Earlier in my journey as a coach / delivery consultant, I thought that agility can be achieved through a “high performing team”. Many agile coaches, scrum masters, delivery leads / managers etc have tried to achieve this kind of thing through making a great team. This might work really well in a small organisation, but once you get to medium to large size organisations, this is not necessarily where the key problem is.
In more recent years, I’ve observed how critical it is to bring various groups together to achieve an outcome. The solutions to some problems are larger than just one or two teams and create interdependencies for delivery. Often, the points of waiting and even friction occur where these interactions are necessary.
Problems with “High Performing” teams
A high performing team works great when all of the dependencies are contained within the group. This could be a single team or a “Service Team” which I see as a larger group or “team of teams” providing a service (eg five 10 person teams working together). Often this team have optimised the interactions within the group and have a fairly well known way of working.
Where this group needs to interact with others in the organisation, it can run into problems. Other groups may have their own way of working which may be similar but is often times different. Relationships between members of the different groups may not be very deep or perhaps non-existent.
Additionally, I’ve seen in the past where teams are “high performing” this can increase the silo mentality and start to create a blame culture. That is, they don’t want to be seen as a non high-performer and become insular and in some cases arrogant. They can call blockers out up and downstream, but don’t want to spend their time being “unproductive” by relieving the blockers. If it goes unmanaged, you can see them pull in more WiP in this circumstance while they wait , which creates further problems.
It may be that they don’t have the skills to go upstream / downstream to help relieve the overall system. Thus they continue on with solving “their part of the problem”, but the overall tends to suffer.
Take, for example, a mobile development service team. They may make regular (eg monthly) improvements to the mobile application / device for your organisation which they can do entirely by themselves. Then at some point your organisation wants to launch a whole new feature not previously seen. You want to showcase this at an upcoming trade fair to generate the largest possible market interest in a short amount of time. Your mobile team will need to work with the marketing team and sales teams to ensure you can maximise the revenue opportunity at the trade fair. They may have rarely done this before, thus the interaction is unusual but critical for the overall business success.
Nature of work in large organisations
Your organisation is a network of interdependent services that act together to serve your customers. This is really an adapting, changing, organic ecosystem if it’s running effectively. External stimuli (customers, markets, competitors) will place new demands on the ecosystem and it’s long term success is based on it’s ability to adapt to that stimuli.
In larger organisations, there may be some interactions between groups that are consistent / regular (work together on many / most initiatives), others may be occasional (eg once or twice a year) and others may be a “one off”. For those that are consistent or occasional, you may be able to predict this to a certain extent. Even if you can predict the frequency of the interactions, the nature of the individual interactions may be quite different.
Oftentimes, the really high value work will mean that this kind of work likely doesn’t have much / any connection to previous work so you’ll need to establish some relationships from scratch.
Possible Solutions
Understand the network
Sometimes to get this understanding you may need to visualise the work and “how work works” as it traverses the organisation.
Where it is at all possible, it would be worth gathering some data about the network to understand the interactions. You can see where the common links are that you want to strengthen and how you may wish to make changes. You may also wish to gather data on where wait states and blockers are in the overall workflow. You may wish to introduce a cadence like Kanban’s “Operation’s Review” to continually monitor and adjust.
Protocols
The internet is a classic example of a network that grows and changes over time, but the fundamentals of how nodes communicate with one another is governed by some simple protocols. You can set this up as basic systemic policies to allow for simpler communication and coordination around the network.
Cadences
Sometimes cadences can work to help with synchronising groups. However, beware of this becomes sometime they can be a source of waiting / waste. For example, if you have a quarterly planning cycle, you may not want to wait that long for a new, urgent piece of work.
Reorganise teams
This really isn’t really viable in the short term – with different work coming from different sources it often doesn’t make sense to continually reorganise. Furthermore, there are costs associated with doing so – there will be a period of inactivity, plus you’ll lose the benefit of previous metrics for that team as it establishes it’s new identity / way of working. If in the longer term you see a continuing pattern of teams working together, you may want to take action at that point – just wait until the reason is compelling enough to justify the cost.
Remove dependencies
This is something that you should always consider, however in larger more complicated work, this is not always practical or possible. You may achieve this by slicing work into more narrow / succinct areas of scope to avoid the immediate need for a dependency. This can also be achieved by changing a technical need for the dependency.
Coordination specialists
Some people are natural connectors in organisations, knowing who to contact / bring together to help solve problems. You can use these folks to help guide work through the network, facilitating the creation and maintenance of connections where required.
Team Member Swap / injection
While complete reorganisation of teams may be too disruptive, you may wish to consider injecting a member from one service team to another to act as a bridge for a particular initiative. This could also take form of a swap where team members are exchanged from each group. This will help build a deeper understanding of the other groups context which will make this and future interactions smoother.
Stimulating the organisational network
There are a couple of spins to this from my perspective – one is the effect you get from large group events where there is lots of interaction. Meeting new people and understanding who is who can help to start to bridge the gaps of connectedness – this can often occur as part of a regular planning or other similar cadence. The other way is a deeper understanding is through other techniques like Cognitive Edge’s Social network stimulation.
Conclusion
As your organisation grows, the complexity of how it solves problems will likely also change. When you get to a certain size, having a “high performing team” will not necessarily be enough – you will need to tune the entire network of services to be able to adapt appropriately.
This is not a simple problem to solve, so it’s best that you don’t act too simplistically. Furthermore, as the organisation and environment continually evolves you will never be “done” with this – you’ll always need to monitor and make continuing adjustments.
As I mentioned in my recent post on Kanban books, I would recommend Klaus Leopold’s book on this topic: “Rethinking Agile: Why agile teams have nothing to do with business agility”.
RETURN TO BLOG
