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.
Hi Jim,
Thanks for the post.
I’ve seen agile teams get caught in the oscillation cycle you describe. I think that sometimes the customers of the product being developed (not necessarily the end users) become infatuated with the idea that “agile” implies that there is zero cost associated with changing requirements (over and over).
In contrast, within a waterfall methodology, the cost of change is made pretty clear (formal sign-offs, change requests, etc). So, I think that one challenge agile teams face is how to accept the legitimate, market-driven need for change (for which agile is well-suited) while at the same time making the costs (time, money, lost opportunity) of (frivolous) change explicit.
Hi Jim,
Great post, and one I can certainly relate to. I’m managing a team experiencing pretty much exactly the oscillation cycle you’ve described. The team is charged with delivering all the enhancements and defect fixes for a heavily trafficked ecommerce website, and we often find ourselves managing a lot of work in progress. Clean iterations are a rare thing, and I think much of the cause may go back to something you talk about; the participants not understanding the problem.
Having to deal with the entire application stack means we often lack in depth knowledge of the problem area, and spend a lot of time engaging SMEs to illuminate the issue and the path to the solution. With everyone pressed for time and under pressure to deliver on their own work, collaboration is often hurried, and requires us to circle back for additional consults, and so on, with little forward progress. Clearly we need to focus on improving our communications and making these huddles more productive.