Reading Time: 6 minutes
Note: This article is written by Stefan Lindbohm and I. You can also find this article on his blog.
Have you ever felt like, despite tremendous investments of your time and energy trying to coach teams to overcome their challenges, you were just stuck? You knew your team had the potential to be a high performing one, but the same issues kept resurfacing over and over again?
Despite having worked with countless teams and dozens of organizations over the span of our careers as coaches, we too feel stuck sometimes. It’s a natural part of being a coach, whether you’re brand new to the role or have many years of experience under your belt.
In taking a look back at our time as coaches of systems, teams, and individuals, we identified the top 5 agile coaching pitfalls we’ve run into over the years and that we see coaches old and new still struggling with today.
|Note: The following pitfalls are about coaching teams as opposed to other types of working groups. If you’re coaching a working group or any other collection of people that isn’t behaving as a team, you may be better off by starting with addressing the structure of the team itself. Read more about that here: The First Question to Ask When Building Teams – Is This Really a Team?.|
1. Thinking Agile is the answer to everything.
The most common pitfall we encounter is the thinking that being an Agile Coach is simply a matter of checking things off a special agile checklist. Whether that’s explicit working agreements, rigorous stand-ups or planning meetings, or more specific “Definition of Done” criteria, people are sometimes under the impression that just by doing things the “Agile Way” their problems will disappear.
If only it were that easy.
In our experience coaching teams and organizations, agile is rarely appropriate as a first response. In fact, the tensions or conflicts that arise more often have to do with systemic, not individual, issues. An over- or an under-constrained environment, low psychological safety, bifurcation of knowledge, frequent team changes, unproductive team dynamics: these are just a few of the deeper issues that need to be addressed to truly be able to see long-lasting change on a team level. What we continue to see time and time again is that teams that work in an environment conducive to high performing teamwork tend to solve most of their own problems and need limited support with agile.
How to avoid this agile pitfall:
- Take a systems perspective and look at how factors other than agile may be affecting team performance. 9 out of 10 times it’s the environment that’s blocking the team’s progress. A simple framework is Motivation (do people feel their work is compelling/motivating?), Organization (Is the organizational structure conducive to focus and collaboration? Over constrained? Under constrained?), Information (Does the team have the relevant information they need to make decisions?).
- Read up on what creates psychological safety. Start by taking a look at one of our favorite models: the SCARF model.
2. Taking ownership of the team’s problems.
This one is a classic. Coaches are, understandably, very eager to help their teams overcome obstacles and work better together. But sometimes this leads to coaches stepping in and doing too much for the team.
What does this pitfall look like in practice? One common example is coaches thinking up great solutions or workshops for the team without first consulting the team on whether the problem was even relevant to begin with.
At first, this might seem like the right thing to do. You’re solving problems, the team is working better together–all good, right? Perhaps in the short term. But in the long term, this behavior damages the team’s ability to succeed as they learn to rely on you instead of taking responsibility for their own team health. When coaches become part of the operational solution, teams are often squeezed out of ownership of their own improvement. For coaches, this means missing out on opportunities to build more effective and empowered teams.
This pitfall stems from a misunderstanding of a coach’s fundamental responsibilities. A coach isn’t there to solve the team’s problems for them–they’re there to help teams and organizations learn to solve their own problems.
How to avoid this agile pitfall:
- Shift your mindset as a coach. The problem is not, in fact, the problem. The problem is how the team sees the problem: both its importance and their sense of being able to take action on it.
- Before you take action, consider the difference between “I’ll facilitate your stand-ups” (Operational), “I’ll set up a workshop on how to run stand-ups” (Teaching), “I’ve observed X about your stand-up, what do you think?” (Coaching) and keep in mind that, when building teams, coaching tends to be better in the long run.
3. Not paying attention to team dynamics.
The next pitfall coaches fall into is missing one of the most critical aspects of collaboration: team dynamics. Team dynamics explains how capabilities and challenges in a team’s collaboration evolve over time and why. Overlooking this aspect means not seeing and adjusting to the team’s current state and can lead to ill-timed interventions.
But just knowing where a team is at in its team dynamics journey is not enough. Even coaches who correctly identify team dynamics issues still find themselves unable to effect change in their teams–they don’t have all the necessary tools in their toolbox. Though they proactively try to improve team collaboration, they often do it in the wrong way and at the wrong time.
Take for example a coach who tries to run a purpose workshop from scratch with a newly formed team that has yet to form the relationships needed for such a workshop to be effective. In such a case, the result is often damaged relationships and a lower ability to collaborate. This not only isn’t what the coach intended but also makes the team less willing to trust the coach’s ideas the next time around.
How to avoid this agile pitfall:
- Deepen your understanding of team dynamics. A good overview is the Tuckman model. If you want to dig into more detail, one of the best-written sources we’ve found is Susan Wheelan’s (of IMGD) book Creating Effective Teams.
- Have a conversation with your team about team dynamics and your journey as a team. Just knowing what’s ahead and understanding where you are now will help tremendously in coping with the various challenges the team will face as they develop. Consider asking the team to assess where they are now and facilitate a discussion around their assessment.
- Whenever you plan to run exercises or workshops with the team, take a minute to consider what their current capabilities and challenges are, keeping in mind the team’s current group development phase. Are your proposed activities appropriate given their current state?
4. Not enabling early success.
We’ve lost count of how many team bootstraps we’ve been a part of and even coached ourselves that focus on the team getting to know each other on a detailed level, deciding on a process, getting a high-level view of the vision, and even attempting to create a complete roadmap and perfectly prioritized backlog right from the start. This all sounds great, right? In fact, it’s yet another pitfall.
Now don’t get us wrong. It’s great to get to have all these things. But spending 1-2 days on them before the team has done any real work will kill energy and discussions will be mostly unproductive because there’s nothing yet to relate these discussions to. Instead, focus on making sure the team kicks off their time together with some quick wins. Why?
The way that a team spends their time together initially can help set them up for success down the line. It may be tempting to adopt consensus decision making early on to ensure that everyone is on board, but that will take a long time to get in place in a newly established team and delays their first success moment as a team.
How to avoid this agile pitfall:
- Work with the product manager to ensure that there is a clear goal that the team can get started working on.
- Help the team get started fast. Work with, encourage, or even push the entire team for early success, something of value for the customers or the team that can be delivered in the first few days. Only briefly cover longer-term context. The team should leave the first week feeling that they accomplished something and that they’re curious about what they can accomplish next week.
- Find things worthy of celebrating during the team’s first week. Celebrate those things together.
- Expand the scope of work, workshops, and exercises as the team’s capabilities improve over time. For example, run a 1-day offsite one or two months later instead of right at the start.
5. Not challenging the team’s performance.
High energy in meetings may appear to be a great thing and is something coaches strive for. But what if the team is having the wrong conversation? Alternatively, what if there’s no conversation or debate at all and energy is low? Will the team be able to find great solutions to the difficult problems they’re facing? Probably not.
Challenging team performance begins with understanding where the team is stuck right now, but at its core, it’s about helping the team reach high-performing levels.
So what do you do as a coach if the team you’re coaching is stuck? Do you challenge them head on? Give them feedback? Design processes that force everyone to speak up? Or do you perhaps wait patiently hoping the team will overcome their collaboration tensions as they get to know each other better? Whatever you do, that’s what this pitfall is about. Doing something that challenges the team to perform better.
How to avoid this agile pitfall:
- Select a way of challenging team performance that suits their current team dynamics. Consider the difference between “Let’s talk about collaboration, performance will come later” (Performance avoidance), “I’ll facilitate a retro and let you explore your performance level” (Performance facilitation), “Here’s some feedback and I’ll join you in conversations about your performance” (Performance coaching).
- Deliver performance feedback to the team. Be sure to consider what stage the team is at in their team dynamics journey so your feedback is relevant to their capabilities.
- Run a performance retrospective in which the team assesses their own performance on different dimensions such as collaboration, impact on the customer, technical quality, individual productivity, and individual happiness.
Overcoming Agile Team Coaching Pitfalls
Coaching is a constantly evolving, fluid process. It’s both an art and a science, and that means that even as we gain more experience we’ll still come across challenges. It’s part of what makes coaching tough, but it’s also what makes coaching so rewarding. This list of agile coaching pitfalls is an attempt to make some of this fluidity a little easier to grasp, and we hope you will find it of great practical use.
You probably noticed that several of these pitfalls stem from team dynamics issues. We noticed that as well in our work over the years and, over the past year, have developed and run a course on exactly this topic.
We call it the Team Dynamics Training Course, and in it, we address these pitfalls and give you the tools you need to work your way through other tricky situations that may arise in teams. Read more about it on the Mastering Team Dynamics course page.
Nice article, thanks. I’d have one question and one comment.
Question about 3) Team Dynamics, where you write: “Have a conversation with your team about team dynamics and your journey as a team”. Would you recommend to openly state on which maturity stage the team is at (eg. Tuckman’s Storming Phase, or Agile Fluency’s “Delivering Zone”)? Or would you rather keep this hidden from the team? (I guess not).
Comment on 4) Early Success, where you write: “It may be tempting to adopt consensus decision making early…”. I think you may have mean consent-decision making rather than consensus-decision making.
Thanks again, great work!
Superglad to hear you like the post!
To me, the agile fluency isn’t about group dynamics per se. It is about the extent of agile adoption in behavior, mindset, processes, impact. An it looks at different levels of a company. That’s very different from team dynamics which looks at how a teams capabilities, behaviors, and needs evolve over time. As a coach, I would start with using a model, do an introduction to it and then ask the team what they think and what they recognize. If the team struggled I would be willing to share my observations but I don’t see it as my job to diagnose the team on their behalf.
With regards to point 4, no I did mean to write consensus. In consensus decision making everyone has veto power regardless if they have a valid reason to block progress. And when a team is new to each other and new to the product they fear rejection and therefore do not challenge each others ideas. So trying to adopt consensus decision making is particularly risky when the team isn’t comfortable challenging each others ideas, when they don’t know each other, when they don’t know the product.
What are your experiences with consensus decision making?
In my experience , Consensus decison making should be done at a later stages when team is comfortable with eachother sharing their experiences
Coach should make sure the Scrum teams is a good mix of expertise
He should guide the scum masters in indetifying and establishing right mixture of people ie Buslness SMEs /new team mates/Tecnical experts/Testers
Then group discussion/brainstromsessions gives an oppurtunity to learn about each other’s view point about business process/pain point/challenges/strength /weakness/oppurtunies of the organisation how best team can work with each other
Super nice article ! As the article “Thinking Agile” is the answer to everything.
Sometimes we have to figure out the problems by our self. We always need to support our team because if our teams work with more efforts and confidence their is always a hope
to complete the given work in a given period of time.I also can across a blog where the topic of the blog is “8 Reasons to use Agile”. In this blog they have explained The agile technique characterises the business object and success bench
In this blog I have explained The agile technique characterises the business object and success benchmark in small gain, taking a project between various rounds of development, deployment, and testing. It varies from what we call the waterfall method, which took the project from its first step to deployment.
Click here to read my full blog : https://bit.ly/3i8Ip7j