Saturday, September 09, 2006

Agile Risk Management

A regular thought in the back of my head on Mondays, is that I've got to go look at my project's risk log and see what mitigating activities are needed this week. And in the fast-paced, open, collocated environment my project operates in, thinking about Risk Management is often last on my mind. Compound that with our risks being in an online Excel spreadsheet (vs. casually handled, openly expressed and discussed, and if possible radiated on the wall), and I was the perverbial deer in the headlights. I had regressed back to my old ways of PMing with respect to Risk Management!

For clarity purposes, I defined risks as "the watch list for things that could go awry (content not fabricated, new/unfamiliar technology, geographically dispersed team, interdependence with another project, etc). I began seeking the input of those more experienced. And did I ever spark a lengthy number of back-and-forth responses. Here are my takeaways:
  • In Scrum, this is exactly what the Scrum Master does every day. While in XP, it is the resposibility of the entire team. But what if you're "Agile?"
  • With daily standups, heartbeats & retrospectives, and other forms of communication and feedback, the team focuses on real issues and higher-probability and nearer-term concerns. Of course this reduces waste by not spending valuable time mitigating risks that may never happen. And when the stories related to a given risk neawr, the team can say "we're uncomfortable with the new technology needed to implement XYZ story, so let's allocate 5 additional points to do a Spike or a Learning Task beforehand".
  • I was reminded that many of the principles and practices of an Agile team are to mitigate most of the risks many people would call "the motherhood and apple pie" of risk management for PMs. As an example, you don't fret over the possibility of losing a key developer mid project as long as you're pair programming. Similarly you don't have to fear priorities suddenly changing, because of our broadly-brushed product backlog (and only the next 1-2 iterations have the additional details required to sufficiently estimate, build and test).
  • My question even moved Ron Jeffries to write an article for the XP website, which also prompted Kent Beck to chime in. Woo hoo! I've hit the big time, baby!

1 Comments:

At 4:03 AM, Blogger Scott W, Ambler said...

There are many ways which agile teams can address risk, for the most part due to the fact there there are many types of risk which need to be addressed. For example, you can address technical risk by:
1. Doing a bit of architectural modeling up front on the project. This is completely different that the BDUF which you see from traditional teams, but fact is that agile teams will often spend a few hours around a whiteboard trying to identify an initial architectural approach. This helps to ensure that everyone is on the same "technical page" and heading in the same direction. See http://www.agilemodeling.com/essays/amdd.htm#InitialModeling for a description of how to do this.
2. Remember that XP isn't the only game in town. RUP teams will prioritize technically significant requirements to the top of the stack early in the project so that they can address those requirements, during the Elaboration phase. The goal is to prove the architecture works from end-to-end, thereby addressing technical risk.
3. We often take a test-driven approach to development, see http://www.agiledata.org/essays/tdd.html , which not only shows that our software works it also enables us to do detailed design on a just in time basis.
4. We try to convince other folks that testing is a good idea. For example, your organization likely doesn't test your RDBMSs thoroughly, does it? Sadly, your organization likely hasn't even considered the concept (traditional data literature has very little to say about testing for some reason). Yet for some reason you're surprised that your production data sources aren't perfect (or worse, your expectations are now so low that you've come to assume that this is the way to be). You can read about database testing at http://www.agiledata.org/essays/databaseTesting.html and how you can safely fix your production databases at http://www.agiledata.org/essays/databaseRefactoring.html

- Scott
Practice Leader Agile Development, IBM

 

Post a Comment

<< Home