Wait Your Turn

A few years ago, Todd worked with a development team as a Scrum master. The product we were working on was a slick engineering sales tool which was well-liked and well-received by the users. The development team took pride in the quality of their work, the team’s chemistry was great, and everyone genuinely liked working together.

During one sprint retrospective, a mechanical engineer on the team was quiet and looked exhausted, and others noticed that he wasn’t acting like himself. After some prodding by the team, he opened up about what was bothering him:

Every single sprint, you guys race out of the gate, taking on the things that take you a while to develop. I, in contrast, sit for the first few days with hardly anything to do. Toward the end of every sprint, when you all are winding down, I’m winding up and working 16-hour days to test the results of what you’ve developed. It’s completely exhausting.

The software engineers realized he was right. Their opinions completely dominated sprint planning. And when they created a plan for the next 24 hours during the daily scrum, the mechanical engineer was rarely considered. This wasn’t deliberate or malicious—it just happened.

During every sprint, teams should find ways to nonsequentially execute work. A sprint shouldn’t be a mini-waterfall project where each area of expertise has to wait for their turn, like this:

See how coding has to wait for design to finish and testing has to wait for coding to finish? This will cause a lot of grief as the team rushes to finish an increment by the end of every sprint. (We used design, coding, and testing in this example, but your situation may include things like analysis, infrastructure, deployment, and so on.)

Ideally, development teams should be able to nonsequentially execute work, like so:

Nonsequential execution allows the team members to work together as single unit, always considering each other. A single area of expertise doesn’t “own” the plan for the sprint or the day—instead, they are owned by the entire development team and everybody’s input is incorporated. This requires thoughtfulness and consideration, especially for teams that aren’t used to working together.

The solution that Todd’s team (in the example) came up with was brilliant. They decided that the best way to be cognizant of this issue was to further visualize their sprint backlog. They created a “wall of testing” specifically to enhance transparency around the flow of work to the mechanical engineer. The idea was that the visualization would build awareness around the nonsequential execution of work that was necessary to build a good product. They came up with the analogy that the mechanical engineer should be constantly fed like Pac Man. The analogy and the visual board worked great for this team.