If, after a given iteration, something that was considered valuable is found not to be, it’s taken off the backlog or deprioritized. Conversely, a new feature idea might have bubbled up or some other item in the backlog has suddenly gained importance, so it’s bumped to the top of the backlog to be worked on. The use of iterations creates regular checkpoints where the team is allowed to pivot if the context has changed (which it usually has). Context here isn’t just the market context, it includes the team’s knowledge of the product.
Despite their usefulness, teams sometimes use iterations incorrectly, decreasing their effectiveness. Here I describe a couple of patterns in which I’ve seen poor use of iterations.
The Multi-iteration Iteration
Each iteration is meant to deliver customer value. In the context of agile software development, that usually translates into “working software”. Delivering working software using short iterations in the very early stages of a project is extremely challenging because few, small features can make it into the first versions; it’s very easy to fall into the trap of thinking that everything is important, rather than stripping out the non-essential parts.
When confronted with this, many teams incorrectly use iterations as “steps along the way”. What I mean by this is that they create a fat feature, split it into tasks and work on it for a number of iterations. The feature is only complete at the end of all those iterations and is WIP (Work-in-progress), non-working software, before that. In effect, those iterations are just one big iteration, and the team is putting on “agile makeup”. The fat feature could probably be split into a couple of features, each individually valuable and deliverable in a single iteration.
Doing this multi-iteration iteration negates some of the benefits of the iteration:
- since the feature needs everything to be complete, there is little planning to do; teams either skip those meetings, make them really short or spend them talking about something else;
- since the feature will only be delivered at the end of the multi-iteration, there is no external feedback until the very end. This leads to a distortion of the team’s view of the world: everything seems fine until the last “iterations”; then, the team realizes something is missing and has to work harder to catch up.
Feature Handoff
A similar trap is handing off features between teams. An example would be having the backend team creating the services that the frontend team will consume. Thus, the backend team works on the services for an iteration and delivers working software. Then, the frontend team creates the frontend using the services for an iteration and delivers working software. This seems agile, since software is being delivered; but consider the scenario where, while implementing the frontend, that team had to work around some issues with the services from the backend team. These are added to the backend team’s backlog to fix, so they fix them in the next iteration; after that the frontend team can take advantage of the fixes. The feature could probably be delivered faster if it was worked on within the same team, on a single iteration.
This was, in its essence, a rant against the cargo cult of iterations as a means to “becoming agile”. The two examples I’ve presented illustrate that good use of iterations implies good backlog management and value stream mapping; they’re not a “for agile, add water” kind of technique.
