Why Agile Doesn’t Really Work
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.
- If an organization has a product it can ship, it must actually ship it (gasp).
- 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.
Uncategorized
“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.”
That pretty much nails it, David. Having seen how tough a sell agile can be for just development, I don’t think many companies would buy into the agile enterprise in one gulp.
Perhaps getting a foot in the door with agile development will lead the way. If the software is ready and waiting every month, the onus and attention will fall on the IT, sales, and business groups to become agile enough to make timely use of it.
Flickr meets both 1 and 2. Therefore agile software works in at least one case.
Porting agile software dev to corporate environments which are on the whole not agile, however, fails. I’ve seen this firsthand as well but it’s not a failing in the methodology, it’s an incomplete implementation of it.
You need to get your deployment people working Agile also, and after that your management team, and after that literally everybody else.
If you’re trying to rescue a giant corporation from its own dysfunctions, that’s a much broader issue than whether or not Agile software dev works.
“No silver bullet” applies to systems at every scale.
A chain is only as strong as it’s weakest link.
For an awful long time, that link was the dev/build/test/package piece. Agile/unit testing/ci all help with that.
But now, as David points out, the next glaring bottleneck in the lifecycle is deployment.
There’s a great saying in the 12 step movement…”There won’t be change until the pain to change is less than the pain to stay the same.”
Roughly translated, IT departments aren’t going to be wild to deploy the newest/snazziest version/patch/whatever unless the perceived payoff is greater than the risk/pain of staying where they’re at.
We’ve all been the victim of patches/upgrades-gone-bad. And IT departments are (rightly) gun shy cuz they get royally chewed on when they deploy something (new/patched/upgraded) and it breaks existing line-of-business apps.
The current solution? Extensive quality checks. Test/Stage and Prod environments. (which are spotty for most companies) Documentation out the wazoo.
All which slow the deployment process down. Usually planned/executed by the same person (the stereotypically overworked IT application/network/systems admin).
A better solution? Hrmm…well, what would agile IT look like? Given IT folks don’t have the same intrinsic ability as developers to build their own tools (though some _are_ accomplished dev’s, and most have a strong duct-tape-and-bailing-wire gene) there’s a bit of a gap there. Just like I wrote my own almost-ci-solution in perl back in 2000, I’m sure there are IT folks who’ve put together custom rapid-deployment solutions for their shops.
I guess if I were a CIO, I’d ask…does “rapid/frequent deployment” really help me help my customers kick ass? If yes, then great. If not (“hey, your windows have _transparency_ now!”) then I’ll give it a pass…
[/ramble]
Interesting and thought provoking, but actually, I totally disagree
Although there’s plenty of dysfunction in today’s corporate environment, software development is not about delivering working code, is about delivering solutions.
If you sell software, would you make the new version immediately available or wait till the previous one looses market momentum? Maybe you want to wait for a particular date or event. Maybe you want to segment your market differently, having the software ready is only a component of the solution.
Even for internal corporate software (non-COTS), would you install a new POS system in your busiest season, forcing your vendors to spend time learning the new system instead of selling to customers? That is not a good way to stay in business…
Bottom line: ship or use a new software just because is available is not always a good idea.There could be plenty of business reasons to NOT do it… maybe Agile doesn’t work because it focuses too much on delivering unit tested code and forgets about the big picture. Saying “we fail because the others can’t keep up with us” seems lame
Interesting post. I agree that elements of Agile practices can help organizations but it is unreasonable to expect the organization to keep with a flux of releases.
Frequent releases may work fine internally or for hosted apps but shipped products is an entirely different story. It may work well if are delivering pieces that fit into a bigger picture. As with everything once the hype fades, the tried and working practices stay.
Sorry guys, you just don’t get it. The point of Agile isn’t to actually ship your software every two weeks or every day or as often as you can, it’s that you have the ability to ship whenever you need to because you maintain working software. The point of the actual frequent “delivery” of working code is so that you are able to respond to change rapidly by having a rapid feedback cycle. This rapid feedback also makes it easier to fix things or make changes because it’s a lot easier to make a change to something you were just working on earlier today than something that you worked on a month ago or longer. If an organization is shipping too often for the customers to get any value, then Agile hasn’t failed, the organization has failed. Here’s my complete response to this post:
http://agilology.blogspot.com/2008/05/why-elegant-code-doesnt-get-agile.html
@jeff,
You missed the point, man. This was a tongue-in-cheek article agreeing with you.
The real point is that in order to move up to the next level of genuine Agility, we are no longer focused on software development.
Agile software development proved itself. Game over. Now what? Sit back and let the anti-Lean queues build up at the end of the factory door? How about teaching MBAs who run companies to embrace change as a value-add.
I don’t think it is I who doesn’t get it, sir.
Frequency of delivery can depend on many other outside factors. Training, documentation, migration, process changes, many things need to be in place for different types of tools to be released.
Delivery is dictated largely on environmental factors and the class of application you’re looking at. For an internal sales tool, we can’t swap out one tool for another without massive repercussions. Rollout requires quite a bit of coordination with many stakeholders. Once the tool is rolled out, even minor additions of features triggers internal support issues. “What is the process now with this new feature?” etc etc.
I’d say the ideal plan is “release as often as you can, but no oftener.” Releasing too often creates churn and waste.
I understand and feel your pain, but I quibble with your title. If you had named this article “*Where* Agile doesn’t really work”, then I’d have been right with you.
Unfortunately, it seems that Agile will hit big business only when small businesses that succeed with Agile/Lean become big businesses that succeed with Agile/Lean. If it happened, that would take decades, but then, any revolution takes that long attain anything close to critical mass.
Still, your message is clear: the world is not Agile. I hope you don’t think anyone sane is walking along claiming it was, or could be anytime soon!
@JB
Consider Toyota and the Toyota Lean Manufacturing System.
I believe big busines can be Agile, but that means a fundamental change from command and control management models to a model of empowering the individual worker.
The point of this is that although we can deliver a steady stream of software from development teams, we can rarely deliver steady streams of value to our customers.