3 ways to …

Agile transformations often focus on forming agile teams and training teams in agile ways of working. While this is a good start, if you do not know how you are going to manage dependencies between teams you won’t deliver the full potential agile promises. Here are three ways I think dependancies can be managed between teams.

Observe enough agile teams and you’ll come to notice a common anti-pattern that prevents the flow of work - dependencies. A red flag to look for during daily stand-ups are phrase like: “I am waiting on” or “I am blocked by”.

In my experience organisations deal with this dependency problem in three different ways:

• Getting rid of the problem

• Managing the problem, or

• Ignoring the problem

Getting rid of the dependency problem

This is by far my favourite approach. 

Here we eliminate the problem as much as we can, by giving teams as much autonomy as possible. Pioneered by companies like Spotify, Google and Amazon, we architect our solutions and create platforms to enable teams to manage every aspect of their work. Each team has a clear product or area of responsibility with clear rules of engagement and nothing stands in their way. They do not need anyone's help or permission to provision, develop, test and deploy their solutions to production.

So why is everyone not doing this? In most bigger organisations we struggle to get the right technical expertise at a high enough management level to enable this kind of environment. When is the last time you saw an Enterprise Architect and a General Manager designing the ideal organisational structure? To make this approach work, you have to think through your entire business model, devolve operational decision making to the team closest to the problem and trust your people.

Managing the dependency problem

Not as good as the first option, but way better than the last. This is where we actively implement dependency management. 

We make all work and dependencies between teams super visible and management (usually Scrum Master and Product Owners) get together regularly (called Scrum-of-Scrums) to hold other teams accountable for dependencies they own until they are resolved. When teams are not aligned, we need someone with more of an eagle eye view (like a Product Manager) to make the priority call based on business priorities. 

Ignore the dependency problem

The Scrum Guide says: “Removing impediments to the Development Team’s progress” is one of several ways in which the “Scrum Master serves the Development Team”. Unfortunately, this cultivated the misconception that Scrum Master will magically remove all dependencies.

With this approach, I usually see no formal visualisation or coordinated priority of work between teams. It is up to the Scrum Masters or team members, to form a network of contacts within the organisation to get things done for which their teams do not have the skill and/or permission. Introverted people will rely on raising official requests or long email trails, whereas old-style Project Managers will just shoulder tap (which is often more successful in this environment). 

I have seen this approach work as long as everyone is not too busy and there is a culture of helping each other. But when the CEO announces a company-wide initiative that everyone needs to work on (basically overloading the system), all work can get stuck in gridlock.

Obviously, most places implement a mixture of these approaches, but next time you hear someone in a standup say “I am waiting on” be sure to recognise what approach your organisation uses and how to deal with that dependency.