Agile Techniques For Risk Management
Agile Techniques For Risk Management
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
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!
Opinions expressed by DZone contributors are their own.