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.)

I think the mission of an agile coach is to keep a project on the road to success. He monitors the effectiveness of the team and makes adjustments as necessary.

My father compares parenting to bumper bowling; a parent's job is to keep the ball out of the gutter. But, if their child is not approaching the edge, the parent should let the child find his own way.

Similarly, a good coach provides guidance but allows (and hopefully encourages) a team to find their own identity. It's critical for a team to take ownership of its own process if they are to maintain and adopt it. In my experience, a team will not maintain or effectively utilize an agile process, over the long term, if the coach is the only champion of the process.

Returning to the parenting analogy, the early stages of a child's development are where the parent's role is the clearest; the world is fairly black and white. But as the child develops into a teenager and young adult, the situations, decisions and consequences are more complicated.

The same is true for an agile coach. In the early stages of the coach's involvement, the team is the most willing, as they will ever be to take advice on faith. The coach can demonstrate techniques, discuss experiences and respond to questions; but the expectations of the coach are largely about process. At this time, the coach is relying on her own abilities to communicate the effectiveness and motivation of agile processes; this is the most amount of control the coach will have.

But as with the developing child, things get complicated. As the project ensues, the expectations quickly shift from process to results. Where the customer was happy to see any piece of working software in the beginning, she now has expectations of high productivity. The coach is now relying on the aptitude of the team; the coach has less direct control and must mentor the team such that they produce effectively.

As the expectations of the team increase, credibility and trust are necessary for effective coaching. Any latitude the coach will have with the team, be it management or developers, will be based on the experience of the team with the coach. It is a form of currency; successes are credits and problems are debits.

Each adjustment the coach makes is also a debit. The more direct (i.e. dictatorial or authoritative) the action, the larger the debit; subtle actions cost less. The coach has to be careful not to bankrupt herself; the skillful and wise coach judiciously spends in order to maintain reserves. A team is far more likely to trust a coach when she directly and obviously intervenes if they don't feel she is constantly crying wolf.

The master coach facilitates success by influence and suggestion. A coach shouldn't issue mandates. A good coach is a catalyst and his coaching, at times, is imperceptible. But a team usually knows when they have a good coach.