Oscillation versus Iteration

Short iterations can cause Agile teams to lose focus and begin oscillating rather than iterating. This can happen from several perspectives—business, technical, user—and it’s something that Agile teams need to be aware of and guard against. When customers change their minds on an user interface issue over and over again—oscillation may be the issue. When developers skip from one design to another over and over—oscillation may be the issue. When product owners churn stories into and out of an iteration—oscillation may be the issue.

Iterations converge on a completed story, feature, or objective. Oscillations send us back and forth between states with little forward progress. It’s difficult at times to tell the difference, but when an oscillating situation seems to be happening, someone needs to stand back and say, “stop.” This is the time to stop and re-evaluate the situation. Two typical problems are: 1) the participants don’t understand the problem, or 2) the participants have different opinions about the solution. In either case, continuing on won’t resolve the issue.

Often the problems arise from not having a well-defined context for the work, for example, not having a good theme for an iteration or release. When discussions about a particular story (how much functionality it should deliver for example) seem endless, then maybe it’s because the team doesn’t have an anchor point in terms of what they were trying to accomplish during the iteration. When two developers are endlessly arguing about a design approach, maybe it’s because the team failed to set basic design guidelines.

Teams without release plans often oscillate in iteration planning because they lack the overall theme and context of such a plan provides. I once worked with a cell-phone software team during a particularly volatile time in the industry. Standards were changing and manufacturers were changing their requirements frequently. The team felt that they were going in circles—and their solution was to freeze requirements. Unfortunately, that would have been disastrous in the market. This was a case in which changes, while seemingly oscillations, were just normal for the industry at that time. The company did need to adapt to these changes and iterate towards a solution. By going back to the business objectives for the project, in this case the multitude of changes were justifiable.

So separating oscillation from iteration isn’t always easy, but it’s a skill that good Scrum Masters, project managers, iterations managers and teams need to cultivate.