Martin Fowler: Agile Doesn’t Matter That Much
Martin Fowler has an interesting post up called Utility vs Strategic Dichotomy. The point he’s making is that there are essentially two kinds of software projects, which he names utility and strategic, and that they need to be treated entirely different in the way you staff and run them.
Utility projects, he defines, are the ones that provide functions that are often necessary and crucial to run the business, but not a differentiating factor in competition with other companies.
A classic example of a utility IT project is payroll, everyone needs it, but it’s something that most people want to ‘just work’
Then he delivers hammer blow number one.
“Another consequence is that only a few projects are strategic. The 80/20 rule applies, except it may be more like 95/5.”
What Martin Fowler is saying is that a vast majority of us are doing work that is of no strategic importance to the business we support. I’m sure this statement cuts a wound in many developer’s and project manager’s self images, mine included. But I’m with Martin on this one. It’s time our sector gets its feet back on the ground and we start to realize that we’re here to support the business. Not the other way around.
Hammer blow number two.
Another way the dichotomy makes its influence felt is the role of agile methods. Most agilists tend to come from a strategic mindset, and the flexibility and rapid time-to-market that characterizes agile is crucial for strategic projects. For utility projects, however, the advantages of agile don’t matter that much.
I have a little harder swallowing this one. That the agile movement doesn’t “matter that much” while developing utility systems doesn’t ring true to me. Yes, time to customer is not as critical as in strategic projects, but that doesn’t mean that building the right system isn’t important to utility projects as well. And the agile values will help reducing cost and risk in any project, be it utility or strategic.
Cheers!
Business people sometimes break it down by tactics and strategy. Tactics are the short-term work that need to be accomplished. Strategy is a longer term vision. If were strengthening an existing project, that is a tactic to thwart competition. If we introducing a new project, that is a strategy to enter a new market. Strategic projects will eventually become tactical ones.
What’s driving the work is not as important as some of the actual constraints on its success. When extending the core banking system, it is important to not take a lot of risks. Tactics need to be solid. If we’re releasing a new online banking system, then getting the initial version to market is probably more important then getting it perfect. Strategy can tolerate a higher risk.
If you want to mitigate the risks, you need to apply a lot of heavy processes to insure that everything is thought out and nothing important is skipped. If you follow a solid, but slow engineering process, and set reasonable constraints on the work, eventually you’ll get there. If you wing it and design-on-the-fly, it might work, but you’re relying on luck, and thus accruing risk.
Some programmers are driven to the higher risk projects, they are often more fun. There is usually less formal process and a strong sense of urgency. Low risk projects can take their time, double check things, and get them right. It takes way longer, but if you’re concerned about risk it is a fair price to pay. Mainframe projects are usually low risk.
Some agile ideas mitigate risk (like iterations) and some increase it.
Paul.
Hi Paul,
“If you want to mitigate the risks, you need to apply a lot of heavy processes to insure that everything is thought out and nothing important is skipped.”
Or you apply an agile process but don’t ship to end users until you’re happy with the result and quality is assured. What makes things harder, though, as Martin Fowler points out in a recorded talk, is that the business people involved in a tactic/utility project, are generally less inclined to contribute as heavily in the development process as the agile approach demands.
“Some agile ideas mitigate risk (like iterations) and some increase it.”
Now that is an interesting topic. 🙂 What agile ideas increase risk in your opinion?
My worst nightmare came true: Martin Fowler wants to be Mr. Carr. Everything is a sewer pipe.
What about IT projects that drive innovation and can (and often do) turn the corporate strategy on its head (in a good way)?
While it it true that IT is “utility”, it is also true that software is more than just an enabler. It is a game-changer in corporate environments whose strategy is to drive innovation through software.
@Sam
Hi Sam,
“My worst nightmare came true: Martin Fowler wants to be Mr. Carr.”
🙂
“What about IT projects that drive innovation […]”
Utility projects that drive innovation can very well become strategic, but only if the result is helping the company to differentiate itself against competition. (Martins definition of strategic projects). Otherwise they’ll still just be building utility systems — although shiny and well functioning ones.
“[…] software is more than just an enabler […]”
True, it can be “a game-changer” and strategic, but Martins observation is that very few of all IT projects fall into that category. My gut feeling tells me that he’s probably right about that.