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.
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?
“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.
Salesforce only has one production code base. We do have ~18 versions of our API, and guarantee backwards compatibility. New stuff tends to only appear in new versions of the API. It all flows through the same few code paths, though. You have to do quite a lot of regression testing. ;o)
We use agile extensively, and a lot of the items you mention are rolled into the 2 or 4 week sprints. Usability, internal and external docs, systesting (mostly) are all required to be done before a feature is considered finished. Our release sprint is pretty small, and we’re trying to make it smaller.
Of course, the functionality you can deliver in 2 weeks might not be a fully baked “feature”, so the notion of versioning and optional activation has to be baked into your infrastructure (and dev/qa culture) at a pretty fundamental level.
We have a few people that are starting to speak at Agile conferences about scaling agile, I’ll see if there are any online slides.
@Peter
Wow. That is cool. Seriously cool and it is interesting to hear how you are bridging the backward compatability gap with what I assume are message interfaces to the same codeset?
Nice, man.
Yes, our API is SOAP based (well mostly, some legacy xmlrpc), so each version has its own endpoint. Once beyond the base serialization layer, it all moves into the same code path. I’m grossly oversimplifying, but that’s essentially true.
Our WSDLs are dynamically generated, so those change as we upgrade the service. Actually, they are dynamic down to the field level, based on version, permissions, features purchased or activated, who you are, etc, a whole raft of options.
Given the complexity of those combinations, we offer a number of calls that describe additional metadata beyond the type info of the WSDL, e.g., is this field updatable, or createable. All that also has to be versioned (usually).
Here are the API docs.
http://wiki.apexdevnet.com/index.php/Web_Services_API#API
the Describe calls are the additional metadata ones I mention.
also, would you mind updating your original salesforce comment in your post, it’d be much appreciated. ;o)
thanks.
@David I’m not sure you’re getting my point, although I think my blog response may have been less focused than what I intended (I wasn’t totally serious either, though). I feel like something that you and many, many others seem to be less focused on is the fact that Agile is an ideology and NOT a process, so are you advocating a different idea for business to adopt, or are you focusing on a process that fits the Agile model, or is this a plug for education at the business side of things? Or is it really all of the above? I agree that business has to get on board sooner or later, but what do you think is the solution? Do we need to sell them on something or do they need to do something entirely different? I’ve been meaning to blog on how to sell business on Agile for a while. Maybe Agile and the MBA should be the next focus of the development community.
I understand about the sales organization not being able to keep up. But, as others have noted, you don’t have to publish your versions every 2 weeks; you can just add internally and then ship a bunch of iterations every few months.
However, I do think that part of the model working with sales organizations is backward. Some sites like Dell and Amazon continually tinker with their sites and nobody seems to mind. Their secret is that the changes are incremental and the interface is intuitive. Retraining should be minimal or unnecessary.
I don’t believe agile is appropriate for every project but it does show results to the business community quickly for feedback. Waterfall methodologies, with their long development cycles, often go astray of business requirements. By the time they realize the discrepancy its too late to correct.
Why Agile Doesn’t Really Work, I don’t think this statement is giving the right perception. Development teams use Agile so that they can give working, good quality and releasable software in short durations with the right flexibility.
Yes it wouldn’t be prudent to think that IT teams will be able to release this great working software to users after every iteration.
I think that’s the decision the IT teams have to take on how regularly they can make the releases since the development the teams are delivering great software every iteration.
This decision could also be based on ROI the business teams are looking at.
Earlier without Agile practices it wasn’t possible for development teams to deliver regulary now since they can deliver regularly I think IT teams should also INSPECT and ADAPT at the changing scenarios, Agile is the mindset which has to be embraced by an entire organization rather than just a few geeks to get its optimum value.
“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.