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.

Project Communication in Outsourced Project Management

We all know that, in average a project manager spend more or less 90% of his or her project management time for communication. Proper and effective communication is one of the most challenging areas in project management.. How about communication in outsourced project management..? that is any PM’s nightmare unless they manage it properly from day one.
This issue is not about language, either you do nearsoursing or outsourcing, nowadays most the professionals will speak good English. But poorly managed remote communication may increase the risk of project failures drastically. All aspects of remote communication should be carefully quality managed by a project manager who is in to outsourced project management. Unfortunately this needs quite lot of experience.
Over the years I’ve seen most the PM methodologies have matured, and processes has been introduced for project management.. New tools have come to the market., but still the challenge of remote communication remains the same.. How do we overcome it ?
Recently I had a chat with one of my project managers. He told me a story about a project he has managed while working in his previous company. It’s a very small sized project developed for one of the European countries. So him being the project manager sitting in the development company in Sri Lanka has communicated with customer via 600 emails. It gave me a fright.. Are we really doing something right here?
Have you heard about “Mad email Syndrome” which is very common in outsourcing operation. These are the symptoms;.
Project Manger from Venders company writes a mail to the customer about his questions regarding some requirement.. A nice email. Customer reads the mail., thinking why these people can’t even guess some simple thing like that …then he writes a reply in Blue color as comments for each question. ( yes we need to clearly separate the answer from the question)
Now that the Vendor's project manager who waited impatiently till he get all the answers to his questions receives the mail and he goes through the blue color comments made by the customer.. after reading that he find its disapointing and the customer has not answered half the things as he expected., most the points are not elaborated., so it creates much more questions for him now. Then what he does.. ? he uses another color., mostly seen is green , write comments in green color again under each blue color comments.. send this to the customer and CC to his whole hierarchy to save his back :-) and show them that he has still not got the answers right.
Customer receives the long email which is flashing in many color comments now.. He get really worked up.. certain symbols can give him a totally a different tone to the email. He write the comments in red color now.. and send it to the vendors PM again..

This doesn’t stop here… Is this situation new to you ? Im sure if you are in to outsourcing business you may have gone through this situation many times. This chain of email communication is a very strong risk trigger of project and relationship failure between outsourcer and outsourcee.. Why such a useful tool such as email can create this much of damage?
1. When communicating through emails , the other party doesn’t see your body language. They read exactly the meaning of word to word which may sound totally different to what you meant.
2. The other party don’t hear your tone of the voice. or your giggling . Recently I saw a customer commenting something like “Remove this field! “ with “!” what is that additional “!” is for ? these may create some unnecessary issues
3. Its very common that both parties think the other party is the idiot. They put less effort to understand each other. This may totally be different if you had a face to face discussion.

So how do you quality manage this remote communication? My advice for project managers are as follows;

1. Do not have email communication over 2 loops., if it goes over always try to use Voice via skype or telephone line. Or even use some tools such as Webex. Which is really good.(video con would be the best but unfortunately most of us do not have that facility )… Hmm How about Cisco TelePresence.???. I love to experience that !! :-)
2. Always read and re read your emails before sending.. do they mean something wrong to the reader.. make sure you communicate very clearly
3. Do not send too many emails. Try to summarize possible information in one email. Have your subject lines very clear.
4. If you need only 1 question mark have one .. But not three.. When you ask “can I have these replies by before end of business today? “ has a major difference between “can I have these replied before end of business today???????????”
5. Be very clear and elaborate on required points.. try to use tables as much as possible
6. Be warned when communication is not going right.. always ask help from your supervisors before it becomes too late.
7. Have the right attitude to respect the other party . if you read the mail in negative mind., you will end up with negative results.
8. Send customer status reports frequently., leave very little room for questions. Reports should be completed.
9. Always have project budgets to meet the customer face to face at least once in your project life. That will make your project communication much easier.
10. Understand that the time customer can spend for you is limited. That’s one reason why he or she outsource the project to you. Respect the fact and always think twice before you raising the question .Because you need to get the question right at the first time .