Why Agile will Fail

It has taken a little time for me to get back in the swing of writing this year. While 2008 was great (seriously, would not have changed a thing), I just didn’t realize how tired I was until I had some time off over the holidays. The past few months my life had accumulated the mental equivalent of technical debt. It was important for me to do some refactoring before I could start building out any new features ;-)

What do you think, quite a provocative title for my first post of the new year, huh? I had a few other ideas swirling around, and even started outlining a few over the past few weeks, but none seemed to materialize into a solid article. Sometimes you have to follow the muse and today’s inspiration comes from a friend of mine here in the Atlanta area.

Yesterday, I read a great post by Dennis Stevens called “Business Technology is not about Technology“. If you are not subscribed to Dennis’ blog, I highly recommend that you do so. Dennis brings a great perspective on IT and business and how we can use agile as a means of delivering value in our organizations. The article yesterday made the case that businesses should not invest in technology, they should invest in solutions. That business technology is not the end game, but a means to achieve business goals, a means to profitably deliver value to customers.

Dennis talks about all the failed technologies that never quite lived up to their promise: ERP, CRM, SOA, and MDM. He makes the case that businesses invested in these technologies without first identifying their value creating work streams and how they needed to perform them differently in order to achieve their strategy. Their investments were more about implementing the technology than improving their core capabilities.

The article concludes by stating that responsible business technology discussions start with strategy and flow into operating objectives and finally into improvement projects. Technology can enable those objectives and help improve the processes, but the hard work to identify value generating work streams needs to be done first. The technology is never the silver bullet.

My takeaway from Dennis’ article was that anytime you deploy a technology you better have a clear understanding of how that technology is going to enable your value generating business processes. If you don’t… you have doomed the initiative to failure. Why? The technology by itself does not solve your problem. The proper application of the technology to optimize your most critical value streams is what will solve your problems.

So… what does this have to do with agile software development.

As I was reading Dennis’ article, I couldn’t help letting my mind drift to development and project management methodology. Dennis’ point about understanding value streams and technology could be equally applied to our discussion here of agile development practices… just replace the challenges with ERP and SOA with a discussion of Waterfall, RUP, and Agile.

Just like SOA, Agile will fail because most companies don’t first identify those value streams that are critical for profitably generating value for our businesses. We focus more on deploying agile when we should be focused on the problems that agile is trying to solve. We look at agile as a silver bullet rather than an enabler of a well defined business strategy to optimize our critical improvement projects.

Does your business really care if your team is transitioning to agile or continues to do waterfall?

What your business really wants is to deliver value to market faster than their competitors. They want more responsiveness to market conditions and the ability to change their minds when they get new information. They want lower project costs and more predictability in their project portfolios. Unless your agile transition is delivering on these key business drivers, what does this mean for your agile change initiative?

What it means is that just like with SOA and ERP or any of the others, the marketing initiative called Agile will fail. It will fail because it never lived up to the promise and was never able to deliver the value the business hoped to achieve.

That said… with or without a marketing initiative called SOA, good software architects will continue to build systems around services. Likewise, with or without a marketing initiative called Agile, good project teams will continue to deliver software iteratively and incrementally. Good project teams will continue to respect people and give them what they need to be successful. When faced with the need to change, good teams will continue to leverage lightweight processes that allow for inspection and adaptation.

While Agile might fail, and we might not call what we do Agile or Scrum or XP, the ability to be agile will remain a key differentiating factor of high performing teams!