How to build high-performance teams on Agile and DevOps principles

It’s not a war, it’s a game.

High-performing teams are critical success criteria for many different aspects of life. Be it the winning team in a sport, the small, highly effective special forces unit, or the often-unsung heroes of digital and technology delivery.

While the application of their skills may be very different, the best teams display a few clear facets of their success. 

In this article we will look at:

• Team size
• Longevity 
• Ownership of the work
• Skills
• Working Practices &
• DevOps

Team Size

Many studies prove where the sweet spot is in team size. Closely linked to the number of communication channels humans can handle and the number of individuals we can establish trust relationships with. If we rigorously stick to the 7-9 people per team rule, those team members will build long-lasting trust relationships with their team members, and each will know the strengths and weaknesses of each other. This trust and understanding is the bedrock of high-performance teams. Whenever we expand a team beyond this sweet spot, we must accept that there will be a reduction in trust and understanding which must be compensated for in the reasons for expanding the team. This might be to increase the overall skills of the team with the addition of specialists but if the team size is large due to duplicated skills, then the result is very rarely better than a smaller team.

Longevity

Teams take time to establish and become performant. Organisations that understand this will focus on maintaining teams that have become performant rather than breaking them up at the closure or completion of a task or project. Tuckman’s model of team development (1) can be observed in any new team and the associated reduction of throughput during the Storming phase should not be underestimated. However, those principles are now showing signs of age and there are more recent viewpoints that allow us to observe the team forming in a more appropriate way for Digital Teams. One such example is the book by George Karseras, Build Better Teams: creating winning teams in the digital age. (2)

In this, George extends the thinking to include the environment, the ability of the team to collaborate at their level and the organisational structure being equally as important as team-focused thinking such as Tuckman. 

Structuring the communication and tooling around the team dynamic rather than at an organisational level will encourage the team to communicate and collaborate openly without the noise or scrutiny from the wider business.

How a team is positioned in the organisation can have a profound effect on its ability to reach peak performance. Moving delivery and operations functions closer to the customer and away from being an IT supplier to the business, for example. 

Own the work

Another key success criteria for team performance is linked directly to their ownership of the work they undertake and that is their ability to ‘pull’ the work towards them as opposed to having it directed at them. We can see this in several different dimensions among which we include the move to DevOps covered later. In the first instance though, having teams pull the work to them is a vital part of work ownership. In its simplest form, this might be how an agile delivery team reviews the backlog in Sprint Planning. Only considering items that pass a robust Definition of Done and creating the Sprint Backlog by pulling items in. In this way, teams will form around the commonly understood scope of the sprint, often defined by a Sprint Goal and as a collective, take ownership of the delivery. 

Sidenote, the lack of a sprint goal is often incorrectly perceived as a weakness in the agile maturity of a team. In reality, teams often struggle to define a Sprint Goal due to the variability of their work or have moved beyond the simple goal statement to a higher level of maturity and so a lack of a Sprint Goal can be used as an indicator but not a measure of agile maturity.

The right skills

There is a lot of talk about the multi-disciplined or cross-functional team being the ideal, particularly in software development. However, it is now, thankfully, becoming equally important to consider the diversity of the team. The following excerpt from a 2016 Harvard Business Review (3) describes one of the key performance improvements that can be had from team diversity “Diverse teams are more likely to constantly re-examine facts and remain objective. They may also encourage greater scrutiny of each member’s actions, keeping their joint cognitive resources sharp and vigilant.” The dimensions of diversity will vary from team to team and organisation but must be considered as an important facet to establish a high-performing team. At AND we use the structures of Whole Brain Thinking (HBDI® Herrmann Brain Dominance Instrument) (4) as an important diversity dimension when forming teams and making this visible to team members builds increasing levels of trust, empathy and powerful decision-making during team-thinking activities.

Work practices and topologies

It might sound like an obvious statement, but teams that have an agreed way of working are more likely to perform than teams that do not. If a team understands the ‘rules’ then they can concentrate on the delivery execution. However, for a team to devise a way of working that is fit for purpose to them AND is widely understood by the other teams and touchpoints in the organisation, a pattern for ways of working should be established. To establish these patterns, it can be very informative to look at the Team Topologies and align the various or many teams in an organisation to just a handful of topology types. 

In the book: Team Topologies | Organizing Business and Technology Teams for Fast Flow (5) The authors encourage the technology delivery teams to be aligned to just 4 topologies. Each Topology has a defined set of working practices, communication types and engagement models. In doing so, the teams require less cognitive load for collaboration with other teams and can build their own ways of working on top of the baseline for their team type and within the guardrails for the pattern. This means that teams are better equipped to work together and with each other and can move quickly through the phases of team establishment and become high performing.

Yes, but what about DevOps?

We often find that DevOps is being purported as something akin to a Silver Bullet in delivery excellence. DevOps and the DevOps handbook (6) came about to solve just one specific problem. That is, the often tricky handoff of a product or service from the team that built it, to the team that runs it.

Without intervention, the Development and Operations teams can be found somewhere on the scale between entrenched warfare and an ill-defined ownership boundary.

In establishing a path to high-performing teams, if we only consider the Development (or Operations) teams, we will likely make little or no inroads to the Operational handoff and in a lot of cases, make things worse as, often, the Development teams start to deliver at a pace that is unachievable for the Operations team to consume. 

Therefore, when looking to improve the delivery pipeline and establish high-performant teams, both Development and Operations teams must be in the scope of the change. It should not go without saying that, establishing DevOps principles and adopting a one-team approach to end-to-end delivery will, over time, improve the ownership, quality and speed of delivery but one can simply not ‘become DevOps’ overnight.

As with team evolution, it takes time and the approach and duration of the time will depend on which end of the wall-building scale the teams are on. For example, if the Dev and Ops teams are mainly working in harmony but there is a bottleneck in service or product adoption then you can perhaps start by pairing and/or loaning team members across the hand-off point. If though, the teams are regularly lobbing grenades at each other from a heavily entrenched position, mediation will be required, and the creation of a temporary DevOps team may be required to create the bridge between them. It should be noted that the word ‘temporary’ was very deliberate in that sentence as a perpetual DevOps team is very rarely the answer and does not mean that DevOps has been implemented.

They should be there as an enablement team (one of the four topology types) who will create the tools and trust required for the Dev and Ops teams to reach a common ground and ultimately become one..

References:

1. Tuckman, B.W. Developmental sequence in small groups. Psychological Bulletin, 1965, 63(6), 384-399.
2. Build Better Teams: Creating Winning Teams in the Digital Age
3. Harvard Business Review: Why Diverse Teams Are Smarter
4. The HBDI® (Herrmann Brain Dominance Instrument)
5. Team Topologies: Organizing Business and Technology Teams for Fast Flow
6. The Devops Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations