Who Should Lead the Scrum Team?

Some years ago, I joined a start-up with the mission of scaling the product up. The challenge motivated me and I was eager to get my hands dirty. On my first day, I had an inspiring talk with the CEO. He invited me for a coffee and we talked about his vision and how the team worked. He told me they worked with Scrum, and I’d be empowered to make decisions to reach goals. I felt confident… up until I got to know the team’s structure.

I took a walk with the CEO around the office and he introduced me to the team.

CEO: “Our bar is high, David. I hope you understand what I mean. Let me introduce you to our QA Lead. He won’t let you push any broken stuff to production.”

Peter: “Hi, David. No worries, we’re going to work as a team. I will help you guarantee a minimum quality level.”

CEO: “Let’s continue our walk. Now, let me introduce you to Jack, our Team Lead. He ensures the team uses state-of-the-art technology. You will need to partner with him to rock.”

Jack: “Welcome to our team, David. Glad to have you here. Let’s grab a coffee at some point this week.”

CEO: “You’ve got to know more team members. Wait until you meet Sally, our UX Lead. She is terrific! And here she is.”

Sally: “Hey David, welcome to our team. I heard a lot about you. I guess we’ll work closely together.”

CEO: “Let me hurry up, I’ve got an investor call in a couple of minutes and you still need to meet Tony, our Agile Coach, and Lavigne, our UI Lead. Ooops, my phone is ringing; I better go. Please, introduce yourself to them. I am sure you will figure out how to get started.”

Honestly, I felt overwhelmed and shocked. The start-up had only two Scrum teams and so many leads. I wondered how the team’s dynamics would work with so many ‘bosses.’ Shockingly, they went against the principles of the Scrum Guide, putting emphasis on title and disciplines.

The Scrum Guide offers the following definition of a team. In bold, you’ll find the critical aspects to me:

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. — The Scrum Guide, November 2020

Scrum has no hierarchies, yet companies love it. From my experience, confusion is the result of teams with multiple leads. Let me walk you through what I learned from leadership inside Scrum teams.

Multiple Leaders = Confusion

In the scenario I mentioned, the Scrum team had several leads inside the team, effectively creating micro-teams and silos. The result was a lack of accountability and multiple discussions creating no valuable outcome; each team lead had a particular agenda. Let me share some examples with you:

• Team Lead: Jack managed software engineers, seven in total. He was a knowledgeable person, but he often hijacked his wishes inside the Sprint. Software engineers had to decide whether to follow the boss or the Sprint Goal, and they generally chose the first option; we often missed the Sprint Goal because the team was distracted by something other than that.
• QA Lead: Peter mastered several techniques to ensure high quality. The team had three dedicated Quality Assurance Engineers led by Peter. However, the “QA team” rejected almost everything three or four times because it didn’t meet their bar. Curiously, the parameters changed Sprint after Sprint and the software engineers didn’t know about it. In short, a rivalry between QA and Devs was created.
• Agile Coach: Tony had several Agile badges and wanted to build a self-managing team, but constantly hit the wall. No matter what he tried, the leads would not follow. He was frustrated.
• Product Owner: I wore this hat and envisioned empowering teams to solve worthy problems. I did my best to foster collaboration, but during the Sprint, people generally took a diversion because their bosses wanted something else.

As you can see, we were anything but a team. We played different games, yet we thought we were doing Scrum. The team had no clear direction with so many leads, and confusion was our result.

Maximizing value was not more than a dream

Something had to change, and it had to happen quickly. The shift started after a normal Daily Stand-up; Tony said, “I need to say a few words.” We were curious and asked him to proceed.

Tony: “Do any of you know what transforms a collective of people into a team?”

Jack: “A common goal, I guess.”

Tony: “Great! That’s one aspect, but there’s another: Common rules. Now let me ask you a question, do you have a common goal?”

Jack: “Of course we do. David crafts a Sprint Goal with us, and we follow it!”

David: “Do you?”

Jack: “Well… There are always some adaptations needed due to our ever-evolving tech debt, but we generally follow.”

Tony: “It means you agree on a goal, and you change what you do on your own accord, without transparency.”

Jack: “Maybe I’ve added some additional topics during the Sprint – but what about Peter, who continuously changes what we need to do to reach his quality standards? That’s also not very transparent.”

Tony: “Let me interrupt you. I think you get the point: We set goals but do not commit to them, and we don’t play the game by the same rules. It seems like our ego is the enemy. Each team lead defines something without even talking to the team. How can we work like this?”

David: “I think we need to step back and agree on how to function as a team instead of a group of people running in different directions. We have all the expertise we need to create value, but something is missing.”

Peter: “Say it. What’s missing?”

David: “Trust. You don’t trust the quality of our developers, and you continuously change how you test. Developers don’t trust Sally and change whatever she proposes; you don’t trust me, Jack. That’s why you steal topics from under me.”

Tony: “Without trust, we have no team. Now, the elephant is in the room, and it’s up to us to solve it or ignore it. Pick your choice.”

After this intense exchange, we had to change how we worked and stop being several micro teams and start acting as a single team.

Becoming a Self-Managing Team

A strong connection to the industrial era is one of the biggest problems of Scrum Teams. Every professional is responsible for a single part and nothing else. Although that worked well with products like cars, it won’t work with software development. Collaboration is vital.

A self-managing team has no hierarchy. The team decides who does what, when, and how. Bosses have no place in such teams; nobody gives orders. However, a team can only become a self-organizing team with high maturity and trust. Here are some traits I have noticed in such teams:

• Clear direction: The team pursues goals instead of delivering a set of features. The Product Owner sets where to land, and together with the team, they agree on how to get there. First, where to go and only then, how to get there.
• Scrum pillars: Inspection, adaptations, and transparency are evident in the team. No one hides anything from anyone. The whole team continuously inspects and adapts to function better as a team, ultimately reaching the Sprint Goal and creating value.
• Decision: The team avoids consensus – it’s not about compromising to please everyone, it’s about getting a commitment from everyone. The most qualified person for the job has more say. For example, a UX Designer is best suited to define the User Journey; even if a software engineer disagreed, she should respect the UX’s decision. A Product Owner is the best person to decide whether or not to make the effort and solve a problem, and if so, how much effort should be given – because she understands the business impacts.
• Agreements: Clarity on how to work together. A simple example is using Definitions of Done (DoD), where the team agrees on what defines an item as done and lives up to that. Whenever the quality isn’t satisfactory, the whole team agrees on measures to change it. No team member would change the DoD without discussing it with the entire team.

When you’re part of a self-managing team, you benefit from high accountability and outstanding results. The team puts in the time doing what matters instead of wasting their energy on pointless discussions.

Trust is the foundation of everything

But what about team leads, what’s their role in it? A great leader helps team members advance professionally and foster an environment of trust. It’s about empowerment, not command and control. Technical Team Leads help software developers improve their craftsmanship; they don’t dictate who does what, and when.

Circling back to my initial question, who should lead the Scrum Team? The Product Owner is responsible for pointing the direction and empowering the team to get there – but she must also focus on leading instead of managing. Command and control has no place in self-managing teams.

“A leader’s job is not to do the work for others, it’s to help others figure out how to do it themselves, to get things done, and to succeed beyond what they thought possible.” — Simon Sinek