PART THREE

HOW-TOs

Here follows a detailed description of how to create a good Agile cross-team collaboration that doesn’t hinder the Agility of the individual teams while fostering the Agility of the whole system of teams.

Below are some options available to quickly draft a good-enough starting point for an Agile cross-team collaboration.

Different contexts & circumstances need different solutions: 0) retrospecting the cross-team collaboration

Many factors have a huge influence on what will work well or not in a specific Agile cross-team collaboration, for example:

• which teams are involved, 
• their ways of working, 
• their mastery and level of Agility, 
• their preferences, 
• the nature of the cross-team dependencies,
• the degree of Complexity of the work to be done, intended as the degree of uncertainty, unknowns, rapid changes and a high level of innovativeness (find more about the degree of Complexity in the book Living Complexity).

There are so many factors and combinations that it is impossible to find out upfront what will work well and what will not. 

Therefore, achieving good Agile cross-team collaboration in a given context and circumstances is similar to attaining good Agile ways of working. It has to start from a simple starting point and from there it requires to experiment, learn, adapt and evolve along the way, with help from regular Retrospectives on the cross-team collaboration itself.

This evolutionary process should re-start from the beginning whenever the teams, the cross-team dependencies, or the work involved changes. The cadence should be linked to the pieces of work requiring collaboration.

With time and experience, the teams in the organisation will become better at choosing a good-enough starting point, choosing the next experiment, and learning and adapting faster. Gradually recurring patterns will emerge, forming a catalogue of experiences and options that will be known for having worked well before repeatedly under specific circumstances.

Organisational bottlenecks, obstacles and inefficiencies affecting the shared work and cross-team collaboration will emerge during the retrospective. It will lead to improvement actions on the governance, structure and composition of the teams, departments and the whole organisation.

Viktor Grgic pointed out the need for an organisational continuous improvement. This retrospective plays a big role driving the improvement toward the organisation’s specific needs and circumstances. It is an alternative to imitating canned solutions, standard solutions, or models copied from different organisations with different needs and circumstances.

The practical elements of Agile cross-team collaboration

Every time there is a Backlog item that needs 2+ teams to collaborate to get it done, the teams will have to find a common way for 

1. planning the work, 
2. considering temporary team structural changes, if needed
3. coordinating the work,
4. sequencing the work to do and getting it done together.

In summary, they will have to agree on the touch-points and the interface of their interaction, and agree on a protocol for their collaboration.

1) Planning the work

Below are three possible options to consider based on the scenario faced.

• When the teams are from the same product area (share the same Backlog and the same priorities)
  The Backlog defines the plan and priorities. No additional planning effort is required unless the dependencies between two district pieces of work are identified late in the process and so a re-prioritisation decision needs to be taken swiftly to bring the two dependent pieces of work closer together.
  
• When the teams work on the same product but in different areas of the product (have different Backlogs and priorities, but a common goal and a common decision maker)
  The teams and their POs and stakeholders need to coordinate their priorities among them when possible and in case of a conflict escalate the decision to the common decision maker.
  No party can autonomously commit to a plan until the priorities are coordinated.
  
• When the teams work on different products or even in different companies (have different Backlogs and priorities, different goals, and don’t share any common decision maker)
  The teams and their POs and stakeholders need to agree to deconflict their plans and coordinate the priorities related to the piece of work and its cross-team dependencies. No party can autonomously commit to a plan until the priorities are coordinated.

2) Considering teams’ temporary structural changes to do the work

All the structures discussed below, last for the relatively short time needed to complete the work (a Backlog item, a User Story). During that time each team member is fully dedicated to the structure they belong to.

• None
  This is the most common and safe solution.
  The rule of thumb is that each team should remain stable for around 18 months. And after that, only a limited number of changes should happen over time.
  
• Gelled teams helping each other
  Relevant team members from a donor-team can join the recipient-team to offer knowledge and help as needed. This requires the teams involved to be stable for long enough (18+ months) for the temporary changes not to damage the teams. The teams should not be suffering from knowledge silos either (e.g. they are practising pairing or mobbing/ensembling that prevents knowledge silos).
  This approach completely removes the need for cross-team collaboration. But it will affect to some degree the capacity and performance of all the teams that have temporarily donated some of their team members.
  
• Creating a temporary task force with relevant team members from the teams
  This is very similar to the previous options, except for all those collaborating cross-team now form a separated task force. It may be better when more than two teams are involved or when there is a need to reduce the noise added to the recipient team.
  
• Temporarily merged dependent teams
  When all teams involved in the work to do are very small (2-3 members) and the number of teams involved is also small (2-3 teams) there is the option to merge the teams for the time needed to complete the work at hand. This will completely remove the need for cross-team collaboration.

In the last three options, if those doing the work collaborate synchronously, pairing or mobbing/ensembling for example, that will greatly amplify cross-team knowledge sharing.

It is possible and desirable that, after the work is completed, knowledge sharing will enable these teams to work autonomously in the future on a similar piece of work with similar dependencies. Because they will have learned how to do the work autonomously.

3) Coordinating the work

After work has been planned and started, the teams involved need to coordinate their actions. For example, where to start, what to do next, exchange and share relevant information, develop a common understanding of the work to be done, help each other as needed, integrate their parts of the work, etc.
They need to find out which of the touch-points are needed. And for each one of them who should be involved, how should it be organised (for example as an ad-hoc event or a regular and recurring event), how communication should happen (for example synchronous or asynchronous), etc.

Below are three common approaches to do this, and the description of how they fit with the degree of Complexity of the work at hand (find more about the degree of Complexity in the book Living Complexity).

• Self-synchronisation
  This approach expects all the members of every team to be empowered to directly share information and coordinate their collaboration and work activities, as needed by the work at hand and its progress and evolutions. Imagine the players of a football team or doubles tennis players and the way they work together.
  This is the same level of synchronous collaboration expected in a good Agile team, but in this case, across the members of the teams collaborating.
  
  Work nature: This approach is a good fit for a type of work that has a high degree of Complexity. Meaning it has a lot of uncertainties, unknowns, rapid changes and a high level of innovativeness.
  And as such it requires a high bandwidth of information sharing and interaction and high-speed feedback loops. For the nature of the work, the collaboration protocol cannot be defined upfront and will emerge during the collaboration. It may remain fluid and may continuously change until the work is completed.
  
  Team capability: It requires each team involved to be comfortable with this type of collaboration and to already have a good level of Agility.

• Orchestration
  In this approach, someone from each team like the Scrum Master and the PO are empowered to come together to form a temporary orchestration workgroup lasting for the limited duration of the collaboration. The group shares relevant information and coordinates the collaboration and the work activities across the teams.
  This orchestration workgroup does not act as a (wo)man-in-the-middle, but whenever direct collaboration between members of different teams is needed, they just facilitate for it to happen, and get out of the way.
  
  Work nature: This approach is a good fit for a type of work with some degrees of Complexity. Meaning it has some uncertainties, unknowns, and some level of innovativeness. The orchestration facilitates the identification and definition of a collaboration protocol among teams that fits the work at hand: clear collaboration touch points (events) and interfaces (what is exchanged between teams, when, who, etc.)

• Strictly hierarchical coordination
  This approach expects that there is a dedicated role in the org-chart with the authority to direct the collaboration among the teams, in a traditional top-down fashion.
  
  Work nature: It can be a good fit for the highly repetitive, predictable and standardised type of work. While it is very problematic for software development and innovative work where it doesn’t solve the coordination problems and it often becomes an obstacle that people have to work around.
  
  This approach for obvious practical reasons is not applicable when for example the teams belong to different organisations that have distinct org-charts, or when the teams belong to disjoined parts of the same organisation.

4) Sequencing the work across teams

Below are a few options to sequence the work over time across the teams. Each option fits a certain degree of Complexity of the work at hand, and a certain level of Agility in the teams. Find more about the degree of Complexity and the level of Agility in the book Living Complexity.

• Parallel work
  The piece of work that is consuming a cross-team dependency and the work on the related cross-team dependency are carried out by all the teams in parallel at the same time. It can be done using techniques similar to those that allow automated test coding in parallel with the coding of the related feature.
  
  Team capability: This requires the teams involved to have a high level of technical Agility and collaborate synchronously like with pairing and mobbing/ensembling. And it benefits from the ability of the teams to practise Trunk Based Development (TBD), Feature Toggles, and Continuous Delivery with automated remediation plans (for example one-click rollback).
  
  Work nature: This approach is a good fit for a type of work that has a high degree of Complexity. Meaning it has a lot of uncertainties, unknowns, rapid changes and a high level of innovativeness. Because of the nature of the work, all the interfaces between the different pieces of work, their design, their integration, the understanding of the problem and the discovery of the solution, evolve gradually while the work is done and until the work is completed.

• Asynchronous blocking work
  This approach is a more flexible alternative to the strictly sequential Staggered work (see later). Its flexibility is attained from more advanced teams’ capabilities. While the teams work asynchronously, the work can only be completed after all the teams successfully complete their part of the work and successfully complete the integration.
  
  Work nature: it is a good fit for the same type of work that fits staggered work with or without a buffer.
  
  Team capability: The ability to work asynchronously requires the additional ability to practice Trunk Based Development (TBD), use Feature Toggles, and practice Continuous Delivery with automated remediation plans (for example one-click rollback).

• Staggered work without a buffer
  In this approach, the piece of work consuming a cross-team dependency will be planned into the following iteration/Sprint, after the work on the related cross-team dependency is completed. It needs all the work to be done iteratively and incrementally. So that even if the work on the dependency is not completed on time, the work that consumes the dependency can start anyway by consuming what is already available.
  
  Work nature: This approach is a good fit for a type of work with some degrees of Complexity and so with some uncertainties, unknowns, some changes, and some level of innovativeness.
  
  Team capability: This requires all the teams to have a good level of technical Agility that can be obtained, for example, by practices such as real Continuous Integration, TDD, and continuous refactoring with emergent design.

• Staggered work with a buffer
  This approach is similar to the previous one but adds a safety buffer. It avoids last-minute emergency changes to the iteration/Sprint planning when the work on the dependency is not completed in time by the end of the previous iteration/Sprint.
  
  Team capability: Techniques such as Consumer-Driven Contracts (https://martinfowler.com/articles/consumerDrivenContracts.html) can be enough to help teams avoid misunderstandings, and reduce the risk of integration problems.

• A future Deadline
  The teams will work independently on their own piece of work and the work will be sequenced using deadlines.
  
  Work nature: It can be a good fit for the highly repetitive, predictable and standardised type of work. For it, the interfaces and the integration of the pieces of work can be correctly defined upfront without causing unexpected surprises. And it won’t require multiple back-and-forths and rework that would cause very long delays.
  
  Team capability: The sequencing of the work with deadlines is inherently fragile because when any of the teams get behind schedule, that has a knock-on effect on all the other deadlines. So, it should be adopted only by teams that cannot be Agile.

Let’s not forget the important intangibles

Being part of effective Agile teams taught us the huge importance of the many intangibles required for a great collaboration inside a team. Equally, in Agile cross-team collaboration, many essential intangibles play a fundamental role in the success of the collaboration. These are a few of them worth mentioning to help us not forget that processes, tools and techniques always come second, after the social and human aspects: we know it is important to get to know each other strengths and skills and styles, get along, trust each other’s genuine intent to collaborate and to help and support each other, and trust the ability of the collaboration to be successful. We know it is important to have authority aligned with our responsibilities, to have the freedom to bring our whole selves to work and be human, to use our creativity, to do our work well, and to have joy in our accomplishments.

---

<< Part 2 (Part 3) Part 4 >>

---