Six Practices for Healthy Inter-Team Cohesion

We've recently run a meet-up where we shared a broadened, fresh view of Org Topologies™.

This broader view is more aligned with the system thinking perspective and is also easier to understand. We believe it creates a richer context for the research question that we are working on: "how can we create better product development organizations that can longer stay relevant for their customers, employees, and stakeholders?"

This article describes one of our recent findings: organizational cohesion.

The challenge of nailing It

If you are familiar with our previous work, you know that we tried many different names for the axes of the org topologies map.

For the Y-axis, we used:

• level of value consolidation

• team’s scope of work

• fluency at learning & working with the whole product

• a shared understanding of customer domain

• breadth of shared customer focus

• switching costs

• product-centric alignment

And for the X-axis:

• level of capabilities consolidation

• team’s capabilities

• fluency in delivering end-to-end value

• depth of cross-functionality

• transactional costs

• team autonomy

Those names were not wrong, in fact, all of them were partially correct. But we couldn't settle upon any of these names because we were striving to find something universal, and not so directly associated with specific practices such as backlog management.

Alignment is not enough

For some time, we settled on using alignment and autonomy for the axes' names. Alignment is a widely used term within the product development domain. But does being aligned necessarily mean tight collaboration to deliver value?

A group of component teams within a SAFe adoption can be very much aligned on the big goals ahead of them (especially right after a multi-day PI-Planning event). However, they still might not be able to deliver on those plans due to unforeseen blocking dependencies coming from a lack of cross-product knowledge.

Therefore, alignment is important for collaboration, it is a prerequisite, yet it might not be enough. Alignment works only in conjunction with abilities. And in complex creative and engineering work, abilities are determined by team composition, technical and social skills, infrastructure and external support, skills to self-manage dependencies and collaborate with the other parties, etc.

When we are aligned and possess all the needed abilities, then the magic of creation can happen. It is still not guaranteed, but now at least there is a higher chance.

Interaction - it's all there is

From a systemic point of view, a system is not just the sum of its parts, but also the universe of the interactions of the parts. And in complex systems (e.g. large-scale organizations dealing with non-trivial value creation), the interactions between the parts play a major role in how the whole system behaves. This is where the magic happens that makes the emergent system qualities appear.

For example, you can have a software development organization where each team does some sort of iterative-incremental approach, working in short iterations and making quick software changes, but the whole organization might still be seen as slow and unresponsive in delivering real customer value. Why? Because the interaction between the teams is not efficient, they occasionally get blocked by each other and the flow of value creation gets interrupted.

Our goal is to make Org Topologies™ generic so that it becomes an open playfield for collecting good industry practices. For this reason, we are striving for more abstract, more generic definitions. And applying the systemic view gives us the following definitions for our axes:

• X: quality of interaction within teams

• Y: quality of interaction among teams

Team behavior emerges from the way the team members interact with each other inside the team. This can be related to how the team members collaborate and to the team's capabilities. Some team member interactions (e.g. cross-functionality) contribute better to the level of adaptability than others (e.g. handoffs).

Different quality of interactions between teams yields different results. Again, quality is to be seen in the context of how well the type of interaction contributes to being adaptive at the company level. Some inter-team interactions (e.g. breadth of shared customer focus) provide better adaptability than others (e.g. Scrum of Scrums).

Cohesion

If there is too much alignment, freedom can be at risk because it limits the teams' creativity. But when there is too much freedom, there might be a lack of collaboration toward common goals. It seems we need a good balance of both.

Bas Vodde has put it nicely together in his conference talk: Maximizing Dependencies with Interdependent Teams. We want autonomy at the level of capabilities, but for the greater good, we also need tight collaboration. In LeSS, it is not uncommon that several teams work together on a related set of product features. In fact, this is even a desired outcome when multiple teams share a common list of priorities and goals -- they will find a way to work together on the top items. The teams are interdependent.

Our goal is to collect a set of generalized practices that can be applied universally by organizations in any state of agile maturity. The term we propose to describe the correlation between inter-team and inside-team interactions is 'organizational cohesion'.

For good organizational cohesion, we need a good mixture of both alignment and autonomy. Too little autonomy with too much alignment will grind teams to a halt due to blocking dependencies. Too much autonomy with too little alignment will allow the teams to run in different directions.

Good cohesion makes teams stay in comfortable proximity to each other and to the clients. Thus, enabling sharing work (when needed) and taking care of the work environment to avoid the tragedy of the commons.

Practices for creating cohesion

There are many practices around to create alignment and/or autonomy. Every practice that creates alignment has its own qualities, and it is essential it is paired with a practice that creates the right level of autonomy to find the "sweet spot" of cohesion. And vice versa.

Below are some known industry-wide practices from the viewpoint of creating inter-team cohesion.

#1 Creating Cohesion with OKR's

The main goal of OKR's is to provide alignment on goals and a transparent way of measuring them. Implementing OKR's bottom-up and side-by-side (instead of top-down) is a good way to apply this practice.

OKR's improve team autonomy, so we need at least stable teams (Column 1 and higher on the map). Goals set at higher value aggregation levels will be more useful, that's why OKR's are likely to work from the feature level and higher on (row A and higher on the map). At the task level, the goals will be too fine grained, and they will most likely contradict.

There is a chance that the introduction of OKR's brings confusion when they are added to existing goals set via other practices (such as KPI's, maturity models, Product Backlogs, etc). Replacing or combining existing practices reduces ambiguity and thus increases alignment. OKR implementations achieve better cohesion when the teams define the Objectives as Product Goals in the Product Backlog (horizontal axis). The higher the aggregation level of the value, the more meaningful the OKR's will be (vertical axis). If the OKR's are defined at a too high level in relation to the abilities of the teams, the organizational coherence will be broken. The result is then that from the point of view of the teams, the Objectives will be too abstract and meaningless.

#2 Creating Cohesion with OBEYA

OBEYA is the practice of collecting relevant product development information on the walls of a big room. OBEYA aims at having valuable dialogues and using collaboration and collective wisdom to steer product development. During the OBEYA sessions, all relevant teams and stakeholders engage to align on what's important, solve problems, discuss direction or progress, and so forth (vertical axis). The team members provide and own the content in the OBEYA room, which displays their level of autonomy (horizontal axis).

OBEYA works best for aligning on larger chunks of value like initiatives, features, etc (Vertical axis). Lower levels of aggregation (e.g. tasks) will lead to too fine-grained information gathering, stimulating micro-management.

#3 Creating Cohesion with Multi-Team PBR

Multi-Team Product Backlog Refinement (PBR) is a practice in LeSS. In such PBR sessions, multiple teams work o shared Product Backlog Items from a single Product Backlog. During these events, team members are temporarily mixed to form groups for refining the Product Backlog Items. Mixing team members is a powerful practice that facilitates fast knowledge sharing across teams. This practice is vertically focused: it aligns on the most important things to do and enables team members to widen their product understanding. Horizontally, teams will improve their cross-functionality and cross-component-ness. Multi-team PBR will not work with component teams (functional silos). That type of team first needs to be flipped to feature teams to benefit from this practice.

#4 Creating Cohesion with Pairing, Pair & Mob Programming

Pairing team members implies people form pairs to work on tasks. Pairing works for any kind of task. When pairing is applied in programming, we call it pair-programming, as introduced by Kent Beck. Most developers might argue that programming is individual work. However, I have seen many skeptic developers adjusting their ideas on pair programming after experiencing how liberating this practice is. When programming in pairs, there is a driver who does the coding and a navigator who instructs the driver on what to type. Roles are alternated frequently. The resulting software is high of quality and there is a lot of learning as the team members extend their cross-component/functional capabilities.

Woody Zuill's Mob-programming takes this approach one step further. With this practice, the whole team is involved in the programming session. Again, there is a navigator who instructs what to code. The rest of the team takes the driver position at short time intervals, say 5 minutes per person. This way of working demands that everybody needs to be engaged all the time. The learning of one day of "mobbing" is immense.

This practice stimulates horizontal movement by increasing the quality of inter-team alignment. This practice can improve the quality of inter-team alignment at any level. From working on individual tasks to collaborating on the same product, teaming up with a colleague is fun and instructive. There will probably be more resistance to pairing at the Y-levels since these levels tend to focus on optimizing resource usage, a goal that conflicts with assigning two people to one task.

#5 Creating Cohesion with One Product Backlog

Since the beginning when we started working on the Org Topologies™ map, we were considering the understanding of customer value as the alignment between teams. Only later we discovered that actually, this is one practice of many that can align teams. There are many ways to Rome, and there are many practices that lead to cohesion. The reduction of Product Backlogs is an extremely powerful descaling mechanism, and with descaling comes alignment because it forces the teams who do the work to align on the work.

To obtain cohesion by moving away from single-team backlogs to area backlogs or even a company backlog, we need at least cross-functional/cross-component teams. For best results, all teams would need to be able to deliver Done autonomously, but also without that, this practice will give pretty good results. The number of hand-offs and alignment meetings will drop in favor of faster deliveries due to a wider and deeper understanding of the product domain.

Aggregating Product Backlogs with component teams will not get the teams moving much faster due to the high number of dependencies and the absence of an incentive for the teams to think broader than the scope of their component.

#6 Creating Cohesion with Team Interdependence

Dependencies are, in general, considered to be bad. But this is not true. Some dependencies are blocking your work. You have to wait for some other team, or people outside your team bother you to do things for them which makes you lose focus. We call these asynchronous dependencies. You have the know-how, and you want to do what people ask you, but not now. The trick is to turn them into synchronous dependencies: People ask you to do something and actually, you were already working on something similar. We also like to call synchronous dependencies "opportunities for collaboration". More on this subject can be learned by watching this video by Bas Vodde.

Examples of ways to create synchronous dependencies can be sharing Sprint Goals, or sharing Product Backlog Items through techniques like pairing or multi-team product backlog refinements, or story mapping sessions. For best results, first create cross-functional teams.

End note

We are aware that these are just a few examples from many. We think they are good examples to show how the Org Topologies™ map will help you to improve your product development organization:

1. Understand how the Org Topologies™ map can improve your organizaiton's adaptivity.

2. Find out where the teams in your development group are on the horizontal axis by reflecting on the interactions inside the teams.

3. Observe the vertical axis to learn at what level and how the teams align with each other.

4. Think about the quality of their cohesion will give you clues on which practices to try out to improve your group's adaptivity.

Moving on, you could:

• Read one or more case studies will help to understand the value of a deeper understanding of organizational dynamics.

• Review your agile practices to increase team autonomy and improve inter-team collaboration.

• Share practices you use or see being used with us and tell us how they help or hinder organziational cohesion.

• Book a session with us, so we can help you get started using Org Topologies™.

© 2023 Roland Flemm and Alexey Krivitsky