Why Agile Doesn’t Really Work

May 27th, 2008

Update: I am stunned at the misinterpretation of this post. That’s what happens when you hit publish without sleeping on it, I suppose. What I hope you take away from this article is stated in the very last paragraph.

After genuinely pursuing and advocating this whole Agile thing for the last 5 years, I must admit defeat and withdraw my support from the entire Agile movement.

Uncle. I get it. It will never actually work.

Sure, TDD works, so does continuous integration, and a host of other great development practices. The truth is, though, that the real Agile value proposition was never about code. Better software with higher quality and excellent craftsmanship is a great side effect, but Agile is really about changing how products are created and delivered. Agile intends to fundamentally change the model of your relationships with clients and coworkers.

Fat chance.

The Ensconced Lag of American Business

Agile supports the idea of frequent delivery of value to customers. In order for this to actually work, a couple of things need to be true beyond showing software at the Sprint review.

  1. If an organization has a product it can ship, it must actually ship it (gasp).
  2. If a vendor has made a product available to you, your organization must actually be able to receive the update without tipping over.

Ship It

Let’s say that a high functioning Agile product team has a product that can theoretically ship every 2 weeks. Heck, let’s make it a month. Can the sales department keep up with that kind of change? How about the customer support department? Not typically.

Support teams require time to ingest these changes so they will be “trained” and able to support the new product release. Makes sense, right? Forget the fact that the product is sitting there gathering dust. Pretend the support teams have been playing with drops of the software all along and are ready to support the product the day it is code complete. Can we let the client have it yet?

“Not so fast,” says the I.T. department. We need to certify the new package with a week long burn in and load scenario. Never mind that testing has continuous and past memory leaks have been fixed and checked with automated regressions. Just follow the policy.

Okay, that didn’t really happen. I.T. has worked in close cooperation with the development teams and has an automated deployment system in place that allows push-button product deployment. Awesome. Can we ship yet?

Not until Technical Writing has completed the documentation and help files. What? Wasn’t that supposed to be included in the automated builds so that our documentation builds with our product? Yeah, but the tech writers were busy on another project this week and they need to get back to this project next week. They were proofing marketing materials for the next trade show that the software won’t be available for.

You get it.

Take It

You favorite vendor just dropped a new release of software, but you can’t have it. There are several reasons why, all quite reasonable.

I.T. is backed up with a 6 month project backlog and won’t be ready to roll that new version until the fall. Besides, all the users need to be trained because the new version is so dramatically different they will be crippled unless they are trained on it. Since we didn’t deploy all the incremental updates, it will be a huge User Experience shock.

Oh, and that new ESB version has spawned a porting project for all of our message adapters because BizTalk doesn’t support that little feature we were taking advantage of anymore. That rewrite will take a year. Good luck on that one.

And that new Oracle version? Maybe we’ll get it in 2013 because if we deploy now, it’ll break all of our Oracle forms applications that should never have gone into production, but did.

A Note on SaaS

Sure, Google can roll out a new version of GMail in 24 hours, but just ask SalesForce.com how any many past versions of their product APIs they are standing up because customers have deeply embedded into their system in non-portable ways.

The key here is that Google actually releases small increments of functionality that don’t freak users out. Small, incremental changes in a SaaS model can work. I still believe it.

Conclusion

These two requirements eliminate 99% of the organizations in the world from truly reaching that Agile utopia that is merely Lean.

How many of you are still using Office 2003 because I.T. hasn’t rolled out 2007 yet? How many times has your enterprise had to upgrade through 3 versions of a major enterprise system because no one had been installing the updates from the vendor? This is the norm.

Get it? Having perfect product in hand doesn’t really accomplish anything if we can’t give it to the customer and if the customer can’t take it anyway. Lean and Agile software development isn’t even close to enough. We need Agile business practices to really make this work.

Build your business practices to embrace change just like your Agile development practices do. Embrace continuous integration of the enterprise, not just your source code.

  • Pingback: You Want IT When? | Does Agile Solve the Right Problem?

  • David Cheung

    “but just ask SalesForce.com how any many past versions of their product APIs they are standing up because customers have deeply embedded into their system in non-portable”

    I am not clear what experience Mr. Starr has with salesforce.com but we are one of Salesforce.com’s larger clients and are not deeply imbedded into an API version. We choose to use an API version for features within that version, for applications that don’t require that new feature we can stay on the older version or move up. So in that sense our applications are an extension of Salesforce.com’s core functionalities rather a wrapper around it.

    As to the point of “Ship It;” the incremental deliveries can be partial smaller working functionalities of a larger release released to Staging every cycle (2, 4 weeks) and ultimately combined into a single Live release (Qarterly for example.). There is nothing in the third principle (Deliver working software frequently) that says you need to go Live.