The topic of High Performance Agile teams is one that comes up frequently in conversations in Agile circles. There is a lot of confusion around it, I think in part because it’s difficult to come to an agreement of how we define a high performing team and what the benefits are. At Stuart we recently had a discussion around High Performing Agile teams in our Agile Community of Practice (CoP). We wanted to gain a common understanding of what we mean by it, what are the benefits of high performing teams, what are some patterns and anti-patterns, and most importantly, what are some tips and tricks for developing high performing teams. So, we put our heads together and came up  with some thoughts that I am now sharing as part of this blog post.

Before we begin, it is important to note that developing a high performing agile team is a never ending journey and that it is not necessarily linear. A team may become more or less mature for a number of reasons such as a change in scope or vision, changing, adding or removing team members, and organisational restructuring. Below is a summary of our conversation blended together with my own thoughts and experiences. I also included some research I conducted online that supports the need for high performing teams and highlights the struggles to get there. Let’s start by asking ourselves: why do we want high performing agile teams anyway?

Why do we want them?

High performing teams bring many benefits to the organisation, including:

  • Better quality solutions
  • Sustainable development
  • More engaged and empowered team members
  • Removing leadership bottlenecks
  • Happier teams which are more productive and result in people staying with a company longer
  • Better communication
  • Trust
  • Efficiency

          How do we define them?

          We started our conversation in the CoP by defining what we mean by high performing Agile teams. Are we talking about lines of code? Number of releases? Business or customer value? Velocity in the case of Scrum or cycle time in the case of Kanban? The answer is more nuanced than it would appear at first glance. This is because different teams define success in different ways and we need to be careful not to track vanity metrics such as lines of code or velocity. These types of metrics do not speak to the value that the team is delivering.  Business value and customer value are great indicators of success but only if you have a way to define and measure them. Many organisations do not. How did we define a high performing Agile team then, you ask? Well, we stuck to the most basic definition possible.  First we aligned on the definition of an Agile Team, and then identified what makes it a high performing one.

          An Agile Team is a team composed of cross functional, fully autonomous individuals with the skills necessary to effectively accomplish the work in their backlog. Everyone in the team is empowered to make their own decisions and is held accountable for them. (This is a fairly standard definition of an Agile Team and can be found by doing a quick Google search.)

          A High Performing Agile Team: Is an Agile team made up of highly motivated individuals that consistently delivers exceptional results (however you define them) over a period of time, regardless of the challenges and uncertainty the team may encounter.

          High Performing Agile teams don’t just spring out of nowhere. It takes dedication and leadership at all levels. A lot of effort goes into developing such a team. The results of the team are often due to the sustained efforts of committed people who embody Servant Leadership values and principles. As I stated earlier, it is an infinite game. High performing teams are rarely satisfied with their performance even if they are performing well. They are constantly looking for ways to do better.

          That being said, the definition of a high performing team can be somewhat vague and general so we continued our conversation by identifying first what is NOT a high performing team and where teams struggle. Secondly, we thought about what we can do as Agile Practitioners to move the team past those struggles to achieve high performance.

          Why do Teams Struggle to Gain High Performance?

          There are many reasons why a team might struggle to achieve high performance. I find it useful to break it down into two main categories: Logistics and Team Dynamics. As Agile Coaches our role should be to ensure that every team has an environment that contributes to and is conducive to their success.  We should help every team to discover their own solutions without dictating to them what they should be. That is not to say we cannot suggest possible options to them based on our experience working with other teams. Our expertise is why we are Agile Coaches, after all. However it’s important that we approach each team individually. Every team has a set of unique characteristics, team dynamics and struggles. Understanding and recognizing them is the key to their success.

          Team Logistics

          Let’s talk about the first category I mentioned, Logistics. Logistics is about processes, tools and vision. It’s about how the team accomplishes their goals. For example, does the team have a common vision? Do they have a roadmap? How was that roadmap created? Do they understand their purpose? Do they know how to use the tools at their disposal and are they using them effectively? Are they using the right tools for the task at hand? Does their process work for them or are they working for the process? There is nothing worse than a team following a process that works against their success. This is the fastest way to decrease a team’s happiness and productivity and it will result in sub-optimal solutions. People won’t want to be a part of the team and could potentially leave it.

          The below Matrix is taken – and slightly altered – from a Blog post created by Uday Varma in an article titled 8 Keys to Transforming into a High-Performance Agile Team in the Agile Connection website, which is an incredibly useful resource for Agile Coaches and Practitioners. I find it extremely valuable when discussing possible reasons why Agile teams fail to reach high performance and I reference it often. I love being able to use materials that are already out there and created by other Agile Practitioners to help us in our quest for continuous improvements and learning. If anyone finds anything I write useful, it would bring me immense pleasure to know it is being referenced and used to help others in their Agile Evolution. In any case, I want to give a shoutout to Uday! 

          We used Uday’s matrix as a starting point. We then added the last column on the right as part of our discussion about potential strategies for reaching high performance, and we captured it in a confluence page for everyone in the organisation to make use of. I should point out that there are other reasons a team may fail to reach logistical high performance. If you are an Agile Coach for such a team, work with them to identify the reason, its root cause, and strategies to address it. Below is the matrix that we, at Stuart, have put together by combining Uday’s original Matrix with the strategies we identified to help us resolve them.

          agile table 1

          Click here to consult the full table

          These aren’t the only areas  where a team might struggle logistically. They are the areas we spoke about in our Community of Practice. Your team may share some of these struggles and may have some that are unique to your circumstance. My point here is not to iterate every single area where a team might struggle but to suggest that Logistical discipline is one of the aspects that is key to your team’s success.

          Team Dynamics

          Let’s talk about the other category I identified, Team Dynamics. This is where it gets tricky because every team dynamic is different. To create outstanding Team Dynamics, Servant Leadership, influence management and social engineering all come together for the greater good of the team. An Agile Coach, or anyone in an Agile team, needs to be aware of the dynamics within the team and needs to have an understanding of how to help the team dynamics evolve. There are many lines of thought around this. Everything from learning frameworks like Shu Ha Ri to different leadership styles  Regardless of how you approach it, if you understand team dynamics, then it almost doesn’t matter what kind of leadership style you employ (except for command and control, we don’t like command and control). For this I use the Tuckman model. I find it useful and easy to follow. It is universally relevant. Every team, in my experience, goes through these stages. It doesn’t matter if they are an Engineering team, HR, Finance, Operations, or an Agile team. EVERY team goes through this process. It is also important to point out that teams can progress or regress through the model depending on the circumstance.  So…. What is it?

          The Tuckman model describes the stages a team goes through in its journey to high performance. There are five stages. Each describes the team’s overall characteristics at that point in time to give insight into where and why a team might struggle. In our conversation with the Community of Practice, we discussed the model and identified some strategies for how to develop a team into the next stage. Again, these are just examples, you may come up with more strategies for your specific team. Additionally, teams may progress through some phases faster than others. The key is to have patience and understand that a team is made up of individuals, each with their own needs and desires.

          The Five Phases

          The image below is taken from Toggl Track: 5 Stages of Team Development and I feel it succinctly and elegantly describes the five stages.

          five stages infographics

          Understanding how to identify the phases and the characteristics that make up each phase is only the first step in the process of team development. Developing strategies to move a team through higher levels of maturity is key, as is understanding what may cause a team to move back to a previous phase.

          Stay tuned for Part 2 which explores some of these strategies. Coming soon!

          0 ¡Interesante!