For the most part, attendees at last month's Agile2013 Nashville conference downplayed their title. Programmers, managers, DevOps and testers instead described themselves as "agilists" there to share the experience.
However, there was one group that stuck out, one group that didn't exist 10 years ago: The agile coaches. The role is new, and hard to define.
One attendee describes himself as someone who "used to be a programmer" but is now a coach. I ask what he's been doing, in an effort to define agile coach by example. His company won a contract to convert a large company to scrum and was putting employees through three days of the Certified ScrumMaster course - but he wasn't a trainer.
More from Agile2013: How to Move Beyond Project Estimates and Provide Better Value
The Agile Conference has a coaches' clinic where you can get 15 minutes of "free coaching." But what exactly is that? (Photo Credit: Matt Heusser/ CAST)
"What do you do?" I ask.
"Whatever it takes," he answers. "Programming, if I need to."
That's right. Pressured to describe his role, his one example was the thing he claimed he wasn't doing lately.
Where Does an Agile Coach Come From?
The earliest mention of the "coach" role in agile software development comes from extreme programming, codified in Kent Beck's Extreme Programming Explained: Embrace Change. For Beck, the coach was equal parts traditional manager and 'tracker.'
Beck positions the coach as someone who might otherwise be a lead programmer or system architect. While those terms "conjure up visions of isolated geniuses making the important decisions on the project," he continues, "the coach is just the opposite. The measure of a coach is how few technical decisions he or she makes. The job is to get everybody else making good decisions."
Case Study: Formula One Racing Team Speeds to Agile DevelopmentMore: How the FBI Proves Agile Works for Government Agencies
The responsibility Beck gives the coach probably mimics what the attendee I spoke to actually does on his project - partnering with developers (especially junior ones) to figure out development tasks and helping programmers develop technical skills such as unit testing and refactoring, all while serving as a translator to explain the process to upper-level management.
Over the past few years, the agile movement has moved its focus to self-directed work teams, and the coach role has shifted a bit to match. At the conference, when I asked about the role, most responses were similar to International Coach Federation (ICF) guidance: "With coaching, the assumption is that individuals or teams are capable of generating their own solutions, with the coach supplying supportive, discovery-based approaches and frameworks."
Even the original extreme programming book supports that idea. "If you had a team that was technically self-sufficient, but needed help with their process, you could coach without being a techno-whiz," Beck writes. "You would still have to convince the propeller-heads that they should listen to you. But once the skills are there, my job is mostly reminding the team of the way they said they wanted to act in various situations."
This defines at least two different roles for the coach: technical mentor and change agent.
Coaching Works Better Beyond Agile's Early Adopters
I spend a fair amount of Agile2013 looking to answer the question, "What is an agile coach, anyway?"
One evening, as I sneak into an empty room to make a phone call, I find this piece of paper:
The Agile Coaching Competency Framework. (Used with permission.)
At this point, I'm skeptical. Instead of a single, undefined thing, we now have a big bucket of things that look impressive on the surface. But is there depth?
The author of the framework are Lyssa Adkins and Michael Spayd. Both are principles at the Agile Coaching Institute, while Adkins is the author of Coaching Agile Teams.
"When I wrote Coaching Agile Teams," Adkins says, "it wasn't that I had cracked the code; more like I had one idea that was useful. What I started in that book had matured into the competency framework."
At the beginning of the agile movement, Spayd explains, the people picking up extreme programing and scrum were early adopters. At the beginning, teaching and mentoring the left-hand side of Everett Rogers' technology adoption lifecycle model works just fine. Get to the middle of the graph, the early and late majority, and resistance occurs, he says.
"Teaching and mentoring doesn't help with resistance," Spayd says. "You need a different set of skills. Professional coaching and facilitating allow people to overcome their own resistance. All of these things are 'agile coaching' &mash; they fit in the framework."
Survey: CIOs Say Mentoring Works, Classes Don't
The ICF calls professional coaching the ability to partner with someone to inspire his or her potential, regardless of the domain or industry. While a teacher or mentor might insist on a particular approach, a professional coach "doesn't have a dog in the fight," as Spayd puts it. "Instead of being a content expert, you walk them through a process to see what isn't working and what to change."
Rather than look for one definition of coach, this embraces the idea that coaches can focus on different aspects of the agile coaching framework. Some coaches focus entirely on technical mastery. Others can't write code at all. Adkins and Spayd agree that a "lean/agile practitioner" is core to the skill set for most software teams - but they also agree that agile development is quickly moving out of technology into the business realm, as "agile puts the customer in the driver's seat."
Adkins points to the bottom third of the framework - technical, business and transformation Mastery - and says "it's really hard to be extremely good at two elements" and "impossible" to be an expert at all three. "We tell people to pick one," she says.
That allows two things to happen: First, instead of looking for a "coach" in general, an organization can instead figure out what kind of coaching it needs - teaching, mentoring, conflict resolution and so on - then find a coach who can self-assess to a skill set to meet that need.
Second, it admits that not every coach will have every skill, which encourages more paired-coaching assignments. The Agile Adoptions that I have seen "stick" tend to correlate to pairs of coaches - one technical, on more focused on organizational change.
Related: Using Pair Programming Practices in Code Inspections
Skepticism abated, I move from theory to practice and look for a story of agile coaching in action.
Agile Coaching in Action: Don't Always Do What You're Told
According to Meike Mertsch, knowing what needs to be done, regardless of the official request, is part of the essence of agile coaching.
Meike Mertsch is a consultant and coach from Germany. When I asked her for a coaching story, she talks about a team that asked her to teach estimation. In a blog post on the subject, Mertsch recalls the team calling a meeting to discuss and estimate 80 different 'stories.' Most weren't actionable, though; instead of stories, the cards were full of values such as "more intuitive" or "user friendly."
While the official "ask," as it's called, was learning estimation, what the team actually needed to do was a whole lot of figuring out what to build.
Early into the meeting, Mertsch realizes this difference, which she describes as "a knot in the stomach." Instead of continuing to teach on estimates, Mertsch suggests the product owners come up with action items for the next spring only &mash; that is, a handful of directly actionable ideas.
The group dispersed and reassembled later that day, working through a small number of reasonably well-defined tasks. Mertsch didn't teach about estimation that day, as other coaching was needed.
Commentary: Bringing Common Sense to Agile Principles
Going back to the model, Mertsch needs to know which skills she needed at a point in time, despite the official "ask", and needs to be able to quickly shift from teacher mode to facilitator and back, according to various kinds of expertise. That's the top and bottom of the model. As it's not possible to be an expert in every area, she also needs enough self-awareness to know when to bring in help.
Pinning agile coaching down to a precise definition might not be possible, but at least this gives us the tools to talk about it.
Agile Coaching Philosophy: Apply What's Needed
I may have been too hard on the old friend I introduced at the beginning of the story. His expertise is coding, so when he went to a client with its own private programming language, he contributed where it made sense: Helping build a harness for unit tests, then pairing to help the programmers write testable code.
He wasn't wrong; he was subconsciously using the secret sauce of a good coach, which is to know what's needed and how to apply it. He just didn't know how to put into words what he was doing. Mertsch's story, where the initial ask was for planning but wasn't what the client needed, illustrates that well.
Analysis: Who Says Agile Development Can't Be Faster?
So what's next for agile coaching? Spayd points to the self-assessments he receives at the end of every course he's taught for the Agile Coaching Institute: "Every class comes back wanting information on transformation and transformation mastery. People want more skill in that area."
The ACI defines that as the ability to facilitate, catalyze and sometimes lead organizational change, This draws on change management, organizational culture, organizational development, systems thinking and other behavior sciences. To the extent that middle managers are responsible for growing employees, Adkins adds, they are all coaches.
So what does organizational transformation mean, exactly? Perhaps that's something to talk about next time.
Matthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.
Read more about agile in CIO's Agile Drilldown.