In this post I’ll try to explain why it’s better not to accept changes or new tasks during an iteration. The trigger for this post is an experience I had a few weeks ago. I worked on a very interesting project, it’s a project with short iterations and a daily demo. The client is amazing – smart, responsive and very creative. The client acknowledges that not everything is known in advance and many changes are expected along the way. So far, so good. However, there is a downside – the involvement can make the feedback loop too short – as feedback gets translated into tasks within the same iteration.
The goal of agile development process is to deliver products in constant throughput, respond to changes and get to the final release with well working software that provides the exact value the client needed. In order to do all that both parties must stay realistic and take the right risks.

What’s required for efficient development?

Estimations

One of the nice ideas in agile is the iteration plan. During the iteration plan the client gets to tell what’s the most important features, the developers get to ask for details and finally estimate how much effort the feature requires. Since iteration plan includes all the developers planned to work on the features, all get the chance to contribute their point of view about each feature. The points of view are what’s the best way to implement (perhaps base the code on existing solution), they can talk about risks (this feature influences the performance, requires redesign, etc.), when everybody is well involved they point on more missing details in the specifications. All these allow us the reduce the risk – we get better effort estimation and we know better if we should expect side effects.
When a ticket is added during the iteration, it’s planning gets less focus – it is either gets planned by less team members or it gets planned by developers who do it while being distracted by the task they’re already in. The result is usually the we get less accurate estimations.

Focus

We all know that in order to get better software we need better code. With better code we have fewer bugs and easier maintenance. A very well known way to achieve this is having the developers code in “the zone” for as long as possible. Being in the zone requires understanding the problem, finding a solution and being able to incrementally implement it. All agile flavors have a good way in getting the developers in the zone. The idea is same – separating concerns. There’s a defined period of time devoted to non-development tasks, like iteration plan, demos, etc. The rest of the time is focused on development, which is known to us as iteration, sprint and so on. During this time the developers get to work on a predefined tasks, tasks which they had a chance to think about for spec (with the client) and technically (during effort estimations). If the developers are required to step into a mini-phase of planning in the middle of the iteration, the thinking mode must go back to planning mode. This is very likely going to cause a loss of focus which leads to less efficient development.

Priorities

This is the simplest part and the riskiest. It is clear that most software being built is limited by real world constraints – money and time. Since we can’t get all the features from the backlog done on the first iteration we prioritize. This means that out of a set of relevant features, we pick the most important ones. Using this simple rationale we get to maximize the value of the developed software. What happens when a feature sneaks into the iteration? Usually it doesn’t really go through the usual prioritizing mechanism. Mostly commonly the reason for adding a feature is either it looks like it can “seal a feature” or it can solve some local problem. Both reasons provide value, but none promise to maximize the value.

What we lose by silencing the chicken?

Summary