A Cautionary Tale – Delaying Agile Adoption

I was fortunate that early in my Agile coaching and consulting career I was exposed to a wide variety of teams, organizations and situations.  The events in this story took place in 2006 and have formed the basis for many a great discussion with clients since then.

What happens when you delay adopting agile? Well, one large client I have worked with has found out…

Because this story is a story of failure, and because most people don’t like to have their failure’s exposed, I have anonymized this story and changed some details to protect the innocent (and they are innocent! Failure is a learning opportunity, not something that’s bad).

I started working with BigCom about two years ago. They got a whole bunch of training from me; in total about 60 people received some in-depth training in Agile methods. They also decided, wisely, to get me to help coach them organizationally and for some of their Process Facilitators. What they didn’t do is heed some good advice: start iterating.

They decided that they needed to do some important up-front architectural research on their huge product re-write/porting project. They had an existing product used by many clients and built over the course of several years. This product was implemented in a legacy programming language and in order to make it easy to add features and keep it up to date, BigCom decided to re-write it in a more modern programming language… but they couldn’t decide which one: Java or .NET. Because it was a pure porting job with little if any functional change, they already had a good detailed knowledge of the functional requirements. But this one question of the platform to build upon stalled them. Their research committee studied this question (and some other less important ones) for four months.

Let me reiterate, as part of their agile adoption strategy, they stalled for four months.

I had advised my client that they should feel free to go ahead and do the research, but that they would be well served by starting to iterate and build the new version of the product, even if it meant building it on two platforms simultaneously. The actual experience of trying to implement real functionality in both Java and .NET might seem like a waste, but actually would provide valuable information for the research effort and help speed the decision-making.

Perhaps my advice was too scary to be part of their Agile adoption strategy. Or perhaps there was some legitimate reason for many capable people to sit idle for four months while the committee researched, deliberated and failed to make this important decision. In any case, product management and dev management finally got tired of waiting, and they started up the work.

Of course, without the decision made, the work initially was a real mess: developers were left to choose when to use Java and when to use .NET. Sometimes functionality was duplicated in both languages. Sometimes it made connecting functionality extremely difficult. It wasn’t systematic. But it was experimental, and it did help clarify the issues quite quickly. After only four weeks of doing actual work on the functionality of the product, it became clear how to use these platforms (for the curious: Java on the UI and .NET on the back end).

The research committee had very little to do with the final decision other than to rubber-stamp it.

Time passed. BigCom continued the development work, features were implemented, and eventually the deadline for releasing the product loomed. And then it passed. Six weeks after the deadline, the product was finally released. Nine months after the start of iterations in their Agile adoption. Thirteen months after I recommended that they “just start”.

Four months wasted… and a deadline missed by six weeks. Was it worth it? Might have been nice to distribute some bonuses for coming in ten weeks early instead. Oh well!

Please, if you you are doing adopting Agile as your new way of working, just start iterating!

[This article was originally published on Agile Advice on 14-Jun-2005]

If you find this useful, please consider contributing with our
“Value for Value” model.