Why Agile Isn't Working For You: The Top 5 Agile Coaching Pitfalls

Note: This article is co-written by Viktor Cessan 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 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:

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:

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:

4. Not pushing for 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:

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:

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.

The First Question to Ask When Building Teams – Is This Really a Team?

Note: This article is co-written by Viktor Cessan and I. You can also find this article on his blog.

Have you ever wondered why so many organizations fail at building effective and high performing teams despite offering so much support in different ways e.g. by managing people, by managing the environment, and by coaching teams? You’re not alone. This is often something that frustrates teams, coaches, and managers.

You’d think that given all the support that teams receive, they would have great chances for becoming high performing. What our experience shows us, and research, is that it’s more uncommon than common for teams to get to a high performing state. While there are many reasons to why this happen, in this article we’re going to look at one often overlooked aspect of coaching teams. That is, whether the team in fact is a team or not.

Teams, Pseudo-Teams, Temporary Alliances, and Co-workers.

You might assume that if you put together a bunch of people and give them a goal, they’re a team. But that’s not how it works. While all constellations are working groups of some sort, in order for a working group to be considered a team two criteria need to be met.

First they need to have a common/shared goal and second they need to truly need each other to reach that goal. The need can be objective, e.g. that someone has accesses or a necessary skill-set I lack, or the need can be subjective, e.g. I’ve come to prefer a collaborative way of working such as pair or mob programming. But only when these two criteria are met, a working group can be considered a team.

Pseudo-teams

Teams where the members do not necessarily need each other to reach their goal, despite the goal being shared, are merely Pseudo-Teams. In Pseudo-teams members often, but not always, report to a manager who assigns goals to the members individually or they do it in pairs. Sales teams, Customer Service Teams, Component teams, Channel teams (e.g. iOS, Android) are some examples where members from an objective standpoint often can accomplish their work and reach their goal without needing the help of other people in the working group.

Temporary Alliances

When co-workers need each other for something specific but they don’t share a common goal they form Temporary Alliances. Examples of this are team members that embed perhaps to help a team adopt a new technology. Alternatively if I need to get help from IT-support, or a new entry card to the building and I ask office management for help, I have formed Temporary Alliances. Knowledge sharing guilds are also examples of Temporary Alliances. A Temporary Alliance can last anywhere from minutes to months.

Co-Workers

When team members don’t share their daily goals and they don’t need each other to achieve them, they’re just co-workers.

Common goal is both objective and subjective.

While the need for each other can be either subjective or objective, having a common goal needs to be both subjective and objective. If a common goal is shared by the people in the team but the rest of the company doesn’t believe that’s the right goal, those forces will work to disband the team.

If the company has a shared view of what the goal should be but only a few in the team share that view, sub groups will form. And of course most work can be linked towards the company’s overarching vision but that’s not what we’re talking about. We’re talking about goals as in daily work, monthly goals, quarterly goals, a year or years-long specific missions.

So whatever the goal for the working group is, it has to be both objectively and subjectively shared.

Knowing your type of working group

It’s crucial to pay attention to whether or not a working group is a team because it dictates what kind of structures to build and how to support the team. We see organizations spend tremendous amounts of energy in trying to coach Temporary Alliances and Pseudo-Teams as if they were teams, when in fact the kind of support those working groups needs is very different from what a team needs.

Not only is this a wasted effort it’s also highly demotivating for the members to engage in activities that attempt to foster collaboration when it’s not necessary. Examples of this are daily stand-ups with people who don’t have any real reason to sync other than to possibly keep their manager updated (it’s really common still) – ever heard standups like this: “Yesterday I went to these meetings, today I may think about this and attend these workshops, and I don’t have any impediments” or “What are you going to do today”?

Frequent offsites with Temporary Alliances aimed at team building with extensive getting to know each other exercises or talking about roles and responsibilities are also examples of misdirected efforts.

Only teams need to stick through the rough times

Different working groups are affected by group dynamics in different ways. A team has to get through the rough times because they do need each other. A Temporary Alliance will often never work together long enough to get to the storming phase (see Tuckman’s stages of group development) or they may change or disband the alliance because they don’t really share a common goal and they don’t need to stick through difficult times. They can only fake it until they don’t need to.

The same goes for a Pseudo-team. When the times get tough, the team members can either try to work their way through the difficult times or they can just stop showing up to meetings, work from home, etc. They simply don’t actually need each other.

Would you like to learn more about to manage group dynamics?

Viktor and I hold training courses about building teams and managing group dynamics. We have versions tailored for managers, agile coaches, scrum masters, product owners, and entire teams and will also adapt for mixed groups. Reach out to either of us to find out more.

The biggest lessons from a successful software project

In my years of working with software projects the one thing I have learned is that doing software projects is really hard. Probably zero projects I have been part of or heard of has delivered their value, kept the quality to a standard everyone is proud of, launched on time and had a team of happy people through all of it. Recently, though, I was part of project that did just that. An actual real life professional software project that was deemed successful by both the team and the stakeholders.

I work at Swedish real estate site Hemnet. We are a company of about 50 people with about 15 people working in product development — mostly developers plus a few designers. Being a small company means we are close to management and all fill a bit wider roles than in larger companies. The biggest challenges in our organization has been making priorities and following them through. This heavily influences where we have put most of our effort and where we have made the biggest lessons making, though I think most of it can be pretty broadly generalized.

The team consisted of one UX designer, one graphics designer, one business analyst, one dedicated developer and me as team lead and part time developer. With the team of 5, we switched map providers, created a solution to render 100 000 hits on a map simultaneously and designed and implemented an all-new view for searching on maps. We did this in just 6 months and, from the release date set in the beginning of the project, slipped only one week with being fully rolled out.

Before we get in to what did matter, let me point out that you can Scrum, Kanban or Scrummerfall all you want without getting much of results. It’s easy to try to change the internal methodologies of a team because that’s something you’ve got complete control over. The biggest challenges though, are in getting the right conditions for the team and within the organization. Only after that is settled does methodologies begin to provide real value.

Here are the biggest things that made the project succeed.

A team with power to do its job

This is where everything begins. Way too often, projects are spread out over departments and even split in sub-projects over different departments. The business side is done in one project, handed over to a design project and then handed over to a development project. And even if that is not the case, people are still spread out without good means to focus and communicate on the project. This completely kills the common understanding and collaboration within a project.

Our team was created with exactly one premise: the goal of the project. We were to create the new map search experience on Hemnet. How would it look? Find out. How would it work? Find out. What would it even do exactly? Find out. This was absolutely crucial in enabling us to do our work — we are product developers and excel in solving problems. Based on the goal, the team formed the plan to do it, the concrete requirements and features and did all the design. Except for getting the rest of the company to buy in on our plan, we were never in need of someone else’s decision.

This of course requires the team to have all the competencies needed to get the job done. Having a team with a common understanding from start to end has incredible value in ensuring everyone works on the same thing and towards the same goal to create a cohesive product. In our team, having our business analyst from start to end allowed us to not stray away from business goals, and having everyone with from the beginning ensured we all really understood why the heck we were in this to begin with.

One of the factors we all appreciated the most was being all together in a room dedicated for the team and the project. If you are in an office, the change from being just one room apart is a huge boost to the social aspects of the team and the collaboration made possible by putting sketches up on the wall and just leaning over to talk about something is invaluable.

Making sure of a stable team with the right conditions is where everything begins.

Awareness of what could go wrong and preparation for it

Things always go wrong. The problem is that we more often than not ignore this and just plan for the best. This results in everything going to pieces when an assumption turned out to be wrong or an unforeseen problem arises. As a result, projects usually hit a point where everyone gets uncomfortable over something that went wrong and starts arguing over how to proceed — a situation where exactly nobody has their best ideas.

We spent a lot of time in the beginning of the project trying to figure out where things could go wrong. Being aware of the risks is key to being able to react in an intelligent way when something eventually goes wrong. In our case, we identified where users were most likely to have a hard time with the change and what business related key measurements we were most likely to impact. We completely shaped the project around the risks and made sure everyone understood and were prepared for the things that could go wrong. This helped us adapt continuously and completely avoid disasters, both in the product itself and among people in the company.

The plan we made focused on the key features that would be realized in the project on a higher level. This allowed us to cut the right corners in times when time started getting sparse while still delivering the value promised. We also spent time discovering where scope creep would most likely pop up and discussed these points beforehand. The things we agreed on not doing were then part of the plan. Designing the plan in terms of general features and including the things we would not do was a key tool for us in delivering the project on time.

Plan as much for the risks and the things you won’t do as the things you will do.

Collaboration outside of the team

All developers have been in projects where requirements and conditions change over their heads. A manager changes his or her mind on something too late in the project or another project gets important and starts snatching people. This is one of the most effective ways to demoralize a team trying to make something great and is probably also the most common way I have seen projects go out of control. The problem here is that managers often have no ability to make sense of cryptic scrum points, refactorings and vague descriptions of what is done and what isn’t, which forces them to make decisions with effectively no information on what they are deciding on.

First off, we put a lot of effort in communicating the plans for the project. We made sure everyone with the power to change our faith were fully aware of the plan, including what we would do, what we would not do and what we needed to complete the project. We did this early enough that we still could change everything and made sure that all stakeholders had their say before nailing it.

During the project, we continuously discussed any change that would affect stakeholders with them and held recurring demos open to anyone in the company. This allowed us to work without dropping anyone’s perspective. We had a number of small changes come out of this that would have gotten into big problems if they wouldn’t have been revealed until the end of the project.

Keeping managers and stakeholders in the loop is key to having the project stay it’s course.


There isn’t ever a silver bullet with these things. These were the biggest contributors to this specific project being a success. Even though I have reason to believe they would help significantly in many situations, a project always have to start with the people and environment where it will live.

We have the brilliant Thomas Lindquist as our full time coach working on process and people since two years. This project is the result of those two years of experimentation and much of the reasons why it succeeded are the brainchildren of Thomas’ continued thinking on the matter. This may seem too obvious, but the best way to get better at process is to spend time thinking about it and improving it.

If you are interested in more on this particular project, Thomas has written on the “post-mortem” retro we held with the team, our graphics designer Daniel Feldt has written on his perspective of the project and our UX designer Magnus Burell had a talk on the UX side of things. And for the more technical side, our map-oriented developer Igor Tihonov will talk on this year’s FOSS4G in September.

Riding the ages

Technical revolutions such as the Industrial Revolution are periods where the whole world gets revolutionized one area at a time by big contemporary technical breakthroughs. The breakthrough isn’t of any value by itself, but by revolutionizing a large amount of areas we care about, the technology becomes the largest driver of its time.

A revolution runs until the contribution of its values on the world has stagnated. We can no longer make a new machine that halves travel times or frees up as much time for people as the dishwasher does, and so the Industrial Revolution has peaked and room for the next revolution appears.

We’re now living in the ages of the Information Revolution. The driver this time around is the ability to process and communicate information at an ever increasing pace. Just as the goal of the Industrial Revolution turned out to be making manufacturing ubiquitous, the goal of our time must be to make information ubiquitous.

There is still the challenge of creating something of actual value for people — because without actual value that something will not gain momentum enough to move the world forward — but the path forward is clear: getting better information into people’s hands.

Someday this revolution will be replaced by one of another age, but for that to happen, we first all have to move the world there using our time’s biggest breakthrough; by creating valuable ways for people to use information in all the different areas we care about.

Creating experiences

You could create something that delivers an account balance to its account owner, something that helps visualize spendings, or something that helps people create perfect savings budgets. Or you could take on the problem in its entirety and combine all of those things to create something that is far greater than the sums of its parts.

In the first example you’re just giving people tools and leaving them with the challenge of figuring out how to make sense out of their economy. In the second you’ve got the potential of creating an experience that solves managing money without forcing someone into copying and pasting numbers into giant spreadsheets.

People with a specific interest in the subject will still want their tools, but people usually only have a few of those special interests. All the rest of the problems we’re facing every day are things we want to hassle as little as possible with in order to be able to focus on the things we really care about.

There’s enormous room for making great experiences out of all those problems people are faced with every day. Our world may be driven by increasingly complex problems, but that doesn’t mean we couldn’t solve those problems with wonderful experiences and at the same time allow ourselves to live simpler lives.