What does an Agile coach do?

I often describe myself as an Agile Coach. In fact coaching teams in Agile development is only part of what I do but its the only bit that fits in two words. For some people the title Agile Coach is self-descriptive but for others it leaves the questioner none the wise.

With, Clark Ching’s recent blog about bread as a prompt, here is what I do as an Agile Coach.

The Coach helps teams adopt and improve Agile methods and practice. A Coach helps people rethink and change the way they go about development.

The Coach role is part Consultant and part embedded Trainer. My task is to help individuals understand how to apply Agile ideas in practice. Part of this involves painting a picture of how the Agile world works by telling stories. It involves explaining how to tackle specific problems, in a specific environment.

I tend to work from the process and management side, so I spend most of my time with team leaders, managers, business analysts and product managers. I attend their regular meetings and hold one-on-one sessions to help them try new approaches to the problems they face. That could be project planning, talking to the business, talking to the development team, or about ongoing problems.

Some Agile Coaches get involved with the technical side. They will pair program with developers and help them write tests for TDD. I don’t normally get involved with the actual coding any more but I do spend time with developers. Sometimes these are one-on-one conversations to address specific issues raised by managers, and sometimes they are conversations initiated by developers themselves. They have a question, they come to me and together we find an answer.

I also work with the entire team – managers, developers, testers, etc. – to help improve the team performance. This typically starts with a discussion about Agile, or a process mapping exercise. When a team is first starting out with Agile I like to run what I call “future-spectives”, or “reverse retrospectives”, in which the team choose the practices they would like to adopt.

Initially I run planning meetings, stand-up Scrum meetings in the mornings, reviews and retrospectives. Over time I like to hand these meetings over to team members to run themselves.

As the team improves I introduce new practices and new exercises. Gradually the team starts to look like a true Agile team. I think you need about six weeks to lay the foundations - hence my Scrum Foundation Programme.

I also help remove block and impediments when I can. It can also be as simple as buying books, or (as on a recent engagement) persuading the company to spend money on more technical training for the teams.

There are hundreds, even thousands, of small decisions made everyday 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.

I’m often heard to say that it is in these thousands of small decisions that success or failure hides - “God is in the detail” or “The Devil is in the detail” if you prefer. By definition big decisions aren’t made that often and you usually know they are being made but small ones are made without thinking. Its no use switching to Agile if you keep making the small decisions based on some other model.

Its these small decisions that you can’t see in advance that can derail work. That’s part of the reason I prefer working as a Coach with a team rather than as a Trainer. 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, and I can provide any training as we go.

Each team is different so the approach has to be different every time. It also means that while I describe myself as an Agile Coach I sometimes work in a more interventionist manor. On occasions I will take over the management of the team – as a Development Manager or Project Manager – and help the team change that way.

Working this way is actually harder. Working as an external Coach you are looking into the team and you can see what is happening more clearly. When you are inside the team its often more difficult to see what needs doing. That said, once you have decided on action it is usually easier to make it happen.

On other occasions I’m more of a hit-and-run Consultant. I arrive, I talk to people, I make recommendations – perhaps write a report – and move on.

Finally, working as a Coach isn’t, and shouldn’t be, a full time job. I’m always conscious that the team shouldn’t become overly dependent on me. I prefer to spend only couple of days a week with a team – although when a company has several teams I may end up switching between them during a full week.

So that – briefly - is what this Agile Coach does for teams. And if you think some of this would help you please give me a call - 0845 310 8366 (UK), allan@allankelly.net. (Yes, that last paragraph is self serving but this is my blog!)