Agile methods work because they optimize the flow of work through an organization while focusing on delivering value early and often. Improvements to human communication and interaction are layered on top of the fundamental work flow, but much of the difference between agile and traditional methods is due to the way in which the flow of work is managed.
Your development process basically is a system or machine for turning ideas into saleable stuff. You might define your “stuff” as user stories, features, or something else, but fundamentally each piece of “stuff” is something that delivers value to somebody – preferably someone who will pay for this.
These pieces of “stuff” are grouped into batches, where all the stuff in a batch moves in lockstep through the series of activities which make up development. Requirements, design, coding, testing, integration, deployment – you know the drill.
In traditional methods, all the “stuff” moves together in one enormous batch through all the activities. No feature can be coded until all have passed design freeze. No feature can go to testing until all have been coded. Because the batch size is so large, feedback is very slow. Bugs in a feature are not found until months after it has been coded, you don’t know what the customers think of the features, and you don’t have much feedback on how long it will really take to finish a piece of “stuff”.
In agile, the “stuff” is split into small batches of several weeks. Each batch proceeds through the activities separately. The smaller batches cut that feedback loop down immensely, and the total cost of dealing with the feedback is also cut dramatically. Even better, it may be possible to ship a batch and collect payment as soon as the batch has completed.
The small batches have other benefits as well –
- End date can be predicted accurately partway through the program.
- If it becomes obvious that not all the “stuff” can be finished, it is easy and cheap to eliminate ones that haven’t been started
In short, one of the main reasons agile works is because the work has been split into small batches and each batch is finished before another batch is started.
There are other reasons, which I will discuss in future blogs.
- Cadence: Why a Regular Rhythm is Valuable
- Why Should You Limit Your Work-in-Process?
- Making Progress Visible
- Predicting End Date of a Program
- What’s My Batch? I’m not writing software – do I have batches?
- Cadence: Why Sprint Length is Not As Critical As You Think