Risk based estimation

Although Kanban has been implemented in maintenance I still see there is advantage of implementing it in product development. For me I believe that Scrum provides opportunity to Lean approaches especially in the area is agile requirement development and management.

I prefer having high level business oriented requirements written by product managers who are closed enough to the client. I propose that once requirements are there, we should hold 1-2 day workshop with the whole team to:

1.       Introduce team members to the requirements.
2.       Complete risk analysis for each requirement and the related tasks.
3.       Prioritize requirements based on risks and business value.
Continue reading

Risk Management (RskM), can it become interesting?

“Nothing is as invisible as the obvious.” Richard Farson

Background

I always had problem in understanding the difference between theory and practice. I always considered them the same. I can’t imagine that I could trust physician who has no formal education in medicine. For me people who practice based on theory can deliver authenticated results. In implementing best practices, including Agile and Lean, many of the impediments of implementation are known from advance.

“It has been proven scientifically that the Loxodonta africana and Escherichia coli share most of the same characteristic” (Dr. Robert Charette from keynote at LSSC10 in April 2010). Then, we should expect that the creature we create from implementing organizational practices would carry similar characteristics and problems of the old system.

The two creatures, the old and new processes, may appear dramatically different though they are fundamentally the same. Then, how should we expect that our problems will be solved by moving to the new system? In my view, we might divert the attention of the organization to another endeavor till they ultimately hit the same reality (aka we still carry the same traits of the old system).

RskM in context

RskM is a practice that has rich body of knowledge. e.g. PMBOK® and CMMI®, however it has mostly been implemented in non-proactive way. Just to mention its importance,  traditionally we chose the software development life cycle (SDLC) of the delivery project based on risk assessment.

The implementation of agile practices requires enabling aspects or structures related to people, process and organization. These structures could be identified from up-front using risk assessment techniques. However, in my view, if we try to mitigate all risks from up-front, we might not start the improvement initiative at all.

Process improvement framework

A Kanban system provides evolutionary framework for incremental process improvement and therefore risk mitigation. It helps in implementing Lean practices to maintain the flow while at the same time the agile and XP practices can be rolled-out. In other words, Kanban system can envelop the implementation of various agile and XP practices to weather the winds that will definitely happen during process improvement.

A good starting point is to state the obvious (“the known unknowns” in RskM language) and use them as constraints in our process improvement  journey for discovering the root causes. More risks (” the unknown unknowns”) will be discovered as we progress which can be addressed under the umbrella of the Kanban system.

As we are moving our delivery projects to agile, it is about time to manage our process improvement and transformation programs in agile manner. Kanban system can be a good fit!

Acknowledgment: The above two pictures are from Dr. Charette’s presentation in LSSC10

Risk management in Scrum – Insights

I am writing this post after exchanging tweets with @flowchainsensi.

The Nokia test provides criteria to measure the adequacy of Scrum implementation. If we have ScrumBut (aka inadequate Scrum), then we should not expect the accomplishments in terms of higher velocity, better quality and increased customer value.

Even while we are implementing ScrumBut, we should strive to show some value from using Scrum. This value will allow us to remove handicaps for Scrum implementation and therefore improve our score in Nokia test.

ScrumBut introduces risks to the project. Such risks should be managed using the rigor of Risk Management (RskM) process. PMBOK® and CMMI® have in-depth addressing of RskM details. Traditionally, software development is driven by risks. There are two drivers that can help us start brainstorming for risk identification.

  1. Risks originated from ScrumBut.
  2. Risks originated from not achieving the value which management expects as a result of using Scrum.
I suggest implementing weekly RskM as 30 minutes meeting to:
  1. Monitor the risks
  2. Update risks status
  3. Identify new risks
  4. Create actions to address risks

Such meetings and the outcomes tasks are planned in the sprint backlog.

Risk management in agile/ Scrum

I believe the Scrum frame-work itself is built to address risks. I managed CMMI® program which at heart of its level-3 is risk management and requirement to organize risks into taxonomy relevant to the organization. This taxonomy describes risks categories and attributes that in my opinion are addressed directly if we strictly apply Scrum. I think risk management is so powerful in the world of traditional project management. It reinforces the illusion that we can have a right plan at the beginning.
The advantage of risk management in traditional project management is getting the team together in up-front to assess the possible threats that the project might encounter in the future. Based on those threats the project plan is adjusted so it can weather the proposed risks. Also, it helps to gain extra budget from up-front in case the risks were materialized. Continue reading