I recently read this post regarding how "Agile Fails Better" and found myself wondering if anyone out there had good examples of how their project under an agile management process failed...and more importantly how they got the project back on track.
Question: How did your agile project fail? Were you able to recover from it? How did you recover?
I can't give any details (i.e., company names) but I have known of a project that did fail better because it failed early. The team did several months of iterations and based on their velocity and the estimates on the stories they had, they were able to go to management and show that it was not possible to finish the project in the time given. Once management saw the burn-up charts and the teams velocity, they agreed and canceled the project.
The management considered this a huge win since in the past, they would not have known that the project was going to fail until they were several years and many millions of dollars into the process. Failing early saved them probably millions of dollars.
In our case, agile enabled us to be, well, agile. We were a very small company that could respond rapidly to customer requests. Most of our planning was of a whiteboard, brainstorming nature. We filled up three whiteboards with feature requests, but only the higher-priority ones ever got implemented.
We did "eat our own dog food," and as such we were able to fail faster and discover problems before they got out to the customer. Agile processes enabled us to refactor quickly when such problems surfaced. Problems which get out to the customer are very expensive and much harder to fix than those found in-house.
If there was a weakness to our process it was that we were always fighting fires. It would have been nice to have had a little more foresight so that we could anticipate problems rather than react to them.
If there was one single failing of our process, it was that we became too dependent on a single technology that is now obsolete. Had we been able to look a little farther out, we could have begun bridging this technology gap by gradually incorporating newer technologies.
I agree with Chris, being able to go to management and show--with confidence--that the project needs radical course correction is powerful. It's the best way to give bad news.
All it takes is a simple burndown chart, and they get it. They can see the "Big Picture". They can see what features they want. They can see how long it's gonna take. They can see why eliminating low priority features can be useful. They feel empowered. And you will too.
My experience is that when an Agile project fails, the customer has a project with a partial set of features and some bugs. I've never seen an agile project fail in a way where the customer got nothing but a bill. That is sadly common in waterfall projects. I worked for a company where a project ran for 16 months, spent several million dollars and shipped nothing but power point slides.
I was on the team maintaining the old (client-server) system. In that same time; we added a test system, an automated build and improved user deployment. We also refactored the code to improve maintainability by separating the GUI and business layers. We also shipped dozens of new features.
In the end, four web guys from the failed project were moved to our team to explore building a Web UI from the code base we maintained. They had a demo in four months.
And there the seeds of fail were planted.
Why?
A GUI transplant was a dumb idea that didn't scale well. The C/S app was designed to be used by an internal sales rep. The Web app was designed to be used by the general public. We did ship one new form after another but there was so little reuse and so much duplication in the GUI layer that any little change (like adding paypal) required a lot of poking about and making repeat changes. The decision to keep compatibility with the Client server app was dumb. In hindsight, I really regret that choice and my efforts to keep compatibility.
I knew things were getting bad because it took us longer and longer to deal with changes. And the quality was slipping. After snatching victory from the jaws of defeat, we were now feeding defeat little slices of victory with every dumb idea we stuck to.
And this is why Agile works. We knew things were starting to go off path. Having builds fail and having more time used to fix bugs that made it to the customers were proof that things weren't going well.
It took us months to realize that we need to fork the project and reuse only those parts that made sense to reuse.
What we needed was for our PHB (our customer stand in) to ask two question of the Very Big Boss (the defacto customer)
In the end we had three teams, C/S, Core and Web. This set up worked.