Why empowered teams work

Last week I gave a short introductory presentation about Scrum at our company meeting. I explained how the team picks the highest priority user stories from the Product Backlog, and turns them into a potentially shippable product increment during a sprint. The question arose as to who would tell the team how to do this? The answer was quite simple, “No one does“. I briefly described how Scrum cherishes empowered teams. The team members will figure it out themselves, assuming, of course, the team has all of the required skills to achieve the task. The person who asked the question didn’t seem to be convinced. Obviously, I didn’t do a very good job of explaining it. I’ll try again with the following metaphor (I wish I had figured this out before the presentation).

Vision

Imagine two European explorers in the fifteenth century hiring crews to sail to India. Explorer A sends his crew into the woods to chop trees without any further explanations.

Explorer B, on the other hand, gathers his crew and tells them about their goal to be the first to sail to India to gain easier access to their riches (mainly spices). He instills in them a vision of something they can be proud of if they can achieve it.

Which crew do you think is more motivated? Which one will finish their ship first? Exactly, that’s my point. Teams don’t need step by step instructions of how to develop a software product. They’ve done it before (at least some team members should have). They know what it takes. What they need is a common goal to motivate them and the trust that they can do it. If the team members are not entrusted to determine their own work, they will never fully commit to the product vision, nor will they ever feel the desire to make the key decisions that they should be responsible for.

Leadership

A lot has been written about Scrum sprints replacing the traditional waterfall model, but what is less talked about is that Scrum is also about leadership versus management. According to Seth Godin, “The secret about leadership is simple: Do what you believe in. Paint a picture of the future. Go there. People will follow.” “Leaders have followers. Managers have employees.”

Of course this shines a bad light on management. We don’t even let anyone outside the development team speak at our daily Scrums because we don’t trust them not to tell us how to do our job. The team is, therefore, entrusted to deliver the Product Backlog on their own, and managers are (only) expected to assist the team to build the best product possible.

There is no doubt that each group of people needs leadership to achieve a goal. But this is just another one of the skills I mentioned above. There are undiscovered leaders within your team. They might not have the title on their business cards, but they are there. You don’t have to appoint them either, people will turn to them automatically when problems arise.

Responsibility

There is an issue that remains unresolved. I like to call it the “Spiderman Dilemma“: “With great power comes great responsibility“. What if members on your team don’t want to have this responsibility? What if they are too used to their factory life, where they have tasks assigned to them and they can go home after their eight-hour day without worrying about the product they are producing? I am afraid, I don’t have the answer. After all, I guess Scrum is not for everyone. I do believe, however, that these people are the exception. Generally team members like to have some authority over their time and effort and some input into what they do, because it gives them the chance to be proud of the product they create.

So, give your team a vision and the trust that they can achieve it, not a step by step instruction.

The above metaphor was inspired by a quote from Antoine de Saint-Exupery: “If you want to build a ship, then don’t drum up men to gather wood, give orders, and divide the work. Rather, teach them to yearn for the far and endless sea.”

Drawings by Nicole Day.