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.
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 -
Subscribe -
Newsletter -
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
