Do We Really Need An Agile Coach?
Posted by Abhishek Agrawal in the early morning: April 10th, 2008
Coach – To help someone achieve their goals. To help them achieve it with efficiency, even perfection, to listen to people, to TALK to them! To see their excitement, suspicion, energy… Doesn’t that trigger a nerve of passion?
I had the wonderful opportunity to have one of our Agile Coaches, Guido Schoonheim, fly down to India and have a word with me regarding what it takes to be an Agile coach along with the challenges and excitement thereof. Thanks to the post I was handling at North India’s first “AgileNCR” seminar (chief of Coordination Committee), it gave me a golden opportunity to interact with our guest of honor - Pete Deemer, ex-Yahoo VP, one of the few Certified Scrum Trainers and listen to his experiences during his sessions on Agile. I was really getting excited about the prospective of being an Agile Coach, when I realized it was possible within my current organization.
But right then I came across a very interesting blog post that put the question flat on my face – “Do we really need an Agile Coach?” It led me to ponder over the question. I tried to dig deeper.
Here I present a conglomeration of what I learned through various sites, posts and interacting with people like Guido and Pete Deemer. My personal experience with Agile Coaching is however limited to the above sources of information and I am yet looking forward to get down and get my hands dirty with it.
The discussion in the article has been arranged into the following heads:
- What's an Agile Coach after all? What specific capabilities are he expected to posses?
- How is he different from traditional project management?
- Do we really need an Agile Coach?
So what's an Agile Coach?
As the name would suggest, An Agile Coach is someone who “coaches” a team to work with Agile Development Methodologies. Note however that there is a subtle yet important difference between “coaching” and “training” – A trainer visits you for a short period, walk you through the process of Agile and moves on. An Agile Coach, on the other hand, is expected to stay with the team longer, let them adapt agile, and move on only when the team is comfortable enough to carry it forward on its own.
(In one of Steve's blogs, he discusses an interesting differentiation between Agile with a capital “A” and agile with a small “a”. In this blog however, I always intend to refer to “Agile Development Methodology” irrespective of which case I use to write “Agile”).
What specific capabilities are expected out of an Agile Coach?
According to Mishkin Berteig, an agile coach or mentor should have some really specific experience and capabilities. These are:
Experience:
- Working in strictly timeboxed iterations with adaptive planning using some sort of prioritized work list
- Working in a "test-driven" manner (e.g. writing a document for a client where the client specifies acceptance criteria)
- Participating in frequent status meetings where the team members report to each other, commit to work and identify barriers
- Building and maintaining big visible charts to show progress and status (e.g. the standard thermometer chart to show progress towards a numerical goal)
- Fashioning appropriate tracking and performance metrics that encourage team work rather than individual competition
- Helping other people to adopt and adapt all these practices
Capabilities:
- Promoting collaboration in challenging circumstances
- Searching for truth/a solution relentlessly
- Honesty and trustworthiness
- A learning attitude (proactive and learning from mistakes)
- Humility and assertiveness
- Guiding people without controlling them
- Detachment (ability to step out of a situation)
- An attitude of service without expecting recompense
- Understanding of transformative learning
- Conflict resolution as learning (not negotiation)
- Encouraging creativity
- A sense of humor and the ability to create positive energy. Very important for teams going through sometimes difficult change - as suggested by Pete Deemer as a feedback to this blog.
Not Required:
- Technical experience related to the work of the team.
- Domain experience related to the goal of the work - the Agile Coach should not be a direct stakeholder in the results of the work. However, technical experience and domain experience can sometimes help.
How is he different from traditional project management?
As per KaneMar, the attributes that are appropriate for an Agile coach are quite different than those for traditional project management. For example, rather than being able to track individuals and tasks, the Agile coach needs to know how to motivate the team into forming a self organizing group. He suggests:
What previously worked in an environment modeled on Taylorism, is no longer appropriate in an environment that is continually changing. Agile projects require different skills and these should be recognized and rewarded differently. Specifically, a Taylorist view of the world rewards greater specialization of skills. This can be clearly seen with methodologies such as RUP which categorize people into specific roles such as Analysts, Developers, Architects etc.
In contrast an Agile enviornment favours individuals who work together as a team. It favours group decision making and, by implication, those individuals who have the ability to facilitate and abide by the group decision. Agile projects are at a disadvantage with someone who does not directly contribute to the overall success of the project in some way.In an Agile model, the project manager that only wants to update the project plan and report to manager senior management is overhead for the team. Similarly, the architect that never wants to mentor staff but only wants to draw UML diagrams and dictate a solution to the team is detrimental to overall progress.
Do We Really Need An Agile Coach?
All said and done, teams who really practice Agile methodologies, know that its really simple and natural to follow that route to software development. Once the initial resistance has been overcome, it is quick to get into the DNA of a software developer. They sometimes ask – Big Deal? Isn’t that the most natural and simple way to go? Why on earth would something so simple need to be coached?
I came across one such blog by Paul Tyma who compared an Agile Coach to an Agile Secret Police! What followed was a very interesting chain of replies …
He criticizes the whole concept of Agile Coach saying:
I especially don't get this new craze of a job of "Agile Coach". I mean, everything I've read about Agile and XP seems dead simple. I'm still confused why I need a "coach" for Agile. I'd WAY rather have a coach for Java Generics, type theory, or God-help me, C++ templates. That stuff is definitely harder. Comparatively, agile seems a no-brainer.
He further adds...
The only thing I can come up with is that an Agile Coach is not really a "Coach" so much as a hall monitor or a secret police officer. As in - Agile is not fun (or maybe even inefficient for some people/circumstances) and people keep trying to stop doing the dumbest parts. Then, you need a "coach" to come in, serve kool-aid, and yell at them to start doing it again. Now mind you, the coach doesn't exactly yell at you - he more like "coaches" you like you're missing the point. He comes in like:
"Oh no no no.. you're doing pair programming all wrong!!! You're supposed to have TWO people for pair programming!!"
"Really!!?? OMGosh. I was wondering what the hell fruit had to do with all this."
"Yeah!! Thats why they call it PAIR programming!!!"
"Ha. like pants!"
"Yeah! like pants!"
"OH! But, um, does my stuffed monkey count?"
"Hrm. um. Good question. Lemme go email Kent Beck".
To which a few practicing Agile Coaches replied:
Mishkin Berteig says:
Agile is no doubt very simple. So why do I bother being a coach? Because despite it being simple, in many organizations, peoples habits and the corporate culture constantly impede the adoption of agile practices and culture. One of the most difficult aspects of agile is that it front-loads the learning and crisis in a project (or it should). Because an agile project should be delivering working, potentially shippable software at the end of the first iteration (usually <20 working days after the start of the project), all the crisis that normally shows up at the end of a project instead shows up at the start.
Deb says:
As a coach, I help people spot counter-productive practices and think about how to return to common sense. In a place where these simple things have not been forgotten, Agile rolls out more naturally, and a coach isn't needed.
In addition, like William, one thing I do is help the organization get out of the way so these effective developers can continue to work well! Agile doesn't operate in a vacuum, but usually in concert with a broader organization. Sometimes it helps to have an outsider to work with management while the team figures out how they want and need to work.
To which, Stacia agrees:
Hi Paul - I am also a coach. Agile is completely counter-intuitive to the way teams (and organizations) have behaved for decades. Sure, on a slide it's a straight-forward, common sense approach, but agile = organizational change, and that's no easy task. As a coach, I am there to give advice and relate experiences to help a team along the agile adoption path. Often this means discussing agile impact areas with management, which is sometimes better received from an objective third party.
Having gone through all this, I personally feel that an Agile Coach is like a fire extinguisher – As long as teams are mature and capable of putting off fires themselves, he silently observes, but the moment it gets out of hand (and Agile practices start getting neglected causing undesirable results on productivity and motivation), he is pressed into service.
As Matt Stephens observes:
“As XP increases in popularity and hits the mainstream, more and more teams will attempt XP, probably without a clear understanding of what is really involved. They will most likely be drawn in by XP's ‘low discipline’ practices (such as no big up-front design and minimal documentation), but without applying the high discipline practices that act as an essential safety net (such as unit testing, pair programming, collective ownership and constant refactoring).”
Having said it all, I leave myself and everyone who’s reading this with an Open question: Do we really need an Agile Coach? What do you say?
Archives
Training
- Workshop Agile Management
Custom made, in-company
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)
The first question to come to mind is: “Is Agile Coaching a new phenomenon?” I think not, developers have had ‘policemen’ for decades. Most companies have standards and procedures that tell you what and when to do. The Agile Coach adds to the existing rules by telling you ‘how’ to do it. Usually the Coach is hired by management because they have no faith in their own people in adopting Agile. Which I find strange because my guess is that the Agile Coaches were never coached themselves (they learned it through experience, conferences and books). In my view an Agile Coach should kick-start the agile adoption by coaching a few agile champions and then let go asap. Agile coaching sounds great, but in practice these people are process guiders, perhaps a better term would be Agile Adoption Advisor or Agile Evangelist?
Machiel, most organizations that offer agile coaching and independent coaches have the same attitude: help get things rolling, make sure that the teams can maintain the good habits, and then get out of the way.
[...] read more [...]
The term “Agile Coach” gets thrown around alot nowadays – often time with different meanings. In my opinion a coach is a guide, a mentor and an educator. But a coach should be more than that. I wrote about the need for agile coaching on my own blog a while back (http://www.bigvisible.com/gmorein/you-need-coaching/). I think the best Agile Coaches are also expeditors and risk reducers. They are there to help make the project a success by actively helping teams, projects and programs overcome the challenges of adopting a brand new process in a culture whose often gut-reaction is to rebel and revolt.