Thursday, 10 February 2011

Go with the flow

One of the major problems that Agile tries to solve is the big bang approach to software development. With Waterfall, you do big up front analysis, followed by big up front design, followed by a long period of development. Testing usually gets squeezed because of time pressure, and integration is done by the seat of the pants. There are several flaws with this approach - you don't get any return on investment or learn how valuable the software is until it goes live. There are lots of projects that never go live, or that when they do turn out to be worthless. I'd much rather learn this lesson after three months, than one year.

Scrum (and other Agile methods) attempt to dampen this graph, by delivering little and often, in what is called a sprint. The initial release may take a few months, but once live, the software should be updated regularly. I've worked on projects with one month, two week and one week sprints. Returning to our principles of fast feedback and acknowledging we would like rapid return on investment, it's clear that the shorter the better. But is a short sprint really the best we can do? Why constrain ourselves to the artificial notion of a sprint at all? Why not pull as much work through the system as our capacity can sustain and optimise the flow so that there aren't any bottlenecks?

One argument is it's necessary to plan and co-ordinate releases. If you only release once a year, it's likely that your release involves several manual steps - it's not worth the investment to automate it. When you release every week you learn to automate everything - the repeating opportunity for fuck-ups means it's just too dangerous not to. When you have a high test coverage and a fully automated deployment why work to iterations at all?

Abandoning iterations means rethinking the planning game. Instead plan on demand (as and when a development pair need a new story). This way you'll know the maximum amount possible and leave your decisions to the last responsible moment. Long planning games are a bad idea anyway. At the start of the meeting everyone's fresh, and will argue a card to death. As brain drain creeps in people lose interest. I don't value estimation either. What's really important is to keep stories as simple as possible and to prioritise them well. While we're on the subject let's cut drop retrospectives too. Sure they provide a forum for continuous improvement but why wait until the end of the iteration to raise a problem and fix it. Waiting isn't an Agile principle that I'm familiar with.

Showcasing individual stories to stakeholders would be pretty hard to pull off, but more importantly doesn't make sense. Demonstrating stories separately would result in loss of context, but just because you keep a regular showcase doesn't mean you have to work to iterations.

Release whenever makes sense for the business. If that's every day, once a week or with a batch of related functionality do it. If you're constrained by external dependencies such as specific marketing dates that's fine too, but don't organise your development cycle to those release dates, go with the flow.

No comments:

Post a Comment