In the previous parts (link to part 1, link to part 2, link to part 3), we focussed on why you are a Scrum Master, what to do when you land into your new work environment, how to set up a framework that creates a healthy routine for the team, and how to develop the discipline that will make a team’s performance predictable. This time, we will see how to make the team as self-organised as possible.

Trust the Experts

The traditional way of organising the workforce is to centralise command. One head makes the decisions and tells others what to do. It seems a good way to reach consistency and predictability, perhaps. Yet, it also creates a major key-person dependency: what if that central commander is not available? What if there are too many decisions to make in too short a time for a single person? What if they are not qualified to make a decision in particular?

Another traditional view is that someone in command must be able to do the job of any and all of their team members. That idea was probably always flawed, but it is especially unrealistic in the tech industry. The range of technologies is unprecedented and they all evolve rapidly. No-one can seriously claim to be an expert in each of them.

The expertise of someone in a management position should instead be the ability to assemble a team of experts in the relevant technologies. That alleviates the key-person dependency.

As a Scrum Master, you have to surround yourself with experts to whom you can delegate the technical-decision-making, and whom you trust with the outcome. Respect their expertise.

Empower the Team

Sometimes, your team of experts will be stuck at a crossroad, not knowing which path to follow. Should they opt for cloud provider a, b or c? Which message-queue system should they implement? Should they follow a model-view-controller approach, or microservices instead?

The obstacle may be that the team members lack the authority, the experience or the confidence to make a choice. It could also be that they are waiting for an architect to make those decisions for them. Often, that results in delays and indecision, both of which are enemies of delivery. How do you counter those enemies?

Enable and encourage the team to make decisions

What is the most suitable technology to solve a specific problem? What are the security requirements? How should we integrate with this or that component?

Those questions are not for you to answer. Task the team with finding out the answers. If those answers are not forthcoming (e.g. an architect is not making design decisions; a security officer is not defining the security strategy; a consumer of your service is not giving a clear steer), have the team spike the options to determine the best one. If requirements are nebulous, let the team investigate what is needed. Inform your stakeholders of what you are doing and why. Your client will see that as a positive initiative to remove the blocker, and your team will gain confidence, as well as respect for you for trusting them.

How do you know you can trust the team? Well, in most cases, you do not. Take baby steps. Give a little trust, see how it goes. If it goes well, trust the team with something bigger. If it does not, try again with something smaller. Let them make mistakes and learn from them.

Expect disagreements and tensions in the beginning: that newfound trust may trigger egos to surface, and the individuals may not be accustomed to dealing with that. Invite constructive debate and challenges of opinions. Facilitate the debate, if you need to. Use your conflict-resolution skills.

When the team is ready, push them to engage with a stakeholder whose decision they are waiting for. Let them first take part in the conversation, then lead the conversation, and, finally, influence the conversation. In some cases, the team may even force decision-making. Ensure they capture the outcome and raise the appropriate tasks. Then, implement and deliver. If the solution turns out to not be what was needed, whoever should have made the decision can now give a new steer; at least, the deadlock has been removed… and the team has gained some expertise in the process.

Lead

As we saw previously (link), as the Scrum Master, you are the team’s servant leader. But what is leadership anyway?

There seem to be two schools of thought on that subject. The dictionaries give us these vague definitions:

“The set of characteristics that make a good leader / the position or fact of being the leader” (Cambridge Dictionary)

“The state or position of being a leader / the ability to be a leader or the qualities a good leader should have / organization” (Oxford Dictionary)

“Someone’s leadership is their position or state of being in control of a group of people. / Leadership refers to the qualities that make someone a good leader, or the methods a leader uses to do his or her job.” (Collins Dictionary)

Some of them go further and tell us that “strong leadership is needed to captain the team,” though none explains what strong leadership is, or what the qualities are that a (good) leader should possess.

The second school of thought seems to stem from the IT industry, and spends more effort defining what good looks like:

“Embedding the capacity for greatness in the people and practices of an organisation, and decoupling it from the personality of the leader.” (David Marquet)

“Leadership is the art of motivating a group of people to act toward achieving a common goal. / Leadership captures the essentials of being able and prepared to inspire others.” (Susan Ward)

“The true leadership definition is to influence, inspire and help others become their best selves, building their skills and achieving goals along the way / The ultimate definition of leadership is empowering others to become effective leaders as well.” (Tony Robbins)

It all really boils down to how one understands leadership. As outlined above by the dictionaries, the traditional view is that the leader is the (sole) decision-maker, centralising command in one head. The main advantage of that view is the consistency of the decision-making process. The main disadvantage is that it puts a lot of faith in the capabilities of the leader and none in the followers’. Likely long-term consequences are burn-out for the leader and brain-drain for the team members, who will not feel appreciated.

The second, perhaps more-recent view sees (some of) the decision-making devolved to parties who are technically best equipped to make those decisions. The main disadvantages are that, if things go well, it is the team’s success, and the leader cannot take credit. On the other hand, if things do not go well, then the leader takes the blame for the decision made by the team. The full list of advantages is too long to enumerate; let us restrict it to two major points:

1) Team members are more invested in the success of the team, and 2) The leader frees up the time previously needed to keep up with technology advancements and making every single decision, and can focus on leading the team and communicating with the client instead.

A Scrum Master who wants to be successful simply cannot realistically be a leader of the first type. The Scrum Master is not in charge, but responsible for those in their charge. The Scrum Master is not responsible for the job; the Scrum Master is responsible for the people responsible for the job.

If we simplify, your only managerial mission as a Scrum Master is to find out how you help the team members reach their natural best.

Next time, we will talk about how you can sharpen your saw.