The Role of the Agile Coach


stays with the team for the duration of the work. An Agile Coach may stay with a team but they may also move on, or they may stand back over time.

On an assignment last year I coached several teams at one company. Initially I started with some training and by walking each team through the Agile ceremonies – planning, daily meetings, retrospectives, etc. As the teams became more familiar with the activities I reduced my involvement and allowed team members to take over.

Again, this approach casts the Coach as change agent. It may be that teams need different coaches at different stages of their development: A technical coach to help the developers master TDD; a second Coach to lead the team through early adoption and a third to refine the processes and practices later.

Much of the Coach’s work is about changing individuals’ mindsets, the mental models and short-cuts which they have build up over years. As my fellow Coach Niels Malotaux put it recently “Coaching is about resetting people’s intuition.”

There are hundreds, even thousands, of small decisions made every day during software development. These decisions are based on people’s mental models of how development works – or how it doesn’t work. Part of the Coach’s role is to help people unlearn many of these models and relearn models based on Agile values.

Cumulatively these many small decisions are more important than the few big decisions made occasionally. By definition big decisions aren’t made that often and you usually know they are being made but small ones are made without thinking. It is no use switching to Agile if you keep making the small decisions based on some other model.

The architect Mies van der Rohe once said “God is in the detail” and so it is with Agile: “Agility is in the detail.” It is the small decisions that can’t be seen in advance that often derail work. It’s the Coach’s job to help spot the small decisions and ensure they Agile principles are applied.

Part of the reason I prefer working as a Coach with a team rather than as a Trainer is because you see the change play out over time. Yes I deliver training but when I’m gone do people use it? When I’m there as a Coach I walk people through the changes, the details and I see the change happen.


Rolling Out Agile in a Large Enterprise, International Conference on Software System, Hawaii, 2008

Coaching for Performance, John Whitmore, 1992

Effective Coaching, Myles Downey, 1999


About the Author

Allan Kelly helps companies improve their performance by adopting Agile development. He works as a coach, trainer and consultant to companies large and small and is based in London.

He is the author of “Changing Software Development: Learning to become Agile” (2008), holds BSc and MBA degrees and works for Software Strategy ( He is currently working on a book of Business Strategy Patterns. More about Allan at



User Comments

1 comment
Leyton Collins's picture

Love the article. The challenge of course being sometimes the team doesn't think they need a coach. I've found there is a need to proceed oh so carefully (and sometimes frustratingly) when that is the case. 

May 18, 2014 - 4:40pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.