April 16, 2021


News for Agilists

Mistake-proofing Your Product Development with Scrum

Like the Poka-yoke concept, the fundamental characteristics of Scrum help us reduce mistakes. Scrum provides a framework that allows us to avoid common snares. And it draws immediate attention to problems when we can’t avoid them.

Shutting Out Mistakes

Scrum has several mechanisms for preventing errors. We often overlook how powerful, simple, and effective they are.

“There are four purposes of improvement: easier, better, faster, and cheaper. These four goals appear in the order of priority.”

— Shigeo Shingo

The Power of Small: Scrum is all about small. The team is small. The product Increment is small. The Sprint timebox is small. And small is good. Small increases learning, teamwork, shared understanding, flow, feedback, and happiness. It decreases errors and helps you find and fix errors when they happen.

Self-organizing Teams: The power of placing problem-solving in the hands of your team is significant. Bringing all minds to bear to solve problems beats relying on a single person to make all decisions. The team is closest to the work and they are best equipped to decide. This reduces error.

Cross-Functional Teams: When a team has all capabilities to deliver a releasable Increment each Sprint, great things happen. They avoid dependencies and hand-offs. And they are also not relying on one person’s knowledge to direct them. The power of the team is strong. This all works to eliminate large amounts of waste and errors. It feels like magic.

Definition of Done: The Definition of Done is like the Contact, Constant Number, and Sequence Method of Poka-yoke. It defines what needs to happen for an Increment to be potentially releasable. This avoids confusion on what Done means. It also signals what obstacles are in the way of achieving a Done state each Sprint. It is a powerful tool.

Visualizing the Work: We use many tools in Scrum to visualize the work. These visual tools create awareness both to prevent and detect problems. The Product Backlog and Backlog Refinement help you inspect the amount of work, align on its priority, and understand users’ needs. The Sprint Backlog visualizes the work needed to achieve the Sprint goal. And it alerts you to impediments and dependencies encountered during the Sprint. Information radiators can highlight the burndown or burnup of work and cumulative flow.

Focus: Scrum provides focus through the Product Backlog, Sprint Goal, Sprint Backlog, and Sprint Events. This focus eliminates errors and waste due to context switching.

The best processes protect us from mistakes and prevent them from happening at all. Scrum has many of these. But it also alerts us to problems fast when they slip through the cracks as described next.

Drawing Attention to Problems

It is inevitable to have problems in the complex world of product development. Where Scrum does not prevent error, it reveals where problems exist. Transparency, inspection, and adaptation work to highlight and fix problems.

Scrum is founded on empiricism. Three pillars uphold this: transparency, inspection, and adaptation.

The Scrum Guide

The Scrum Events provide a mechanism for enabling the empirical process. They are the heartbeat of Scrum, and they support Poka-yoke.

The Sprint is a consistent time-box of one month or less for creating a releasable product Increment. The Sprint provides the construct for transparency, inspection, and adaptation in Scrum. This construct acts as a feedback loop for the product Increment and for the way the team delivers the work. A short Sprint timebox results in a faster feedback loop. A shorter Sprint facilitates more rapid learning.

Sprint Planning is not often seen as a tool for empiricism, but it is. It makes transparent the details to deliver an Increment to meet the Sprint Goal. To support inspection and adaptation, the team pulls key insights from the last Sprint Retrospective and Sprint Review to improve the delivery of the Increment. When the team encounters planning obstacles, they pivot and make tradeoffs with their Product Owner.

The Daily Scrum allows the team to inspect and adapt its progress toward the Sprint Goal. And it makes transparent any obstacles in the team’s path that threaten the achievement of the Goal. Impediments are immediately raised and addressed by the team. Burn-downs, burn-ups, and other information radiators provide visual cues to the flow of work or the presence of a problem.

The Sprint Review provides a forum to inspect the delivered Increment and identify improvements. The regular frequency of this feedback loop is crucial. It allows for the rapid identification of problems. And this allows you to pivot product direction as your context and understanding evolve.

The Sprint Retrospective is an obvious event for identifying improvements to mistake-proof team behavior. On a regular cadence, the team inspects the way it works and identifies an incremental improvement goal for the next Sprint. This allows the team to address any kinks in team behavior and build a better team over time. Problems are not left to fester.

The transparency of Scrum can be uncomfortable at first. And you may find the number of problems revealed to be large and tough to eradicate. This is why The Scrum Guide says Scrum is difficult to master.

“A relentless barrage of ‘why’s’ is the best way to prepare your mind to pierce the clouded veil of thinking caused by the status quo. Use it often.”

— Shigeo Shingo

The alerts provided by the heartbeat of Scrum Events allow you to uncover problems early. It focuses your attention. Take action to adapt and eradicate these problems. As a result, you will reduce later, more costly mistakes. This is the power of Poka-yoke to put your attention on problems that need fixing.

Source link