The Agile Wish

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?

Debbie Allen as Miss Grant, the dance teacher from Fame

"You want agile?"

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.”

2 thoughts on “The Agile Wish

  1. Regardless if you are doing agile or not. The main problems is stated already in your second sentence. “The project manager has done what he could to push those last features in”.

    So in the end of the project when you should be fixing bugs, testing some more, cleaning your code, testing some more. Then you instead start cramming in new functionality until the last day of the sprint. Don´t we ever learn? You need to educate the PM on this in case he/she is not aware of the basics of developement.

    In my current project the last sprint is planned to end in January. The whole team agrees that february will most likely be needed to test the system as a whole, fix remaining small bugs, cleaning the last code and retesting. It is really hard for managers to understand this.

    Project managers and customers may want the project to end before it is done – we need to be very clear with them. I am a test manager but I never say we can´t release – that´s not my responsiblity. I provide the information – they decide what to do.

    I always have an up to date version of our testing dahboard: this is what we have done so far on a high level: per area we have a status:

    stories/functions not implemented yet,
    open bugs,
    state of development and testing.
    our view of the status – happy, sad, or in between

    Then we ask – do you want us to continue or do you want to try releasing given the above information.

    “What is sometimes seen as a catastrophy is very often just the end of an illusion”

    • Hi Tobbe! Thank you for your extensive comment. I like how you provide customers with the information to make the right decision. At the end of the day, it’s their money that pays for it. I also believe that there is a sphere of stuff which should not lie under their control, but is simply part of being a professional, e.g. choosing the right tools, creating a great design, avoiding programming errors, collaborating, etc. Money’s not everything.

      The 2nd thing I would like to suggest is to read my next post, which contains some of my thoughts on what a good, agile release process looks like. The things you mention as a good release process can be improved considerably as well. I think the ideal to strive for is to not have a release phase at all, of course with quality and safety.

Comments are closed.