As an Agile Coach, people occasionally ask me for help introducing agile to their teams. When asked these questions in the past, the approach I used to take was to dive deeper into the team’s intent and goals. Instead of pushing practices or tools, I would ask them what they were trying to achieve with agile in the first place and if they understood how well they were serving their customers. But I often had to do a lot of explaining with that approach as it was rare for teams to think that way.

My current approach to coaching teams starting their agile journey revolves around retrospectives and having teams start by reflecting on their work and surfacing their pain points. This approach focuses on continuous improvement as the primary driver for change.

Don’t Start With Practices

I never advocate introducing agile through standard practices like stand-ups, Scrum Masters, Product Owners, or metrics. None of these practices are inherently good or bad, but believing them to be universally good and pushing teams to implement them can create unnecessary waste and even long-term debt if they don’t address a specific need within your team.

In the worst cases, these practices can lead to something you might call “Practice rot.” Practice rot happens when a team has adopted practices that become very difficult to get rid of, that don’t add any value, where nobody is engaged, and people only do the bare minimum. These situations are challenging to get out of and often result in management blaming team members.

If a team comes to me and asks for advice on implementing agile practices, that’s fine, but from now on, the only thing I’m going to push onto teams stubbornly is to do more and better retrospectives.

What’s Grabbing the Team’s Attention?

Instead of starting with practices, teams should focus on surfacing and addressing the problems people face. That could be many different things: What feels out of control? What are they unhappy with? What’s stealing their focus?

When starting an agile journey, it doesn’t matter what practices a team does or what meetings they run. Those things don’t matter because you can’t say that changing any of those practices will make the team more agile.

Teams are already working in a certain way, and trying to begin an agile journey by forcing new practices onto them could disrupt their work and make things worse. Starting an agile journey by pushing practices onto a team also strips them of their chance to self-organize.

The only thing that matters for teams starting their agile journey is developing the ability to self-organize and solve problems.

The Retrospectives Tell You What To Do

The goal of starting an agile journey with a heavy focus on group reflection, retrospectives, and improvement is to stop the pain and fix whatever problems have the team’s attention.

When starting with retrospectives and continuous improvement, a challenge is there’s no one right way to do it. It’s harder for teams to develop their own approach than to adopt a structured process, and it can cause problems if a team thinks that bi-weekly structured retrospectives are the only way to do continuous improvement. Teams will run into issues if they prematurely adopt a particular approach and stick with something that isn’t working for them.

Retrospectives can be flexible and don’t have to follow a rigid format or schedule to be effective. Most teams do their retrospectives by holding meetings with structured exercises every two weeks, but organizing casual weekly conversations about what’s not working is also acceptable. It’s also just as fine for a team to come together to fix issues in real time as they occur. Each team should start somewhere and discover what works best for them.

The continuous improvement process should be self-reinforcing, allowing the team to improve not only how it works but also how the team learns and grows. An evolving team with the ability to get better at getting better is likely to find success in its agile journey.

Avoid Abstract Concepts

Even though I think it’s generally helpful for teams to be aligned and work towards a common goal, unless that’s where the team wants to start, I don’t recommend beginning an agile journey by pushing those ideas or other similar high-level concepts like purpose or North Stars.

If these ideas don’t match the team’s current thinking patterns, having an Agile Coach introduce those concepts can challenge teams, which could make them defensive, skeptical, or potentially even dependent on you.

Instead of pushing high-level concepts, I encourage teams to reflect and discuss their current problems. Unlike externally imposed ideas, focusing on issues and improvements the team identifies guarantees that an agile journey will start at the level that matches their current thinking patterns and the problems they care about.

If the team identifies problems involving its goals and purpose, then great, but don’t push them to start there. It’s important to respect where the team is and start by helping them where they are rather than forcing new ideas onto them.

Conclusion

When helping a team start its agile journey, avoid focusing prematurely on complex practices or idealistic solutions. Start where the team is, emphasize self-directed problem solving, and allow them to navigate their own path forward.

Agility doesn’t happen by adopting new practices or roles; trying to do so can cost more and set teams back months or even years. Starting agile has more to do with changing the patterns of interaction that happen in a team. Teams will be more successful if they slowly start reflecting on what’s not working, addressing real problems, and adjusting their approach along the way.

Instead of a surface-level practice-focused agile adoption, emphasizing retrospectives and focusing on the problems the team faces will establish the foundation for more sustainable, meaningful change.