Update: Apparently, the idea that iterations may have to be prolonged if your process is not advanced enough, was given to me by my colleague Måns Sandström in 2007, which I did not remember as I wrote this post. I wish to correct this and give thanks for that insight and many others, Måns!
You are the lead developer of a team writing a new, enterprise-wide web application and you are finally getting close to release. The project manager has done what he could to push those last features in. There is just one week left for acceptance testing with stakeholders and the week after that, you’re supposed to be live. It sounds tight, but doable.
But there are problems up ahead. (You knew that, right?) Annoying bugs keep appearing. As the acceptance period starts, change requests arrive. Lots of them, actually. By Wednesday you have so many RFCs that you actually feel it would have been a great idea to store them in TFS instead of on index cards. (In case you don’t know TFS, that basically means you’re panicking.) Bug fixing is frustratingly slow. Some fixes seem to create new defects. By Friday, you taste the bitter fruit and delay the release “indefinitely”.
As you go up to the business guys the Monday after, you realise, by their frosty stares, that you are now persona non grata. They really hate you. Who can blame them, really? They bet their careers on you and promised their bosses that this new thing would redefine “awesome”. But it didn’t and now you’re done for. You think to yourself, “It’s not fair!” You just wanted to help. You did your best. How on earth did you end up in this mess?
Most developers recognise some variation on that tune (though perhaps not as dramatic). It’s not that uncommon. Many have been in optimistically short “stabilisation” phases that need to be extended for months and everybody’s frustrated. Let’s back up a bit and see if we can understand what’s happening.
If you haven’t noticed, agile development is really hot right now and one of the core tenets of agile ways is to be able to release new stuff really quickly. It is actually mandatory for software development agility, if you think about it. Imagine the opposite: If you couldn’t release fast, you wouldn’t be able to release new stuff very often, which means you would have batches and you couldn’t change your mind very often on what to develop, which would mean you’re not very agile. Hence, it’s mandatory. So, most agile teams try decrease the time between releases, including the time period from “code freeze” to production. Can we get it down to two weeks? One week? Some teams grow quite advanced, releasing new stuff every day, or even faster.
Of course, to savvy business people, releasing often sounds really appetising. The all-important “time-to-market” factor has been transformed from a threat to an opportunity. Even better, this buys more time to work on valuable functionality instead of doing release work. Any person with a business sense would pressure the development teams to have really short release cycles. Who wouldn’t? It makes business sense and, hey, that’s being agile, right?
What is often not considered is that to be able to release quickly you also have to be able to release safely. In other words, the probability of something being wrong with your software, or going wrong in the release process itself, has to be very low. Typically, this sophistication takes months or even years of effort to accomplish, depending on where you start. It implies great product leadership, direct line of sight to users, a high quality design, thoroughly tested code, and a highly sophisticated automation of the release process itself, including detection of malfunctioning versions with safe rollback. It’s quite the feat, actually, what these teams perform. It takes a lot of disciplined, focused work and a supporting environment to pull it off. There are no shortcuts.
Release problems, like those that appeared in the story above, occur when you really want to be agile, but you are not ready to pay the price for it; when you reduce the time period dedicated to release work to what you want, instead of what you are truly capable of. If the team is wrestling with untested, legacy code; if you haven’t validated your assumptions on how the software should work; or if your release procedures are manual and complicated, you simply need more time.
We can state this slightly more succinctly: You won’t be agile just by wishing you were. It’s not a gift, something you can get for Christmas. It takes dedication, discipline, and directed collaboration over long periods of time to succeed.
If you really want to go this way, and I think you should, I want to give you a mental tool to help you. Imagine that every morning, as you walk through the doors of the team room, Miss Grant, from the 80s show Fame, sits there with a defiant look. She just sits there waiting, until the noise dies down. All eyes are on her. Beautiful. Deadly. Suddenly she speaks to you with intense passion and precision:
“You’ve got big dreams? You want agile? Well, agile costs. And right here is where you start paying – in sweat.”