This is my four-part deep dive into the How-Tos of Agile cross-team collaboration, one of the topics I find most consequential for successfully adopting Agile beyond one team. Ironically, none of the current “scaled” solutions cut it.
When thinking about collaboration inside a good Agile team, what usually comes to mind is a very positive and fulfilling professional and social experience.
An environment where people constantly learn from each other, experiment, achieve more than they thought they could, enjoy the energetic creativity of the group, and succeed together. Some of those that experienced being in a good Agile team did not want to go back anymore. Some of those that tried synchronous collaboration – for example, working in pairs or mob/ensemble programming – did not want to go back anymore.
So why are many experiences of cross-team collaboration painful, leaving bad memories, and making people wonder how to avoid the need for it?
Well, I suspect the problem is not in the collaboration bit, quite the opposite. Because of our social nature, relationships and interactions most of the time are very positive.
Instead, the root of the problem is much more likely to be in the wait time, the delays, the repeated back and forth, the re-work, the slowness and the overhead caused by hand-offs and the blocking team dependencies, the time and effort they take, and the massive impact they have in everyday work.
For that, I believe all that can be done to limit and reduce hand-offs and remove and avoid new blocking team dependencies should be done, as previously pointed out.
The medium and long-term repeated costs of hand-offs and blocking team dependencies are much greater than the cost of getting rid of them. This has already been mentioned before, together with suggestions on how to do it.
And there are also things that can be done to make the cross-team collaboration itself frictionless and more enjoyable. At least in my personal experience (I’d like to hear yours too).
I have found that where it’s possible to work in small gelled teams (see teams’ temporary structural changes in the How-Tos) in which every team member can help other teams as needed, it does eliminate the need for any coordination overhead. As such it is the simplest, fastest, most effective, flexible, and most powerful, solution.
I’ve found that self-synchronisation (see coordinating the work in the How-Tos), where the experience and ability of the team members allow for it, is lightning fast, effective and flexible. Elements of orchestration may be introduced to compensate for the lack of experience until the team learns how to do without.
And finally, I have found parallel work (see sequencing the work in the How-Tos) adopted in combination with technical excellence (Trunk Based Development, TDD, real CI, clean feature toggles, real CD with automated remediation plans, etc.) to be extremely simple, flexible and fast.
These elements allowed me to experience a frictionless cross-team collaboration that together with a minimal number of blocking team dependencies created a super fast flow, allowing me to enjoy the positive aspects of the collaboration not only inside the team but also across teams.
So, in short, the answer to the initial question is: avoid hand-offs and blocking team dependencies, and make the remaining cross-team collaboration frictionless. With the warning: Don’t throw the baby (collaboration) out with the bathwater (hand-offs and blocking team dependencies).
The social and human intangibles of the Agile cross-team collaboration and all the suggestions above on how to pursue good Agile cross-team collaboration remind us that:
– the traditional pre-Agile practices disguised as new do not work, that is why Agile was developed in the first place;
– Scrum of Scrums is at the same time too much and not enough, therefore it must be left behind, the sooner the better;
– all the options presented above help to quickly identify a good-enough starting point for cross-team collaboration, for any new piece of work with blocking team dependencies;
– the real work then starts, and it is done by experimenting, learning, adapting and evolving the cross-team collaboration for the specific teams working on a specific piece of work. This is achieved by applying Agile, not only to each team, but also to the collaboration between the teams, evolving the collaboration itself thanks to the feedback loops and the lessons learned while doing the work. By continuously running Retrospectives on the cross-team collaboration.
Here are a few useful links:
– Book Team Topologies: https://teamtopologies.com/
– Book The Mikado Method: http://mikadomethod.info/
– Book Living Complexity: https://leanpub.com/livingcomplexity/
– Taming Dependencies, #2 in Practice and patterns for the Product and the Delivery Initiatives:
– Unwinding the dependency spiral: http://p2.fed.wiki/view/part-1-unwinding-the-dependencies-spiral
– Collaborating at Scale: http://p2.fed.wiki/view/part-2-collaborating-at-scale
<< Part 3 (Part 4)