What does an XP Coach/Mentor actually do?
One of the things I do is XP coaching and mentoring. But a question that keeps cropping up (bizarrely, often after I have been hired!) is "What does an XP coach/mentor actually do?".
Interesting question. And is there a difference between a Coach and Mentor?
In my opinion there is a slight difference, but first the common ground.
What both do is to guide a given team through the learning process of implementing XP. It is the responsibility of the Coach/Mentor to gently guide the team around the pitfalls by encouraging the good agile behaviours - communication, testing, team self review etc. Equally, destructive behaviours - slipping into mini-waterfall process, not talking to (or not having!!) customers etc - are discouraged.
Often the best way of doing this will be from inside the team, demonstrating by example the power of the techniques. IMO this is the "Coach" part of the job description.
As the team begins to understand and becomes truly self-organising, the Coach must become less involved if the team are to stand by themselves. But they must still have the skills to keep themselves on-track. This is the "Mentor" stage - when the team is trying to stay agile after getting the idea. This stage involves acting as more of a sounding board for ideas; a sanity check that the decisions made as the development process adapts and evolves are correct and not reverting to traditional waterfall. I have found that this often involves acting as an über-team lead, advising the existing team leader and/or experienced engineers on how to handle specific situations but generally not solving the problems for them.
Interesting question. And is there a difference between a Coach and Mentor?
In my opinion there is a slight difference, but first the common ground.
What both do is to guide a given team through the learning process of implementing XP. It is the responsibility of the Coach/Mentor to gently guide the team around the pitfalls by encouraging the good agile behaviours - communication, testing, team self review etc. Equally, destructive behaviours - slipping into mini-waterfall process, not talking to (or not having!!) customers etc - are discouraged.
Often the best way of doing this will be from inside the team, demonstrating by example the power of the techniques. IMO this is the "Coach" part of the job description.
As the team begins to understand and becomes truly self-organising, the Coach must become less involved if the team are to stand by themselves. But they must still have the skills to keep themselves on-track. This is the "Mentor" stage - when the team is trying to stay agile after getting the idea. This stage involves acting as more of a sounding board for ideas; a sanity check that the decisions made as the development process adapts and evolves are correct and not reverting to traditional waterfall. I have found that this often involves acting as an über-team lead, advising the existing team leader and/or experienced engineers on how to handle specific situations but generally not solving the problems for them.
Comments
Post a Comment