Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Agile Techniques For Risk Management

  • submit to reddit
Risk management is a buzzword that managers and CTOs know well. Risky things, by definition, entail risk. And risky things, when they fail, tend to make these same managers and CTOs look bad. So anytime they can find a way to manage and minimize risk, they do it.

There are many traditional risk management strategies. Companies with more money than good sense put multiple teams on the same project, and let it be known that only the first team done gets any bonus money. The assumption is that if we've got multiple teams on the same project, at least one of them will get it done right. The reality is a bit different. You've incented your teams to not cooperate or share lessons learned, work long hours, and take shortcuts. All these leads to the reinvention of the wheel, bug-ridden code, and projects that barely work. Not to mention burned out developers who end up quitting.

Another tactic is the reorganization. This technique doesn't mitigate risk for the company, but the individual. When projects are heading south, managers initiate reorgs so that the teams responsible for the failures no longer exist. It keeps your job safe, but is really destructive to the company.

Agile brings real risk management and minimization to the table. Here are a few ideas you can share with your favorite management type, and you might even be able to use them yourself.

  • Time boxed iterations (link) are great. If you've got three teams, and one of them can't finish something in a week, or in the second week, or the third week, you know which team is having problems. Traditionally we find out where the problem teams are when projects are 80 to 90 percent done, when the teams all start to integrate, and things start to fall apart. A time boxed iteration doesn't tell us what the problem is, but where, and it tells us quickly. Then we dig in to find out if it's competence, training, estimation, personnel issues, or more.
  • Test automation finds issues as soon as they're committed into the code. The traditional model involves developers committing code, and then weeks or months later, QA runs manual regression tests. Of course, months after the fact no one knows who wrote a piece of code... and even if you do dig it out of your source code management, the developer who wrote it doesn't remember why they wrote it. Test automation, run inside of a continuous integration system, catches those problems in minutes or hours. Then the developer who broke a feature can learn from their mistakes, as well as fixing them quickly.
  • 3x5 cards for features (link) force developers to dig into requirements before they start coding them. I've seen more projects go off track when a feature hasn't been thoroughly vetted and it suddenly expands and blows the schedule off track. Any feature that's estimated for more than a week needs to be broken down. This takes time, but it also manages risk.
  • Daily meetings give managers a time every day to hear what their teams are doing. If someone is stuck on the same feature or bug for days at a time, let's circumvent the traditional developer tendancy to stick to a problem until we've solved it. Instead, let's get that developer the help needed to solve the problem quickly. A mentor who's solved the problem before is the perfect person to teach someone how to quickly fix a problem they've been bogged down for several days.
  • Pairing or peer code reviews (link) prevent any single developer from accumulating too many knowledge in a silo that no one else has. If that developer quits, or is in a motorcycle wreck, what happens to the team? They're in a bad place. Let's mitigate that risk by requiring either pairing or peering so that the knowledge silos are broken down. This is also a great way to train your team without taking them "off the line."

There are more ideas, but these are enough to get you started. Do you want to expose risk more quickly, or hide it until it's too late to fix? Do you want to manage the risk, moving it into smaller, easier bits of risk, or accumulate for an entire two year project?

Agile techniques can help you knock risk down to size. It's not a silver bullet, but it's much better than a two-year waterfall project that hides all the problems until the very end. Identify and manage your project's risk as early as possible and give your project the best chance it can have of succeeding!
Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


André Dietisheim replied on Fri, 2010/05/07 - 2:34am

Interesting read! I'd like to a 2 more techniques I'm used to and I was involved in when I was in a high risk project:

 - we terminated the daily scrum by asking every participant about his gut feeling. Everyone could put in his feelings about anything that matters in the project: are we gonna make it? how's the collaboration? Am I motivated etc.

- every team member individually did a risk assessment once a week. We had a Excel sheet with the current risks. We judged the probability of the risk and its consequences for the project (a number between 1-10 for each of them). Everyone could add further risks into the form.The scrum master summarized the risks and major threats were briely discussed.

Jared Richardson replied on Fri, 2010/05/07 - 9:41am in response to: André Dietisheim

Excellent additions André! I like to do the second one (risk assessments) during the retrospectives. If your team is doing weekly iterations, then it fits right in. If not, then I like your way much better than waiting a few weeks to air concerns. I try to pull one to three items that rank the highest for the team and tackle those in the next week. Any more than three and things tend to get lost in the shuffle. Thanks for the additions! Any more anyone?

Dan Rough replied on Tue, 2010/06/01 - 11:46am

This is not just meant as a shameless plug for a recent blog post of mine, but in one of the teams here because of their circumstances, we're running an experiment which involves talking about the cards in the stand up in the morning instead of using the standard method. They're doing that in conjunction with the metrics relating to cycle time they capture, marking feature cards going through their wall with a date which on average similar sized ones would be completed by. This allows the team to manage the risk on a daily basis. See "Not Time Boxing or Commitments but Managing Risk by Using SLAs" for a full explanation.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.