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
At youDevise we are succeeding with the SaaS model you mention – small, frequent changes that don’t require active rollout. We do have components with which customers integrate their own software, and you are right that we can’t make changes to them as frequently, but that’s not a major problem for us – our tests verify each release that those components haven’t changed behaviour.
Our own sales and support staff seem to cope OK with the frequency of changes – it certainly helps that they can give near-term dates for bug fixes or new features. I suspect this flexibility is a feature of a 30-person company – I’m not certain we could pull this off with 300 or 3000 employees.
See https://dev.youdevise.com for our further thoughts on this subject. Thanks for the post!
About Shipping : in my previous company sales department was so creative and efficient that they already sell things we still have to write. Beside we were the technical support (programmers) so I can not see Your arguments against agile.
I came to a similar conclusion a while ago, but not an identical conclusion.
My first response has to do with the kind of development being done. You’re talking about developing software with a large number of customers and a diverse user base, but the original XP project was developed for a single customer and a relatively small user community. I think that most of the software development work in the world falls into the later category, not COTS or SaaS.
Second, in the case of COTS or SaaS, I think we can still do Agile with a slightly looser definition of what Agile must be. For instance, we can still do time-boxed development iterations and re-examine estimates and priorities at the beginning of each time box, even if this is not a release to outside customers. We can also aim for tight interaction with marketing as the best available proxy for the on-site customer, though I do find it counterproductive to actually call this person the “customer”.
I’ll admit that this second paragraph is in the hypothetical realm for me because although I currently work on COTS, my current manager doesn’t buy into Agile at all. He does buy into unit tests, so I can at least openly do TDD without any conflict. In any case, I do believe that my second statement is plausible.
Is this only about money? It seems the whole notion pro/contra here is presented as if the money aspect is the most important one. Well I guess that is sad
Inspect and adapt, man
@markus
I don’t think the point is about money. It is about the ability of organizations to adapt to change. A friend of mine pointed out that software changes about every 3 years. In the case of Windows XP it took 5 years for a new release and MS was crucified for the delay. Now they are trying to move to a 3 year release cycle. However most large enterprises can not accept change that fast. If you look at most enterprise organizations today, they still run XP and have no plans to change until forced. Some of this can be attributed to problems in vista but most of it is that large companies just can not change out their desktops that fast.
Even small organizations can be held up by this. Say you want to go to the next version of office but a critical application is not able to be migrated. You must sit on the old version of office util the applicatio can be modeified. The botttom line is most organizations do not have the bandwidth to accept change as fast as systems can be built and deployed using todays technologies and processes.
Iterative development process, RUP, scrum and agile have helped us develop systems faster and with better quality while ignoring the pople factor of how quickly organizations can accept change.
We deliver software on weekly iterations, but we have releases only every quarter. It’s about potentially shippable software, not shipped software after every iteration.
We have release plans, deciding what themes are in this release, then picking stories to fit those themes.
We deliver to stakeholders after every iteration, and have production-ready software installed for any to see after every nightly build.
I’m not sure anyone in the agile community ever advocated shipping software after every iteration. Releasing software is done in stages, first internal to the team to testers, then to the stakeholders, then probably to users for usability testing.
It’s a large risk for companies to constantly upgrade software. This risk isn’t mitigated by upgrading more often. The point of iterations is not to ship often, but to release often, for the purposes of gathering feedback.
@jimmy
I understand actually shipping every 2 weeks may be a bit much. Often, the features available need to be richer than a 2 week development cycle allows. Shipping more often than every 3 years should be a good thing, though.
I must disagree on one point. The risk of deploying new software definately goes DOWN if it is done more often. This is simply an iterative approach to deploying software, just like we advocate an iterative approach to delivering software.
Take this idea, “Teams that ship often, ship” and turn it on its head. “Teams that roll out new software often, roll out new software.” This requires a symbiotic relationship between a vendor who releases iteratively and a company that accepts change iteratively.
If you have been getting the nightly builds from R# as it prepared for beta, thank you for proving the point.
Continuos Integration of the Enterprise is simply automating frequent rollouts of small change. Risk goes down with that automated integration in place and exercising it frequently.
@wonglik
It is definately aout money and what’s wrong with that? If your customer can’t accept your software because they are unable to ingest it, the value you provide to them goes down and you end up supporting a deprecated product version. That’s $$$.
Jimmy Bogard,
At least one agile advocate does suggest shipping after every iteration, and more – Kent Beck, in Extreme Programming Explained (2nd ed.), says that if you become a really super-XP project (a handful of bugs per year, totally automated tests, a super-high-velocity team) you should ship to production _daily_. I think he may not have been totally serious (has anyone actually done this??) but he certainly thinks us mere mortals should ship weekly (or whatever our iteration length is – 2 weeks or 1 month for my teams, for example).
At youDevise (see comment above) we deliver to production after every iteration. This does cause occasional customer confusion (why did you release last weekend if my feature isn’t done?) but we don’t have the kinds of logistical problems described in the article.
Amen to this post. There are so many additional points to add to this, I might blog about this as well.
@Markus
Of course it is about money. What do you think businesses exist for? To enable developers to deliver the latest and coolest bells and whistles?