Scrum: The Art of Doing Twice the Work in Half the Time

by Jeff Sutherland

Just because everyone has always told you that’s the way the world works doesn’t mean they’re right. There is a different way of doing things—a different way of working.

That training taught me to do four things: Observe, Orient, Decide, and Act. Specifically, I would observe the target area, figure out the best path into the hot zone and the best path out, orient myself in the face of unexpected events, and then act decisively based on instincts and hardwiring. Hesitation could get pilots killed, but so did foolhardiness.

Years later it occurred to me that organizations, teams, and people are all complex adaptive systems. The same things that move cells from one state to another are also what move people from one state to another. To change a cell, you first inject energy into the system. At first there’s chaos, there seem to be no rules, everything is in flux. When you do this to organizations trying to change, people often freak out. They can’t understand what’s happening. They don’t know what to do. But remarkably quickly, just like a cell, an organization settles into a new steady state. The only question is whether the new state is better than the old one. Is the cell cancerous or healthy? How, I wondered, can we figure out some simple rules that will guide teams to settle into a more productive, happier, supportive, fun, and ecstatic state? I spent the next fifteen years trying to figure that out.

Observe, Orient, Decide, and Act.

PDCA cycle (Plan, Do, Check, Act). You can apply this cycle to the production of just about anything, be it a car, a videogame, or, heck, even a paper airplane. When I train people how to do Scrum, that’s what I use: paper airplanes. I divide people up into teams and tell them that the goal is to build as many paper airplanes as they can that will fly across the room. There are going to be three roles on the team. One person will check how many planes are built that can actually fly. Another will work as part of the assembly process but will also pay attention to the process itself and look for ways that the team can make better planes and speed up their production. Everyone else will concentrate on building as many planes that can actually fly the distance in the assembly time allowed. I then say we’re going to do three six-minute cycles of paper-airplane building. The teams have one minute each cycle to Plan how they’re going to build the airplane, three minutes to Do—to build and test as many airplanes as they can that can actually fly. And finally they’ll have two minutes to Check. In this phase the team looks for how they could improve their paper airplane–building process. What went right? What went wrong? Should the design be changed? How can the construction process be improved? And then they will Act. In Deming’s world “to act” means to change your way of working based on real results and real environmental input. It’s the same strategy used by Brooks’s robot. Go ...

Scrum, like aikido, or, heck, like the tango, is something that you can only really learn by doing. Your body and your mind and your spirit become aligned through constant practice and improvement. In the martial arts you learn a concept called Shu Ha Ri, which points to different levels of mastery. In the Shu state you know all the rules and the forms. You repeat them, like the steps in a dance, so your body absorbs them. You don’t deviate at all. In the Ha state, once you’ve mastered the forms, you can make innovations. Put an extra swing in your step down the dance floor. In the Ri state you’re able to discard the forms, you’ve truly mastered the practice, and you’re able to be creative in an unhindered way, because the knowledge of the meaning of aikido or the tango is so deeply embedded in you, your every step expresses its essence.

Whenever there are handoffs between teams, there is the opportunity for disaster.

just because cross-functionality can achieve great results, you shouldn’t play Noah and throw two of everything into a team. The team dynamic only works well in small teams. The classic formulation is seven people, plus or minus two, though I’ve seen teams as small as three function at a high level. What’s fascinating is that the data shows that if you have more than nine people on a team, their velocity actually slows down. That’s right. More resources make the team go slower.

Put simply, Brooks’s Law says “adding manpower to a late software project makes it later.”

Don’t do it. Keep your teams small.

We all perceive ourselves as responding to a situation, while we see others as motivated by their character.

What Scrum is designed to do is change that system. Instead of looking for blame and fault, it rewards positive behavior by focusing people on working together and getting things done.