...a person or a team (any team) is trying to change for the better, either in what they build or how they do things.

✥       ✥       ✥ 

If you change multiple things at once, it’s hard to know which one led to an improvement.

Reflections of any kind generally lead people to propose many possible kaizens (incremental improvements; see Kaizen and Kaikaku). After all, every team has many challenges. Some may owe to lapses in execution or understanding, while some relate to constraints that frustrate straightforward progress. It is natural to want to fix all problems; we all strive for perfection.

However, we can’t always fix everything. It takes too much energy, and if we try to improve everything, we will improve nothing very well. In addition, trying to solve multiple problems at once often gives disproportionate focus to process concepts like priority ordering and scheduling. Every minute focusing on administration is a minute not spent improving the product and process. If we try to improve many things at once, our context will continuously be shifting from one concern to another. Most people do not do that very well ([1]).

Candidate improvements are often interdependent. Any change is highly likely to invalidate any current baseline. Making one improvement may change the team’s dynamics such that another improvement is superfluous or even counterproductive. Making multiple changes may cause unneeded work or work at cross-purposes.

Therefore:

Attempt one improvement at a time, incrementally. “Improvement” can be a change to the product itself, to the assembly line and tools, to the team’s development, or to the development process.

Make sure that the work queue (Product Backlog, Impediment List) is ordered (1, 2, 3) rather than categorized (“must have,” “should have,” “want”). Categorized lists give management and other stakeholders the expectation that the team might attack the work items in parallel. Let management artifacts clarify that the entire team will attack one item at a time. However, use common sense. If there are small items on the list that don’t require the attention of the entire team together, and the items are independent, then it may be reasonable to tolerate a modicum of parallelism.

If the work queue is fundamentally unordered, as the Sprint Backlog might be, the team should still work on a single cohesive change at a time. In the case of the Sprint Backlog, the team works together on all Sprint Backlog Items that contribute to a common, single Product Backlog Item. The associated product changes should normally attain the state of Done (see Definition of Done) before the team moves on to the next Product Backlog Item (PBI). See Swarming.

With care, the team can pursue a change from each of several decoupled domains in parallel. For example, there is unlikely to be confusion from pursuing a process change in parallel with a product change. “Unlikely” does not, however, mean “none,” and the team should keep its eyes open if such entanglement threatens the measures one will use to gauge the success of one, the other, or both.

The team should size changes so they quickly can be enacted and, in the best cases, so the team can quickly assess their contribution (see Small Items). If a given development or initiative will accumulate value only over a protracted period of time, inspect and adapt—but do commit to objectively evaluating the results of the effort at an appropriate, specific date and time. A Product Backlog Item annotation is a good place to record this commitment that the team makes to itself.

In the phrase “improvements to the product,” the team should interpret the term improvement in the narrowest sense. If the product currently helps its user a certain way and the provider changes the product to make it more convenient to achieve the same result, or if the provider improves the result, that is an “improvement.” Adding a new feature is informally said to be “improving” the product, but customers can just ignore additions above their ability to absorb. That doesn’t harm the market but does mean that the vendor is producing product that no one ever uses. This is not a true improvement: it adds little or no value. The Toyota culture holds that overproduction is the number one cause of waste.

✥       ✥       ✥ 

Completing one thing at a time tends to reduce the amount of almost-Done work. It also helps the team—and the stakeholders—better understand the current status (as in “deliverable” or “fixed” or “operational”) of production. It also helps manage expectations about work not yet completed (that all work is in progress hardly means that the team will complete everything by some deadline).

Focusing on one thing at a time and doing it well, taking it all the way to completion, bodes much better for success than trying to do several things at once. It takes discipline to intentionally decide to not do something that you think will be of benefit, even if another improvement effort is already committed. Short iterations help. For example, a Sprint is a short iteration that provides opportunities for one process improvement at a time.

See Testable Improvements for additional information about selecting improvements.

This is also about being safe from the effects of multiple changes. For an example, think about rock climbing: when you make a move, you change only one hand or foot position at a time, leaving the other three points on the rock. You can then explore a range of new handholds or footholds while maximizing safety with three points of control. So it is with development: we maintain a base of a product that works, or a base of practices that are known to work, while exploring the next product development or process improvement.

That the team focuses on only a single item at a time lies at the very foundation of Scrum; it is the basis for all continuous improvement. It is at the heart of teamwork. Contrast this approach with alternatives that micromanage work in progress, to optimize “resource” expenditure.

Some constituency should review every change with an eye to whether it needs additional work, or whether the team can move on. This responsibility typically falls either to the Developers or the Product Owner, but the decision may involve other stakeholders such as management or customers. Use common sense, as long as the Product Owner maintains final authority over product content decisions and over the ordering of feature rollout. Process improvements should enjoy all the scrutiny normally accorded them at a Sprint Retrospective, striving for objective value-related measures where possible. Because of the risk of not being able to separate out the specific cause of a given improvement in value, interval, or quality, a team should normally undertake a single process improvement per Sprint. The Sprint provides the associated review cadence. If the Development Team takes two process improvements into a Sprint, it should normally undertake only one at a time, scrutinizing and reviewing results from each one carefully before moving on to the next. See Kaizen Pulse for more in-depth consideration of this issue.

One Step at a Time isn’t so much a pattern you apply as it is a way to apply patterns. Christopher Alexander explained that the journey through a pattern language happens one pattern at a time. Select one pattern and apply it. If it works, move on to other patterns that may make the system better. If not, back it out and apply another pattern ([2], p. 216). One way to view One Step at a Time is as a guide for using patterns.

This principle pervades many other Scrum patterns and practices. Whack the Mole suggests fixing problems as they arise, which implies fixing them one at a time. In software projects, the discipline of continuous integration encourages rebuilding and testing the software for each change, rather than batching changes together. This not only reduces the magnitude of changes that affect other developers, but also isolates emergent problems to the single change in progress. It smooths out flow. In Good Housekeeping, the “step” of One Step at a Time is a single day. The end of each day should bring some sense of closure. Scrumming the Scrum also suggests a single process change at a time.

This pattern works well when the team can enact each change independently, or when the team can serialize their enactment. While the approach can work in complex systems, it cannot work well, or at all, when the respective changes have complex cause-and-effect relationships between them. There are important areas where it does not make sense to do One Step at a Time but rather to work in several areas at once, as a team, while continuously monitoring feedback between the changes. The Scrum tradition is to delineate the separable items as Product Backlog Items, and the necessarily concurrent items as Sprint Backlog Items. For example, the human interface of an object-oriented program and its underlying object model both reflect the same fuzzily understood end-user mental model. The design of a new feature in an interactive, object-oriented system might be a PBI, but the work on the code for the objects, and the screen design, and the business logic might be concurrent tasks broken down from the PBI as Sprint Backlog Items. Each evolves in response to requirements that emerge from work on the others. So while Scrum advocates the development of a single small feature at a time (at the level of PBIs), it nonetheless advocates that design, implementation, and testing (of any single deliverable) should be concurrent activities (at the level of Sprint Backlog Items). This is the main rationale behind Cross-Functional Teams and Swarming.

[1] Jerry Weinberg. Quality Software Management. New York: Dorset House, 1991.

[2] Christopher Alexander. The Nature of Order: An Essay of the Art of Building and the Nature of the Universe—Book 2, The Process of Creating Life. Oxford, UK: Oxford University Press, 2006, p. 216.

Picture credits: Pixabay.com (under CC0 license).