Leading a Self-Organizing Team
First, a brief history of software development. In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published their famous Harvard Business Review Article, “The New, New Product Development Game,” and introduced “Scrum” as something other than sports jargon. One of the big ideas in that article, and in their methodology, is that the entire team must achieve their goal together. No one team member should take on more responsibility for the project’s outcome than any other.
There is, of course, a Scrum Master in the Scrum framework. But it’s no coincidence that the person whose job it is to preside over Scrum Ceremonies is a largely ceremonial figure. The Scrum Master facilitates meetings and discussions and encourages the team to play by its own rules. But the Scrum Master, definitionally, cannot lead the team.
There are benefits to this approach. Research shows that people are more creative and less self-censoring in a team of peers. The lack of top-down leadership is certainly in keeping with the original sprit of Scrum. But there are limitations as well. A Scrum Master who sees that the team’s current processes are resulting in sub-par code, proposes a solution and mentors the team to adherence is probably a bad Scrum Master. He or she is over-stepping. A good Scrum Master facilitates but doesn’t lead.
Maybe those types of changes are best left to the Product Owner. After all, the Product Owner is responsible for setting the vision and ensuring the team knows what to do. The problem with asking the Product Owner to course-correct a Scrum team is that the Product Owner has to exist outside of the team. Otherwise, his or her vital role as a business liaison and advocate for the end-user is lost. A Product Owner who is doing his or her job well isn’t going to be close enough to the problem to see it.
So, if the Scrum Master doesn’t have the authority, and the Product Owner doesn’t have the expertise, whose job is it to build a better Scrum team? In traditional agile frameworks, from Scrum to SAFe to Kanban, the answer is that the team itself is responsible for continuous improvement.
That’s not the way people work. Despite numerous predictions that the workplace of the future will be an egalitarian utopia, the human need for hierarchy persists. Inexperienced people seek guidance from those who are more experienced. Software development methodologies should not ask teams to behave in ways groups of people don’t naturally behave. Scrum, with its focus on servant leadership, does not leave room for people management, but it should.
Scrum needs a new role — not a Scrum Master, or a Product Owner, or a Project Manager, but someone with a sampling of the traits and skills of all three who is first and foremost a people-focused leader.
At Build we call it a Solution Owner. Solution Owner is a title that Slalom coined but it’s a role that exists on every successful software delivery team.
About two years ago, a year into my tenure as a Solution Owner, I wrote a blog called, “The Five Jobs You Have As a Solution Owner.” In the first blog, I compared different aspects of the Solution Owner role to five other jobs: a translator, a diplomat, a therapist, an air traffic controller, and a parent.
As the translator, your job is to make sure everyone from legal to DevOps has a shared understanding of what’s going on. As a diplomat, your job is to make all those different groups, with their different interests and agendas, feel good about what’s going on. As a therapist, your job is to identify and intervene when people don’t feel good about what’s going on. As an air traffic controller, your job is to answer the question, “What should I be doing right now?” And as a parent, your job is to get out of the way and let everyone involved with the project do their best work, secure in the knowledge that if something goes wrong, you’ll be there to pick up the pieces.
Two years later, I still believe that to be true. But it’s still not the whole story.
A good Solution Owner, someone who fills that missing agile role, is also: a writer, a moral officer, a philosopher, a teacher, an actor, maybe even a magician. But mostly, they’re Star Ship Captains.
When I was a teenager, I was deeply obsessed with a series of Star Trek books recounting the adventures of the crew of the USS Excalibur. In one book, there’s a flashback to the captain’s days at Star Fleet Academy in which he and a handful of classmates are charged with winning an intentionally un-winnable space battle. In the Star Trek mythos, it’s a tradition that’s one-part psychology experiment, one-part final exam for Star Fleet Cadets who someday hope to be officers.
The idea of fighting an un-winnable battle is not the part of the story that appeals to me. It’s the way the simulation is conducted. For the purposes of the simulation, roles are assigned at random. Because (and it’s possible this a direct quote), on the bridge, in a pinch, everyone should be able to do everyone else’s job.
Agile needs a Star Ship Captain role. Someone who sets the course, maintains a veneer of calm, makes judgement calls, and assumes responsibility for everything that’s happening around them. When the lights start flashing, they let people scream at them about how the shields are at thirty percent and engines are down to impulse power while they hail the unknown ship that just started firing and try to talk their way out of things.
But the most important skill this mythical third role needs is the ability to do whatever is necessary to keep the ship in the air. It’s the kind of role that transgresses the Platonic ideals of Scrum Master and Product Owner. But in the real world, having someone with insight into all areas of a project who feels empowered to take responsibility for the team and its approach when things are going wrong can make the difference between success and failure.
