Agile Is NOT a Risk Management Strategy

Last week I told you that agile is a risk management strategy. But it's not.

I lied. (Sort of)

It is true that agile covers all the principles of risk management. I already discussed that last time. And I'm not taking that back. However, agile does not cover the whole domain of risk management. I have three arguments to support my case. Allow me to explain:

1) Agile Does Not Look Inside-Out
In a comment on my previous blog post, Pradeep Bhanot wrote:

"The ISO definition of risk […] deals with broad organizational and legislative issues at a macro level. […] Risk management strategy is a continuous process with a long time horizon. Agile approaches are pretty introverted (other than including the customer), and are missing the inclusion of many external factors that a risk assessment would."

Agile software development only looks at the project itself, and the impact that the product has on the customer and the users. But no system exists without an environment. And agile doesn't always take the environment into account.

For example: Only two years ago Microsoft introduced two competing data access technologies: LINQ to SQL and Entity Framework. These technologies were created by two different teams that both were unaware of what the other team was working on. It must have been an unpleasant surprise for both teams to discover a competing product within the organization. And it wasn't just bad for the teams, but for Microsoft as well. Support and migration of customers from one (new) technology to the other is a lot of extra work that could have been prevented. A little risk management might have helped here. (Though Microsoft did decide to release both technologies, apparently for other reasons.)

The teams behind software projects might be very agile. But agile doesn't cover risks to the environment.

2) Agile Does Not Look Outside-In
Have you ever experienced staring at your code for an hour, not being able to find a bug, and then someone else comes along and finds it in 30 seconds? Or (for the non-coders among us) have you ever experienced re-reading a piece of text five times, and then someone else points out three embarrassing errors after just half a glance? Annoying isn't it?

Well, that's the blind-spot problem, and everyone who's ever created something will recognize it.

My argument is that the blind-spot problem applies to any living system, on any level. It not only applies to individuals, but also to entire teams. I've experienced a situation where a team was unable to see a glaring problem that was smiling in their faces while waving a red flag and wearing a tutu. (No, it wasn't the customer.) The team couldn't see the problem because of their blind spot. But I was not on the team. I was an outsider. And I saw it, in mere seconds.

In this case it doesn't matter whether or not development teams are agile. Depending on their level of experience there will be a number of problems that they just cannot see, because of their blind spots. And, being naturally restricted to what happens in the team, agile doesn't cover any blind spots.

3) Agile changes the risk landscape
At the Open Agile conference in Romania I had several inspiring discussions with Corey Haines about the risk of doing agile software development. Corey is convinced that doing only Scrum, without any technical practices, is actually worse than applying traditional approaches. Because, with traditional approaches, there is at least a chance that the code has some level of quality, while with a Scrum-only approach the quality of the code would deteriorate faster than the solvency of the United States Treasury.

I have pointed out a similar issue in one of my earlier articles, where I claimed that agile software development introduces new risks by relying on people being smart, eager, disciplined, etc… When the team lacks any or more of such qualities (and yes, there are more) then you've already got a big problem before you've even started.

Agile is a great tool for managing many risks, but the transition to agile itself is risky business too. Agile both removes and introduces risks. Therefore agile doesn't manage all risks, agile just changes the risk landscape.

Landscape-9679326@N04-2586526191
Someone should be overlooking the entire landscape…

Three Times a Charm
So you see, there are three reasons why I think agile is not a risk management strategy. Well OK, let me rephrase that:

Agile does some risk management, but it's not a complete risk management strategy.

Yes, the principles of risk management are nicely covered, and many risks are managed, but only for a limited domain of problems. Agile cannot check the whole environment, it cannot see the blind spots, and it cannot prevent introducing its own set of new risks.

That's why people from outside the team need to be involved to cover the entire domain of risk management.

I'm glad there's something left for me to do.
And I'm sure many agile coaches would agree.

(image by neona)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
Agile Is a Risk Management Strategy
Risk Management = Banana Peels AND Dollar Bills
Playing Risk: the effect of one little rule

  • Top 200 Blogs for Developers (Q2 2009)
  • Reading Books in a Parallel and Non-Sequential Way
Related Posts
free book
GET MY FREE BOOK!
“How to Change the World”
  • http://softwareresults.blogspot.com/ Dave Moran

    I agree with Corey’s observation that Scrum practices alone can be dangerous. I just held an all-dev meeting at my company to discuss our implementation of agile/Scrum and to review the key software engineering practices that are important to be successful. Scrum alone does not provide any guidance on software practices, and teams need to make sure that they understand these practices and incorporate them into their work — otherwise you risk taking a giant step backwards!

  • http://www.XProgramming.com Ron Jeffries

    I agree, of course, that Scrum does not specify technical practices, though many / most courses discuss them. Scrum does however demand that the team continually refine its definition of “done”. If they do that, they’ll discover the need for good technical practices.
    It’s also worth mentioning, I believe, that no method provides a completely sufficient set of technical practices. Even XP’s list is just the beginning of what one needs to know.
    Finally, I think that the bottom line of Jurgen’s post is that no matter how much risk management we do, there are almost certainly risks not considered. The trick is to decide how much risk management to do, since doing it all would leave no time for lunch.

  • http://jeromepineau.blogspot.com Jerome Pineau

    In my experience, the only risk control provided by XP and Scrum processed in general are as follows:
    1. weeding out weak players on the team
    2.surfacing technical problems in real-time (they don’t fester)
    3. surfacing weak political structures
    And #3 is key because when that happens, the benefits of 1 and 2 cannot be addressed (only noticed).
    So in essence, XP/scrum cannot succeed in weak technical, people or political environment. So it’s indeed a quick way to immediately identify likely failure. It’s the fixing part that XP/Scrum does not and cannot address.
    Just my 2 cents 🙂
    http://jeromepineau.blogspot.com

  • http://www.dennisstevens.com Dennis Stevens

    Just like the Internet isn’t the new business models, Agile doesn’t manage risk itself. But, if leveraged properly the Agile model can enable management and the team to greatly reduce risk to the business. For example,
    Management:
    – Faster time to cash creates the ability to go after more markets simultaneously (portfolio risk).
    – Earlier feedback leads to the ability to be more responsive to changes in markets, the ability to expedite new opportunities without abandoning work in process, and the ability to verify demand earlier (product risk).
    Team:
    – Introspection creates ability to improve processes (i.e. why, as Ron Jeffries pointed out, Engineering practices emerge in Scrum)
    – Throttling of work in process reduces risk of delivery
    – Incremental development reduces risk of expediting

  • http://profile.typepad.com/PMStudent Josh Nankivel

    “the quality of the code would deteriorate faster than the solvency of the United States Treasury.”
    Ouch! Sad but true!
    My skeptical sense tingles anytime someone claims their methodology to be the alpha and the omega, everything you need in one neat little package.
    The world just doesn’t work that way.
    SCRUM is great, but if you think that (or any other methodology) is the holy grail and all you need to do, you drank too much of the Kool-aide!
    Josh Nankivel
    http://pmStudent.com

How to Change the World - free Workout - free
CLOSE