The two keys to building a successful, empowered Scrum team

Let’s be honest, many companies do not implement the best practices of agile, lean, or other frameworks as they were intended. Organizations, human nature, and processes get in the way of the best intentions. Thus, companies often end up with a suboptimal implementation. The techniques are often not able to develop their full impact. 

Attempting to establish a Scrum team or other agile practices often starts with a single person tasked to do so. This usually happens within an organization that is used to some other way of working, significantly increasing the challenge for this individual. Nevertheless, some excel. Many don’t. 

To me, there are two key things to do at the very beginning of the team’s inception that have an outsized impact on the chance of success: negotiating clear outcomes and minimizing dependencies.  

The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 

The keys: clear outcomes and minimal dependencies

In case you are a Scrum Master or a Product Owner in charge of a team trying to implement Scrum in a traditional organization (think large corporation), these are THE two things to focus on first. Let me explain why that is the case before giving some suggestions on how to go about doing so. 

(Btw, In this context I am referring to Scrum teams, since this is where I have the most experience but I would argue that what I am writing can be applied to almost any team attempting to implement something new within an established organization.)

Clear outcomes means the team is empowered to define the solution

Negotiating a clear outcome for the team to achieve is probably the single most impactful prerequisite in empowering said team. I have addressed the topic of outcomes vs. outputs a few times already. I will try to keep it short for now.  

Thinking in outcomes instead of outputs is what makes roadmaps successful. Thinking in outcomes is the hallmark of good goal setting, using OKRs or other techniques. Outcomes are at the heart of the continuous product discovery process and at the core of successful product teams

Negotiating a clear outcome means the organization is willing to define a target state. More importantly, it is willing to leave the manner of reaching that target to the team. This is empowerment. The team will come up with more creative solutions, display increased ownership of the product, motivation and happiness within the team will increase. 

Minimal dependencies enables the ability to move fast

The goal of a Scrum team – actually for any successful product development team – is to build small product improvements and frequently get these increments in front of customers. In an uncertain environment, the team can then gather feedback and adjust its course of action. 

You can only do this rapidly if you are not constantly having to align with other teams. That’s why it is so important to minimize dependencies to others. This is true for technical dependencies within the product (i.e. interfaces between product components), dependencies in the process (i.e. interfaces between teams where information gets passed), and dependencies within supporting systems (i.e. shared tooling).

The less dependencies the team has to others, the less alignment is needed. It can also optimize the process, tooling, and in the end the product to its specific circumstance. All of this means the team will be that much faster in reaching the desired outcome.

How to negotiate clear outcomes and minimize dependencies

All of the above sounds great in theory (I hope 😉) but is not necessarily easy to achieve in practice. Let me try to offer a few pointers on how to get to a manageable state. Again, I will start with outcomes and then get to the dependencies.

Negotiating clear outcomes is reliant on trust

The key to aligning clear outcomes for a team is trust, such a fuzzy topic that so often seems to have an outsized impact. Negotiating an outcome means the organization and leadership gives a goal to the team but leaves it up to the team how to reach that goal.

They trust the team to come up with the best solution for a given problem.

The reason leaders or an organization wouldn’t want to do that is a lack of trust. They are worried that the (always scarce) resources are spent on the wrong things. In such cases, they will frequently prescribe features for the team to implement instead of giving problems to solve. The team becomes a feature team of mercenaries.

The change in mindset from outputs to outcomes requires persistent effort. It’s easier to achieve the better your standing is. If you are in charge of setting up this team, the good thing is that someone asked you to do this. This means, at least a base level of trust is present. Use this base level of trust to explain the benefits of only setting a clear outcome and leaving the HOW of the solution up to the team.

It will lead to better solutions, more ownership of the solutions, higher motivation, a happier team and in the end less work for the leaders, since they don’t have to dive into the details.   

Two approaches to negotiating clear outcomes

There are two approaches to take in negotiating. Depending on your standing (and personality), you can simply refuse to take the role if the organization doesn’t leave the solutions to the team. Alternatively, you can start with a non optimal set-up and constantly work to change that by showing progress and gaining trust over time. 

I have generally fared well with a mix of the two, tending towards the latter. Outright refusing the role might be more effective and I have utmost respect for people who are able to do this. I am usually unable to do so. For me, in situations where the level of trust wasn’t sufficient in the beginning, just putting our head down, building some momentum, showing some success, and then continuing to negotiate worked out very well. 

Regardless of the approach, remember to explain, often…very often, why it is overall beneficial for the organization to only define the desired outcomes. Perseverance pays off in  the end.

Dependencies can be removed or their impact minimized

In terms of dependencies there are two things to consider, removing dependencies altogether and minimizing the impact of dependencies that cannot be eliminated. 

As a reminder, I am referring to technical dependencies within the product (i.e. interfaces between product components), dependencies in the process (i.e. interfaces between teams where information gets passed), and dependencies within supporting systems (i.e. shared tooling).

Removing dependencies means more responsibility

At least for dependencies on the product and process level, eliminating dependencies usually means additional responsibility and effort for the team. Sometimes, you may find a clever solution to change the product components or the process in such a way that the dependency is removed without extra effort. 

More often than not though, removing the dependency simply means moving additional product functionalities or additional parts of the value stream into the team. This added responsibility is usually accompanied by increased effort. 

This is ok, though. I tend to generally prefer increased responsibility to more dependencies. The increased effort will pay dividends in massively reduced alignment and communication work down the road.

Removing dependencies within supporting systems does not come with the same cost. It’s fairly simple to e.g. get the team’s own Gitlab project, space for documentation, or file storage.

Overall, in the case of a Scrum team embedded in a large corporate organization, I tend to advocate for getting as much separation as possible. Your way of working will be much different. Optimize for the team’s needs wherever possible so that you can iterate without having to align with others. 

Minimizing the impact of dependencies means clear contracts

Unfortunately, you will very likely not be able to remove all dependencies to others. You need to deal with the leftover ones. Clearly defined responsibilities and robust contracts that define the interfaces are needed to make this as efficient as possible. 

In terms of product, this means well documented APIs between software components and clearly defined interfaces between hardware components. These contracts need to be in such a way that they cannot be changed easily. If changes are applied they need to be non-breaking. The above may seem obvious to some as good development practice, but it is so often not done well. 

In terms of process, make it as explicit as possible at what point in time and in what format information or other output gets passed between teams. This needs to be unambiguously clear between involved parties. Write it down!

Break glass in case of need

There are two things still worth mentioning. One, don’t lose hope if the situation is not as it should be. Just because outcomes and dependencies have a large impact doesn’t mean that you can’t be successful without the ideal set-up. I have been in plenty of situations where that was the case. The best medicine in this case is creating small success stories that are parlayed into a better set-up.

Two, there is one last joker you can pull. After all, someone in the company wants you to set-up a Scrum team within the established organization. This is a significant investment of resources. This means there is someone, usually with significant power, that made this decision. By default, you often have a powerful ally. Use that person! 

In his recollection of creating the first iPod within his book Build, Tony Faddell mentions how the “organizational antibodies often attempted to expel the iPod team from the organization”. In a few cases Steve Jobs would give “air cover and drop bombs if anyone messed with the team”. The language might be too martial for some. Nevertheless, stealing ideas from the team building the iPod and breaking that glass in case of need doesn’t seem like the worst idea…

Coverphoto by Brett Jordan on Unsplash