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

by Jeff Sutherland

I called this framework for team performance “Scrum.” The term comes from the game of rugby, and it refers to the way a team works together to move the ball down the field. Careful alignment, unity of purpose, and clarity of goal come together.

Traditionally, management wants two things on any project: control and predictability.

Projects are delayed, come in over budget, and, in too many cases, end in abject failure. This is especially true for teams involved in the creative work of crafting something new.

“Inspect and Adapt” cycle.

Scrum is the framework I built to put those values into practice. There is no methodology.

the idea of “flow.” That is, production should flow swiftly and calmly throughout the process, and, he said, one of management’s key tasks is to identify and remove impediments to that flow.

they discuss not what they did, but how they did it. They ask, “How can we work together better in the next Sprint? What was getting in our way during the last one? What are the impediments that are slowing our velocity?”

What Scrum does is bring teams together to create great things, and that requires everyone not only to see the end goal, but to deliver incrementally toward that goal.

It requires practice and attention, but also a continuous effort to reach a new state—a state where things just flow and happen.

Work doesn’t have to suck. It can flow; it can be an expression of joy, an alignment toward a higher purpose. We can be better. We can be great! We just have to practice.

Often when people talk about great teams, they only talk about that transcendent sense of purpose.

Just as critical, but perhaps less celebrated, is the freedom to do your job in the way that you think best—to have autonomy. On all great teams, it’s left to the members to decide how to carry out the goals set by those leading the organization.

One of the key concepts in Scrum is that the team members decide themselves how they’re going to do the work. It’s management’s responsibility to set the strategic goals, but it’s the team’s job to decide how to reach those goals.

What did you do since the last time we talked? What are you going to do before we talk again? And what is getting in your way?

The third leg of the stool for great teams is that they have all the skills necessary to get things done.

What she looks for in a team is diversity—of skill set, thinking, and experience.

When a specialist identifies with their specialty more than with the product they’re actually making, Dourambeis knows she still has work to do.

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

The transparency and sharing of a truly fantastic team threatens structures rooted in secrets and obfuscation.

The team dynamic only works well in small teams. The classic formulation is seven people, plus or minus two,

everyone on a Scrum team has to know what everyone else is doing. All the work being done, the challenges faced, the progress made, has to be transparent to everyone else.

something between a team captain and a coach.

It was the Scrum Master’s job to guide the team toward continuous improvement—to ask with regularity, “How can we do what we do better?”

It’s the system that surrounds us, rather than any intrinsic quality, that accounts for the vast majority of our behavior.

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.

The Fundamental Attribution Error appeals to our sense of justice. If we can blame someone else, we insulate ourselves from the possibility that we’d do the same thing—that we’re just as likely to press that button as anyone else, given the right circumstances.

It’s about setting up the right framework with the right incentives and giving people the freedom, respect, and authority to do things themselves. Greatness can’t be imposed; it has to come from within. But it does live within all of us.

The thing that cripples communication saturation is specialization—the number of roles and titles in a group. If people have a special title, they tend to do only things that seem a match for that title. And to protect the power of that role, they tend to hold on to specific knowledge.

The heart of Scrum is rhythm.

Throughout the business environment especially, we created an acute depersonalization that seems dictated by fate.

“busy-brag”

“Work in Process,” or sometimes just “inventory.” The idea is that it’s wasteful to have a bunch of stuff lying around that isn’t being used to build something. That stuff, whether it be car doors or widgets, actually costs money, and if it’s sitting around on the factory floor, it means that huge amounts of money are bound up in inventory that isn’t actually needed right then.

They looked at the “Matts” across the entire company—hundreds of developers

Any “process” that people use is wasteful, and that includes Scrum.

As I’ve already pointed out, we humans are absolutely terrible at this, but what we are good at, it turns out, is relative sizing—comparing one size to another.

Our minds don’t work in smooth increments. We’re better at perceiving jumps from one state to another—and not smooth jumps but jagged ones.

character or role—for example, a customer, a bride, a reader, an employee. Who is this task being done for?

what—what we want done in the first place.

motivation. Why does this character want this thing? How is it going to serve and delight this particular customer? And, in a way, this is the key part. Motivation colors everything.

Those stories are ones that a team can wrap its head around. A discussion can actually ensue about how to implement them. They’re specific enough to be actionable but don’t prescribe how they’re going to be done.

“definition of Ready” (as in “Does it meet the INVEST criteria?”) and finally “a definition of Done” (as in “What conditions need to be met, what tests need to be passed, to call it a wrap?”).

What can companies do to create an atmosphere in which people thrive? Managers can encourage autonomy by letting people make their own decisions about their job. And they can make sure that employees know everything that’s going on, because, as they put it, “Doing your job in an information vacuum is tedious and uninspiring.” Managers should also have zero tolerance for incivility and never allow an employee to poison corporate culture through abuse or disrespect. And, finally, they should give quick and direct feedback.

The “Wise Fool” is the person who asks uncomfortable questions or raises uncomfortable truths. These workers aren’t always easy to have around, since they can be seen as troublemakers or not part of the team, but they need to be cultivated and used.

It’s not enough just to be happy. Happiness needs to be harnessed to produce results.

With Scrum’s incremental development and delivery, you want to begin with the things that will immediately create revenue, effectively “de-risking” the project.

You want something that is completely Done—that you can show.

The Product Owner needed to be able to deliver feedback to the team from the customer each and every Sprint. They needed to spend half their time talking to the people buying the product (getting their thoughts on the latest incremental release and how it delivered value) and half their time with the team creating the Backlog (showing them what the customers valued and what they didn’t).

When you’re picking a Product Owner, get someone who can put themselves in the mind of whoever is getting value from what you’re doing.

essential characteristics of a Product Owner

One, the Product Owner needs to be knowledgeable about the domain.