One of the new roles introduced by Agile software development is that of the team Coach. Until Agile came along coaches were confined to the executive suite or the sports field. As with any new role it takes a while before it is fully understood and scoped.Agile teams can, and do, exist without the Coach role being filled but such teams do not necessarily achieve peak performance. Reports from Yahoo* suggests that coaches can make a significant contribution. In this study Scrum teams without coaching support increased their productivity by 35%, while those with Coach support recorded 300% or greater improvement.
What then is the Coach’s role? And what does a Coach do?
For some people the title Agile Coach is self-descriptive but for others it leaves the questioner none the wiser. So let me offer a definition: an Agile Coach help a teams or individual adopt and improve Agile methods and practice. A Coach helps people rethink and change the way they go about development.
Trainer and consultant
The Coach role is part embedded trainer, part consultant – specifically an advisor. Even the best Agile training courses cannot cover every detail or eventuality a team will encounter. The Coach is there to continue the training after the formal classes are over.Having an onsite Coach will help team members put their training into action. Too often people attend training, think it’s good stuff, and then fail to incorporate their new learning into their daily work. This is particularly true when the organization sends mixed messages about change.The Coach also helps teams apply Agile and Lean thinking to the specific environment and impediments they face. Working as an advisor the Coach can help the team adapt the methodology to their environment, and help the team challenge the existing environment.Taken together these two sides make the Coach into an effective change agent - someone who is both motivating change and making it happen. That an organization is prepared to spend money on a Coach demonstrates they are serious about making the change happen.So as well as helping the team execute the Agile vision the Coach may also help motivate the team to that vision. The Coach does this by painting a picture of how the Agile world works by telling stories and providing explanations.
Three types of Coach
While every Agile Coach brings their own approach to an assignment there are broadly three types of Coach. The first is technical, such a Coach works mainly with those cutting code and sometimes becomes fully integrated with the developers. Technical coaches are likely to be found pairing with developers to help them apply test driven development, support developers in refactoring work, help improve the continuous integration system or other activities that are close to the code.Technical coaches are experts in what they do, they aim to both transfer their knowledge and enthuse team members to try new approaches and techniques.The second type of Coach is again an expert who aims to transfer their knowledge however the focus is not on technology but on process, management and requirements. Coaches like myself work with project managers, line managers, business analysts, product managers and others who are responsible for making the work happen.Rather than working at the code-face coaching tends to happen in meetings and in one-on-one sessions. There is a greater focus on facilitating events that help create change and improvement.For example, in addition to moderating stand-up meetings and planning meetings, I normally run retrospectives and “future-spectives”. A future-spective is an event which applies many of the same ideas and techniques as a retrospective but is used to kick-off a new project or Agile transition.When working with managers there is more to coaching than simply knowledge transfer. It is much more about helping people rethink their inbuilt assumptions and mental models. Many managers have experienced career success with other development modes so may perceive Agile as a threat. Here coaching gives way to the third type.The third type of Coach may work across everyone in the team but mostly finds himself working with managers and analysts. In this mode the Coach drops the expert persona and focuses instead on helping individuals and teams solve their own problems. To do this the Coach takes on a non-directive approach. When working as an expert authority the Coach is providing direct advice and recommendations. This is known as directive coaching. In the non-directive mode the Coach may – or may not – be an expert in the field but they assume the coachee is the expert and the Coach helps facilitate their learning.While directive coaching is often found in sports teams the non-directive approach is used by coaches who help business leaders. This approach is set out in books such as Coaching for Performance** and Effective Coaching*** and anyone thinking about embarking on this approach is well advised to read at least one.The diversity of coaching roles makes it difficult for one person to fill all. A technical expert will find it difficult to switch to a non-directive mode and team members may be confused when an expert starts throwing questions back at them. Even if one individual can cover all bases on all but the smallest projects there is unlikely to be enough time to do each role justice.
Longevity of coaching
However a Coach works, and whatever approach they take they the Coach needs to avoid creating a learned dependency. This happens when the team comes to depend on the Coach, without the Coach the team fall back to their old ways. Coaches need to be able to withdraw when the time is right and let the team continue.While many companies will have their own coaches on staff and some will work with teams day-in, day-out for months or even years, there is a lot to be said for using external coaches and limiting the period of coaching.While internal coaches will start with the advantage of knowing the team and domain, external coaches benefit from bringing a fresh mind and new perspective. This allows them to challenge assumptions more easily and suggest alternative approaches.Some coaching activities – such as running retrospectives – can become stale and formulaic over time. Changing the facilitator can inject energy and new ideas.
Scrum Master or Coach?
As an Agile Coach I am frequently asked “What is the difference between a Coach and a Scrum Master?” Indeed, there may be very little difference if a Scrum Master decides to play the role from a coaching perspective. However this is not always the case, some organizations see Scrum Masters as thinly disguised Project Managers. In such cases the difference between Coach and Scrum Master is wide.There are perhaps two main differences between the Scrum Master and Agile Coach role. In Scrum the Master is tasked with ensuring the team follows the Scrum process and rules. An Agile coaches remit is somewhat wider with a greater emphasis on the change agenda.As such, the second difference is one of duration. All Scrum teams should have a Scrum Master who works with the team in every sprint and 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.
Conclusion
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.
References:
Rolling Out Agile in a Large Enterprise, International Conference on Software System, Hawaii, 2008, http://www2.computer.org/portal/web/csdl/doi/10.1109/HICSS.2008.382
Coaching for Performance, John Whitmore, 1992
Effective Coaching, Myles Downey, 1999
Sunday, July 19, 2009
Subscribe to:
Posts (Atom)