Following up on Antony Marcano's post about Risk Management strategies. I've noticed that many teams abandon Risk Management when they adopt Agile. Instead, they rely on agile practices alone to help them reduce the impact of risks. In my view, this is not enough. Many Agile plans are too optimistic and contain no contingency. New requirements are sure to come up and the team is bound to have overlooked some of the technical challenges. Packing a plan tightly at the start without any slack leads to disappointment all round for customers and developers.
Finding out about issues as they come up in the daily scrum is great. But why not be more proactive? The first step your team can take is to recognize the risks they may encounter on their project. I recommend teams hold a risk brainstorm at an early stage in the project to do this. This can be part of a project chartering or one or part of iteration zero. A risk brainstorm is a also great way to get to know the people on the team, to hear something about their past experiences and share stories about disasters on previous projects.
Get the wider team together and invite stakeholder representatives too (like support, systems admins, friendly users, etc). A diverse group is likely to come up with a more comprehensive of risks. Now start brainstorming. You can do this on index cards or sticky notes so everyone participates not just the talkative people.There are bound to be some off the wall suggestions. Don't censor them! Wilder ideas can help open up the discussion and make it easier to talk about risks. Now cluster them to create a full list of all the things that might go wrong and talk about how they can be addressed.
You'll find most software teams can generate a very long list! If they're slow to start, ask them to look back on their past project experience to remember what can go wrong. I've included a photo from a risk brainstorm session, below. This team filled five more A1 sheets after this!
Now they have got all the risks out in the open, invite them to discuss how likely they are to happen and whether they can do anything to avoid them. Suppose one of the risks is that a crucial person on the project team gets sick? This gets the team thinking about how to plan in knowledge sharing. As you work through the risks, capture how the team plans to handle them should they arise. Talk about what symptoms will indicate that the risk has materialized into an issue. This conversation can be a nice stepping-stone into drawing up working agreements that the team wants to abide by. You'll also find that drawing up a risk list helps justify adding some buffers to your release plan as contingency.