Currently, I am working with a team that is transitioning to XP. Besides coaching the team, I am coaching one individual to be a coach so he can eventually be the team's coach. As a result, I have been thinking a lot about the nature of coaching. In an earlier blog post, I noted some of my thoughts on the abstract and theoretical components of coaching. Here, I am sharing (for what its worth) some practical guidelines for an agile coach.

Identify Expectations

Start by identifying stakeholders. I consider a stakeholder to be anyone that has an interest in the outcome of the project or will be a participant. I include developers, managers, testers, marketing staff, technical writers, and others. For each member of this list, I try to identify what are the expectations and goals of the member (or group). I prioritize the expectations and assign a weighting. I actually treat the expectations as XP stories. I will use 3x5 cards; I track the member or group that "sponsored" the story, its weighting (or cost), and priority. (I know there are other techniques, such as some multi-letter acronym matrix; these alternates always struck me as too complicated).

Take an Agile Approach

Without getting too metaphysical, I take an agile approach to coaching. (See this blog post on qualifications of an agile process.)

Retrospectives are an invaluable feedback mechanism. They should be done at the end of each iteration and the feedback received should be enacted upon.

Johanna Rothman suggests one-on-one meetings with all team members on a consistent basis. Depending on team size, this can range from every week to every few weeks, but I think the more frequent the better. Fifteen minutes to a half hour is sufficient, but the individual attention will be appreciated It provides a more secure and comfortable opportunity for feedback. I even suggest conducting these sessions offsite when possible or over a meal (or both).

Returning to the gathering of expectations and identification of stakeholders, a coach should regularly review these lists and evaluate if the expectations are being satisfied, how have they changed and who are the current stakeholders.

Besides the expectations of stakeholders, try to identify their primary activities and support these activities. In Scrum, the Scrum Master insulates and protects the developers so they can work efficiently. I think the coach should try to do this for the entire team. Unfortunately, this can be complicated to achieve as frequently the needs of one stakeholder are in conflict with that of another (Remember, developers and management are stakeholders). The expectation list should give some guidance for evaluating compromises and tradeoffs.

Regularly assess the team's progress. When possible, try to assist, mentor or in some way help any team member that is having difficulties. Look for buy-in for the process and build on it. Hopefully these early adopters will help champion the cause as a team needs to take ownership over their process. Otherwise they won't maintain it or maximize its effectiveness.

Each of the suggestions supports each other. Retrospectives help discover expectations and needs, etc.

Ultimately the coach is part leader and part manager. In my opinion, the ideal coach doesn't have to do much as time goes on; the team chugs along by their own steam.

This is particularly fun for the XP coach as you do all this and write code too! (Context and expectations of the coach will determine the balance of activities the coach will do.)

(Ron Jefferies and Bill Wake conduct a nice tutorial on being a coach. There is a good book list that can be found at http://www.xp123.com/xplor/xp0307/index.shtml.)