Tuesday, February 02, 2010

Risk Management – where it fits in Scrum?



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.

13 comments:

TK on 10:26 PM said...

In principle having Probability/Impact matrix as an artifact for each sprint or release makes perfect sense. However, most people aren't trained in assessing risks. Also, as with any estimation from backlog sizing to sprint task sizing the scoring for the P & I is very much tuned to the team. Which means you will not get a true picture of overall "risks" across the 7 scrum teams. Of course one has to start somewhere, and so I agree with you making P&I assessment for both at the sprint level and equally if not more so important at the release level makes sense.

Jesse Fewell on 4:45 AM said...

Great post. I like how you contrast the old and the new. Like everyone else, I used to believe that risk "was always the Project manager’s baby and if he didn’t foresee the risks of the project, his job was at a risk". However, I've become convinced that the most effective PM will not manage risks to make them go away, but will escalate risks to decision makers. Agile PM is all about putting the decisions into the hands of the real decision makers: strategic tradeoffs must be done by the sponsor/product-owner, and tactical tradeoffs must be done by the team. Your sticky-note technique is effective for doing just that. Some teams use a whiteboard & marker instead of sticky notes, but the idea is the same: transparency.

Shafraz on 7:29 AM said...

Hi Dear,

In simple terms risk in Agile called 'Impediments'. What I know about risk/impediments is that you identify it and act then and there.

"Kiss" is a concept that most agile people trying to forget when they come from the background of Waterfall or other high ;) methodologies.

What is mean to say is that agile insist on 'Keep it simple stupid'. So simply the team identify the risks each and everyday and seek the high level for the removal of the impediment right away.

Shafraz
http://www.mycvauth.com/id/shafraz/

Dave Prior PMP, CST, MBA on 11:02 PM said...

In handling risks with the team, I have done the same type of thing - used specially colored cards and had folks place them on the wall under a special RISK area. If these were critical enough time-wise, we would address them after the morning standup. Otherwise, it would wait until planning for the next Sprint.

The other thing I have done is actual full blown traditional risk management, but not with the team - with the primary stakeholders. This was a weekly meeting that lasted no more than an hour. I maintained a traditional project risk register with quantitative and qualitative analysis, triggers, response strategies and owners, expected impacts, the whole works. My promise to the stakeholder was that I would agree to come and meet to discuss new and existing risks with them each week as long as they continued to attend. This is based on my experience with attendance for these meetings dropping off once the attending parties come to the conclusion that someone else is spending more time worrying about what can go wrong than they are. It sounds simple, but the value of risk management is two-fold, if you do it right - you have a plan in place for dealing with what might go wrong and, people know you are carrying this burden for them. Once they realize that, they are less stressed, when they are less stressed, they interrupt you and your team less. Plus, they are better informed about what is going on. I'd probably spend about 30 minutes preparing for the meeting and 30 minutes updating it after. So, in two hours of time per week, just from me, the client was up to speed on the risks we faced, contributing their own and realized that I was tuned into things enough that if anything major happened, I would let them know - so, it also helped me with building my own personal brand with the client. It may seem like overhead to some, but IMHO there is really no downside to incorporating traditional Risk Management into Scrum.

Anonymous said...

Amiable dispatch and this post helped me alot in my college assignement. Say thank you you seeking your information.

Anonymous said...

Your blog keeps getting better and better! Your older articles are not as good as newer ones you have a lot more creativity and originality now. Keep it up!
And according to this article, I totally agree with your opinion, but only this time! :)

Anonymous said...

nice post. thanks.

Prasad on 8:12 AM said...

Hi,

As you said, PMBOK has a separate knowledge area on risk management since it is that much important in projects to identify risk and manage them. In SCRUM we identify risk as impediments. These impediments will be identified in daily scrum meetings and it will be visible to the entire project team. Risk management or the risk handling as you mentioned :) will take place during the sprint.

I do agree with you on using colored sticky notes as a method of getting the visibility of the risk in a project. By doing so you will get continues reminders about the risk that is in the project as you walk near a project team area. :) Also you know that some how you need to reduce the number of red and amber sticky notes from the board.

This is the “risk visibility” that lack in some of the organization which does not use agile methodologies. In those organizations, the task of the PM is to identify risk and document it. Maybe he/she might enter these risks in to a project management tool/software that is in use, but stakeholders will not be aware of it till something major happens.

rakesh on 8:22 AM said...

it's really good post about the scrum risk. why don't you write an article about the risks involved in planning stage of agile projects. it is really helpful for every one

Thushara said...

Thanks Rakesh.. I will definitely look in to it .

satya on 11:59 PM said...

I liked the article very much. Team should be able to identify the impediments related to the work that they are doing, but when you reach out to other stakeholders they have altogether different kind of risks (external dependencies, business, etc..,) which need to be responded.

Himadri's Blog on PMP on 1:23 AM said...

Good post.We are following SCRUM in our projects so as some XP. Basic idea of make our life simple and project successful is to identify/plan/track/communicate the risks. So 2-fold strategy really works 1)sticky notes for risk 2)weekly communication to stakeholders.

Himadri's Blog on PMP on 1:24 AM said...

Good post.We are following SCRUM in our projects so as some XP. Basic idea of make our life simple and project successful is to identify/plan/track/communicate the risks. So 2-fold strategy really works 1)sticky notes for risk 2)weekly communication to stakeholders.

 

PROJECTIZED. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com