The Key to High Performance Agile: Maximizing Teamwork

Adopting Agile has not brought the transformative benefits many organizations hoped for. Some blame Agile, some blame the organizations. Many agree that there’s a missing ingredient on which the Agile manifesto is silent. Usually, this secret sauce is termed ‘mindset’ or ‘culture’. Something that organizations can’t easily make concrete or readily improve.

Strangely overlooked in the hunt for the Agile secret sauce is teamwork. We’ll look at studies showing that high-quality teamwork is transformative. Let’s look at Agile software delivery through the lens of high-quality teamwork. We’ll see that there’s a great deal that we could do better and in specific, actionable ways.

Teamwork As Secret Sauce

Google studied 180+ teams from 2013–2015. Google found that the team’s dynamics mattered more to the team’s performance than the skills of its individuals. The best teams answered yes to the question “Can we take risks on this team without feeling insecure or embarrassed?”. Google called this psychological safety.

Why is psychological safety important? Teams have to be able to voice ideas that might sound silly. Ideas that seem silly at first can be developed into something successful. Teams can’t be creative if they can’t explore a wide range of possibilities.

Not all possibilities can be explored at once and teams have to prioritize. That means disagreements. Healthy and necessary disagreements. Individuals will avoid this kind of conflict unless they feel comfortable and they trust that others won’t get personal.

The core finding of this Google study fits well with a 2010 MIT study into team performance. MIT identified social perceptiveness as a key factor in team performance. The study found that team members understanding one another and being receptive to one another’s states of mind was more important than their individual intelligence. We’d expect teams that show mutual understanding to also practice psychological safety.

Trust as the Foundation of Teamwork

Agile was founded on ideals of teams self-organizing to resolve customer problems. In order to focus on customer problems, teams need to debate options and scrutinize actions. This requires a strong foundation in trust. A trusting environment is the foundation of teamwork in Patrick Lencioni’s classic The Five Dysfunctions of a Team. His perspective on trust provides a helpful way of seeing the importance of psychological safety.

Building trust is not the only challenge for teamwork. But it is the foundation. Only in a trusting atmosphere are teams able to debate openly, fully buy into approaches, and commit towards achieving results. Team members need to be able to trust that ideas will be met with understanding and that disagreements won't turn personal. Otherwise, ideas won't be ventured for fear of conflict.

Team members have to jointly devise an approach that all of them buy into. If some parties do not contribute, then key aspects of the problem may be missed. More importantly, some team members may not be fully committed. This kind of collaboration requires having open debates.

When it comes to Agile, it’s especially important that teams are responsive to feedback and collaborate when individuals have highly specialized and differing skills.

Agile Alone Doesn’t Guarantee Good Teamwork

Following Agile practices can improve success rates for software projects, particularly if the team is committed to the project and its goals. But there is no formula for the best application of Agile principles.

Scrum can be a guide but following a framework in a formulaic way risks becoming regimented. Then focus moves to the rate of delivering features rather than solving business problems. This regimented form of Agile has been branded Fake Agile as it misses out on the benefits of collaboration and feedback that the Agile Manifesto advocated for.

Fake Agile is marked out by the siloed way in which each role within the team approaches its work.

Solving business problems through software is a collaborative process. Different specialists need to see how their contribution relates to the larger problem. Individuals need to be continually asking how best to deliver the next increment. And how that release-increment will be a step closer to a solution.

Refining a collective vision requires trust and open debate. Individuals need to work both within and beyond their particular specialisms. Specialization can be powerful but it also creates barriers. Failure to focus on a common vision can lead to divisions and undermine open debate.

Fake Agile does not only happen due to a failure to understand Agile training or top-down management culture. Regimentation can come from within well-intended Agile teams.

It is difficult to keep adapting work to the end goal. It takes away our safe spaces. It forces us to do things outside of our specialism.

“ Specialization allows us to handle ever-growing complexity, but the benefits of specialization can only be fully realized if the silos that it creates can be connected effectively.” 

Mik Kersten, Project to Product

To avoid Fake Agile, we need to understand how it develops. We’ll look at each of the typical specialisms of an Agile team. We’ll see what biases each specialism is prone to and how to keep on course for an open and adaptive form of Agile development.

Product Manager Biases

The biggest risk for a Product Manager is taking on too much responsibility for the Product Vision and execution. The vision is a Product responsibility but it is a living thing that everyone should feel part of.

In regimented environments, the Product Manager can come to have a monopoly on the vision. User stories become feature descriptions and development teams become feature factories.

Collaboration can be encouraged by keeping the focus on customer problems. It’s important that the team think about customer problems as the vision breaks down into lots of little design decisions. From the captions on buttons to the messaging of a design theme to the response time of operations. The product manager doesn’t want to micromanage and it’s better for the team to shape the direction together.

A team that relates to its users and stakeholders is more likely to deliver a great product. This was a lesson of studies discussed by Debora Ancona and Henrik Bresman in X-Teams: How to Build Teams that Lead, Innovate, and Succeed:

“ X-teams seek out information about the customer (often directly as opposed to secondhand), the technology, the market, and the competition…

Teams that scouted out new ideas from outside their boundaries, received feedback and coordinated with outsiders, and got support from top managers were able to build more innovative products faster than those that dedicated themselves solely to efficiency and working well together.” 

Ancona and Bresman, X-Teams: How to Build Teams that Lead, Innovate, and Succeed

Encouraging developers to see and think about customer problems needs to be approached collaboratively, without coercion, and not as a token gesture. It can be easy for barriers to emerge between specialisms.

Product Managers can help build bridges by showing sensitivity to the developer’s domain. It can help to try to understand the roles of the key technologies, how complex they are, and who the experts are on them. These conversations will build a better sense of what the team will be able to deliver and what tech debt might be incurred.

Software Developer Biases

It can be tempting to judge teams by the quantity of output. Developers can judge themselves by code delivered. It is more tangible than figuring out how to structure features to work best for users. But the ultimate aim is to resolve business problems and this is how everyone on the team should judge themselves.

“ The most successful development occurs when developers talk directly to customers or are part of business teams.

The biggest cause of failure in software-intensive systems is not technical failure; it’s building the wrong thing.” 

Mary and Tom Poppendieck, Leading Lean Software Development

The core of Agile is delivering in iterations and refinement. This can mean putting software in front of users that may have technical weaknesses and that may not last through future iterations. It means dealing with ambiguity and experimenting. This can be hard for developers as the software is their baby and developers want it to be technically great.

The internals of the software are important. But not more important than solving business problems. Developers need to see how technical problems relate to the bigger picture in order to prioritize effectively.

It is important that developers sensitively probe the product vision and don’t expect it all to come from ‘Product’. It’s also important to welcome collaborative discussions in the ‘Tech’ domain. This could be explaining where technical debt comes from and why it’s important. Or explaining the basis for estimates.

Collaboration can help build trust. Especially the trust to understand that estimation is hard and that there will be overruns.

Scrum Master Biases

The Scrum Master should facilitate collaboration between Product, Developers and Stakeholders to keep the project iterating its way towards solutions. This can make the Scrum Master well placed to spot problems early and anticipate challenges.

For the Scrum Master to be an effective facilitator, they need to avoid being pulled into an agenda. If the Scrum Master becomes too close to senior stakeholders, for example, then their focus can become too much on deadlines rather than ensuring that feedback is being used to get towards building the right thing.

There is no formula for delivering the right thing. Frameworks like Scrum are just guides. Following Scrums’ suggestions to the letter can encourage a regimented environment and make the Scrum Master into a scrum policeman.

Structure matters but what matters more is that the team self-organizes to resolve the key business problems. The Agile manifesto makes no prescriptions about how teams should self-organize.

Maximizing Teamwork to be a High-Performance Team

If there is not an atmosphere of trust and challenging one another then delivery can become regimented and degenerate into Fake Agile. Then the team’s focus becomes more on deadlines rather than feedback. This risks delivering the wrong thing. Teams can become feature factories just because each specialism fails to beyond their comfort zone.

The team is not an island and the source of its problems may not be internal. The practices of a team cannot be entirely separated from the organization. Silos exist not only within a team but also across teams. We respect these challenges and have written elsewhere about how to tackle them.

Some Agile literature puts value on aiming for a T-shaped skills profile. We are told that being a specialist should be balanced with soft skills and some skills from related disciplines.

Aiming for flexibility is important. But we find it problematic to frame this goal of flexibility solely in terms of the skills profiles of individuals. It is more about how individuals interact and what they feel safe doing.

The teamwork aspect of Agile really can be improved. When Google released their study showing the importance of psychological safety, they also released details of how they measured teams by surveys and a guide for fostering psychological safety.

To practice better teamwork, we need to emphasize the right things. It is important that those with the most influential approach problems with humility, encourage debate, and encourage collective decision-making.

There is a role for team building and creating safe environments where people get to know each other. Stepping away from the pressures of delivery can help reflection and seeing a bigger picture. Some teams may find value in Agile training or playing games based around Agile.

There are exercises based specifically around The Five Dysfunctions of a Team but not many Five Dysfunctions exercises with an Agile focus. To help fill that gap we’ve created an exercise where a team can walk through contentious software development scenarios and play out healthy conflict.

We are not suggesting that teamwork is easy.

“Like so many other aspects of life, teamwork comes down to mastering a set of behaviors that are at once theoretically uncomplicated, but extremely difficult to put into practice day after day.”

Patrick Lencioni , The Five Dysfunctions of a Team

Nonetheless, there are identifiable patterns to good teamwork. There are teamwork goals to aim for. Attaining our teamwork goals could also be the key to meeting our business objectives.