Why Agile will Fail

WRITTEN BY Mike Cottmeyer

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!

Subscribe to this blog

leave a comment

Leave a comment

Your email address will not be published. Required fields are marked *

2 comments on “Why Agile will Fail”

  1. Jim Benson

    Mike,

    I fully agree.

    The reason that ERP, Scrum, SixSigma, CMMI and others ultimately fail is that they are human constructs.

    They have lifecycles.

    As you say “marketing efforts”.

    Beneath all these things, however, are principles. Usually initial principles that get slowly engineered out of the final product – until what we are left with is a marketing object with a finite lifespan and limited appeal.

    The questions you are asking are value oriented. How does the organization benefit from a decision? How do we as individuals benefit?

    What’s interesting is that these questions are popping up all over the place lately.

    2009 is going to bring some fantastic evolution in management.

    Reply
  2. Mike Cottmeyer

    Thanks for the great reply Jim.

    Back in the early days of my career, I was a data center guy. I used to build servers, network infrastructure, and the like.

    It was amazing how many times I had to tell people that the project was not to build a new server, the project was to improve system performance. The project was not to upgrade the OS, it was to make the server more secure, more reliable, and increase up-time.

    We get really focused on the solution, as if the solution itself was the endgame. IT people can be so technology focused, it is if we put on blinders to the real underlying business problems that justify our existence.

    My sense is that people have some sense early on that the SOA project translates to better business performance. Abstracting that business benefit behind the technology implementation obfuscates what we are really trying to accomplish.

    Language is important here, it shifts how we think about the problem.

    Reply