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.
The problem was with the “unknown unknowns” which we handle them as set aside budget in the up-front. Everything is pre-scribed and planned. From my experience in dynamic environments, change is the norm and if there are no changes then we are probably not aware with what happens around us.
The team keeps monitoring the pre-stated risks throughout the project. This deprives the project from the possibility of delivering value because it can be against the risk management plan. Risk structuring in the project can hinder the opportunities that we might gain by allowing renewed and re-inventive goals from each time box. Because of risk management, project managers have to be sometimes strict and authoritative to avoid unpleasant surprises and be so much non flexible to change. This limits the team’s talents and willingness to innovate and think of new ideas to deliver values beyond expectations. Talking about change, it is the highest threat for projects managed in the traditional world of project management.
Risk management plan, in my view, is not of high value in Agile world because of:
1. Multiple levels of planning (planning onion) happening at regular basis
The planning at the start of each sprint is done based on state which we do not know about in the up-front. It automatically addresses the future we tried to predict in the traditional world of project management.
The daily Scrums are so useful for the team to get synchronized and renew commitments among them. It provides adjustments of the sprint backlog to cope with glitches and issues. It harmonizes the team and reduces possibility of conflicts.
2. Inspect and adapt mechanisms
Retrospective is an excellent point at which the team learns to improve how to work together. It addresses risks by refining the process to avoid what went wrong and to capitalize on what went well. The beauty of this is that the actions are decided by the team, not auditors or even project managers.
3. Strong involvement of the customer through the whole project
The gives first hand feedback from the customer on the working software each 2-4 weeks. This is key strategy for risk mitigation, in fact risk avoidance. A large benefit her it avoids insulation of the team from the customer. This enhances collaboration. Worst the worst we can lose work of one sprint at most.
4. Self-organization of the team
In Toyota, any worker can stop the line if she discovers a problem. The system trusts the people that they are motivated, loyal and competent. The system acknowledges that the front-line people have knowledge that management does not have. Therefore they are at better position to timely take decisions. For me this is at the heart of risk avoidance as it addresses the people aspect. This is at the heart of respect of the people aspect of Lean systems.
5. Product Owner is responsible on the project
I was always wondering how the project manager can tell the team what to do or to be responsible for while she does not own the requirements of the project. This aspect made the project managers in the traditional world to become risk avert, and they were right. Because they do not want to be held responsible on project controlled by other person, the one who ones the requirements.
The basic premise that degrades the value of risk management is the acknowledgement and transparency about the fact that requirements are volatile and therefore subject to change. The dynamism and evolvement aspects of the product backlog send the message to management that we are shaping up to get the right product. This is a team learning and knowledge acquisition to gain better understanding on the requirements as they should be. It reduces tension with the customer which is a key risk in the traditional world of project management.
I think risk management is a way to prove that traditional project management can work. From my experience in software development, the work is highly imaginative, spontaneous and very much depends on the creativity and alignment of the team.
Another aspect of agile is that the team works during the iteration on almost all tasks at small quantities. For me this is a direct way to realize risks based on hands-on that can help us to adapt through the mechanisms which are already built in the Agile framework.

Another problem I faced with risks in traditional world is that you can not disclose all the risks. For example “don’t know what the customer wants”. We used to have two versions of the plan one which we can share with the customer and one for our internal use. This divide is not there in the Scrum/ Agile world.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s