This is about Risk. There are visible and invisible risks in any software project and those risks may appear any time during the project life. PMBOK has a separate knowledge area on risk management. YES it’s that important!
So ..Then why most the SCRUM practitioners are so silent about risk management ( Ok we Agilists think the word “management” is evil ;-) So I will use the word “risk handling”). I think risk handling is one of the most unspoken areas in agile processes.
To me, handling risks of projects and bringing it to visibility of the stakeholders is very important.. Yes..early as much as possible…. If I have 7 Scrum projects happening at this time at Exilesoft, being the Project Director, how do I get this visibility of the risks of all the projects? One challenge of running many scrum projects in my context is that most the time the project knowledge lies within the teams and the POs..But still there can be areas which higher management needs active involvement to avoid various risks and mitigate them. So visibility of this information is still important to the project organization of the company.
I was thinking a way to bring the risks handling in to practice in scrum projects more effectively.. But still not hurting the agile principles and concepts.
I just went back to my pre-Agile age to see how we handled project risks. In the planning stage, we had a risks plan, initially, we used to foresee many risks as much as possible, we had a fairly complicated template defined by the PMO, the project manager mainly listed all the risks (of course it was PMs responsibility) and then he discussed with the team and other stakeholders ( I suppose I did ;-) ) and assigned a figure for the impact and probability. Then we calculated the severity based on the calculation impact * probability. Thereafter we assigned a risk owner to each risk, and the response options, either we are to mitigate it, if mitigate the mitigation plan, Risk deferral, or agreed to transfer risks or accept or avoid.
After doing all these, we were so happy that we had a nice risk plan for the project, sent to all the stakeholders and then some times we forgot about those risks plans when project was too hectic towards deadlines.. or sometimes being PMs we had unique effort on risks controlling and monitoring process. However it was always the Project manager’s baby and if he didn’t foresee the risks of the project, his job was at a risk. :)
Ok.. Now I have a different situation. How do I do this risk handling in Scrum projects? Who takes the responsibility of such risks handling of scrum projects? How do I get this visibility of all the risks happening in my company projects easily?
I don’t want each team scrum masters to create risks plans and get them updated and email to me, to my CEO and other stakeholders every time. Because I know it will never get the attention which it’s needed and there will be lots of “I wish this stuff is deleted” areas in those reports. Further, that will add lots unproductive stuff in to working software focused production which we may not want to have. Top of that how can the scrum master be responsible to foresee all the risks which may happen in the project.. he is just a human being.. shouldn’t there be a collective effort and responsibility ?
So how do we do this better? I thought of this solution.. Im going to tryout and see whether this will really help us. I think so ..
In scrum, we need the ideas of whole team and we need them to think , work together and have the same commitment and ownership. So why not those all getting involved in handling and reporting risks to each other in more visible way? Not only them identifying and reporting the risks, they need to be actively involved in responding to these risks too. Let’s make it an effective process.
Remember the sprint dashboards with sticky notes..That makes your sprint tasks and progress visible to everyone. Even to an outsider who just walks in to your development room.
I thought of giving each team 3 colors of sticky notes sets Red, Amber and Green. Each project team gets a small white board on the wall. Whenever a team member see something as a risk in his project, he needs to write it in either Red ( he thinks that’s serious and need some immediate attention) or Amber ( Not that serious) or any positive risks in Green ( not compulsory) and he paste it on the risk board under the New risks column. They can be technology risks, requirement risks, risks with commitments, or anything…) this risks board will have 4 columns
So I’m sure one problem is already solved.. When I walk in to the development area, I can see the risks notes in all projects and we can see definitely the red ones needed attention. So its important for me to have some discussions with teams about these red notes or amber notes.
How do we use them?
I think each sticky note can have a space in the bottom left corner for the impact and the right corner for the probability. The team can rate the impact and the probability of each sticky note.
In each sprint planning meeting, its needed to take these foreseen risks to discussion with the product owner, prioritize them, if they need any mitigation plans to add them as product backlog items, prioritize them based on severity, taken in to sprints and address them.
Ex: One of the developers (Tom) seen a risk. He thinks using control X may affect the end product performance and users will not agree to use that product feature.
According to Tom, it’s a serious risk so he will not wait for few days to inform this risk to the team, because with time he knows that he may forget this with his other priorities. Therefore, he will write this risk in a Red color sticky note , paste it on the risk board under new risks and he will get going with his committed work.
Next day after the daily scrum the team and the scrum master notice there is a new sticky note on the board, they will rate the sticky note for impact and probability.
In the next sprint planning meeting , they meet the product owner , so ideal time for them to discuss about these newly seen risks with him as he has the total ownership of the product.
Product owner agrees that this is a serious risk and he will have a new backlog item about the performance of the product feature, he prioritize it in highest priority as it may affect the other areas too in the product. So the team will address it in the immediate sprint and implement some caching mechanism to mitigate the performance risk.
This is only one example. Likewise there will be risks which they will have to discuss with the product owner, their own management or even only with the team .
When they are working on certain risks notes they can move them to the in progress column and when mitigated they can move them to the responded column. If the team and the PO decide accept them and not to do anything about that or ignore them completely due to lesser impact, they can move the notes to the 4th column.
In this way I can see lots of benefits which will bring to all of us;
1. Visibility and awareness of project risks seen in all our projects in much simpler way
2. No documentations and complicated templates which will save our time
3. All the team members will share the responsibility of Risk handling process
4. Risks items will be discussed and addressed with no delays and without any missing items.