magpiebrain

I’ve seen the diagram below used to describe “Agile Development”. I found it to be quite a good overview of a typical agile development process.

Release, to my mind, is the delivery of business value to the client – the process of taking your wonderful code, packaging it up, and delivering it in a nice little bundle to your client. In this diagram, a release is simply something that happens when you have no stories left. Not only does this jar with the agile/XP concept of “release early, release often”, but it radically oversimplifies the kind of checks that might need to be done prior to a release being ready (here simply called “System Testing”).

A month or so back I had a chat with a colleague, where he talked about a different way of deciding what is ready for release. He talked about a series of tests that a system must pass in order for a build to be considered “Ready For Release”.

Anything which made it up to the top level was eligible for release. When the deployment team was ready for or needed a release, they would look at the current stack of eligible releases, and be pick the latest one, or perhaps the first release in the stack which met their requirements (which of course would come from business requirements). What I really liked was that such a process really encourages frequent releases, more so than the process outlined in the first diagram – it is based not on “have we done all the work” lines, but on “could we release this” lines.

As developers, our success is not rated by lines of code, or a stories completed, but by what actually gets delivered to the business. Perhaps we need to be thinking less about an agile development processes, and more about agile release processes.