First, Reflect

You’ll want to consider WHY you’re looking for a coach. What challenges are you facing? What sorts of skills are you expecting them to bring? If you’re just starting up, then finding a coach that has experience “jump starting” agile teams will be your initial goal. If you’ve been agile for a while and looking for a “tune up” and assessment, then that might take you in a slightly different direction. Most coaches can handle both sides of that spectrum, but it’s useful to be clear on where you are on the adoption curve.

Realize that there’s a special relationship established between the agile coach and the organization they’re coaching. First of all, you need to be prepared to establish a partnership with your coach. Be ready to share your “dirty laundry” and your personal challenges. Be ready to trust the coaches you select; not only their experience, but their character and integrity.

Be open to learning from them, but be also open to challenging them to “raise the bar” in your agile adoption efforts.

And important part of any coaching relationship is measurement. How will you measure the results they provide? A typical measurement scenario is to focus on the teams and their productivity—measuring before, during and after coaching. But it’s not as simple as that. Agile measures are quite different than traditional measures, so you’ll want to do some research. You’ll also want to include your team and measure their personal reactions to the coaches.

Finally, do some initial research into agile coaching firms and individuals. Leverage your network and LinkedIn to survey the landscape. Word of mouth and personal recommendations are a powerful place to begin your search.

Work Experience

It’s normal for agile coaches to either focus on the organizational / team coaching (non-technical) areas or on technical coaching areas. In the latter, they usually focus on tooling and technical practices, for example Continuous Integration or Deployment (CI/CD), Test-Driven Development (TDD), and Refactoring & Patterns. For these coaches you’re looking for work experience that often aligns with your technology stack and domain dynamics. Often architects or very senior developers transition into this style of coaching. You’ll also want to see some public speaking and teaching in their backgrounds to ensure they can effectively teach their skills in pairs and small groups. Quite often the interview or selection of these coaches is more of an audition—where the come in and pair with team members in your organization. You’ll be assessing technical coaching chops by “doing” rather than “telling”.

For organizational coaches, beyond the direct agile coaching experience, you also want to consider the work experience behind the coach. What technical background and roles have they held? What sort of diversity in those roles? And have they held leadership roles in organizations.

I’ve found the best coaches to have a breadth and a depth to their work experience that rounds them out. For example, having held architecture, analysis & design, development, and testing roles in a variety of software organizations can be a distinct advantage for these coaches. Another advantage is having grown in their careers to hold senior leadership (Director, VP, and/or C-level) roles.

In general, knowledge of software development, testing, project management, and team leadership is incredibly helpful for coaches. So look for the breadth, but also the depth.

Coaching Experience

Now let’s get the elephant on the table. There are simply too many agile coaches around today! It seems like every agilist who has a modicum of experience at a team level is hanging out their coaching shingle. I feel like they’re misleading the community and potential clients. Sure, they might have a successful experience or two, but in limited contexts. Agile is simple to grasp, but hard to execute contextually. Only with many years of broad, deep, and varied experience do you get a coach that will have the skills and instincts to truly guide you.

Is there a magic number of years of experience? Probably not. But I personally look for coaches with around 10+ years of experience. I’m looking for in-the-trenches experience, for example they’ve been an internal coach as part of an agile transformation, as well as external consultative coaching experience.  They’ve worked with small and large organization, while having encountered entrenched Waterfall and entrepreneurial and open minded start-ups. The point being, they’ve been “around the block”.

Don’t necessarily get stuck on coaches having a direct “domain match” to your existing business and product domain. For example, I recently was approached to coach a BI and Analytics team and the client was looking for direct BI experience. From my perspective, I’m not sure that it matters so much, particularly if you’re a deeply experienced coach. In fact, domain awareness can sometimes get in the way of your effectiveness.

The Methods

Whether you know it or not, there isn’t a succinct agile methodology. Rather there is a ‘family’ of methods that attempt to support and adhere to the Agile Manifesto and its corresponding principles. Some of the more popular method and framework areas include:

• Methods:  Scrum, Extreme Programming, Kanban, Lean Software, AUP, DSDM, and Crystal. The more widely used are Scrum, XP, and Kanban.
• Tactics:  Continuous Integration & Continuous Deployment, Test Driven Development (TDD), Pairing, User Stories, Release Planning.
• Frameworks for Scaling:  SAFe, DAD, Scrum of Scrums, PMO, Agile COE, Agile CoP, etc.
• Bodies of Knowledge (BOK’s):  PMI-PMBOK, IIBA-BOK, Pragmatic Marketing, PDMA, Testing-BOK, etc.
• Soft Skills:  Leadership Coaching, Facilitation, Emotional Intelligence, 5 Dysfunctions, Open Space, MBTI or other personality type, etc.
• Tooling :  Tools become particularly important in at-scale and distributed agile contexts. If tools are a focus, clearly look for matching experience.

The broader the experience your coach brings, real experience mind you, across these areas the more flexible and sound they’re approaches will be as they tailor things to your context. I guess what I’m saying is don’t get a coach who has a “one size fits all” approach to each of their agile engagements.  Varied experience and a context-based approach will always be more valuable to you as you evolve your agile transformation efforts.

Certifications

Again at the risk of sounding self-serving, I think the CSC (Certified Scrum Coach) designation is a differentiator for coaches. In particular, it helps assure that the coach has moved beyond singular team coaching and towards Enterprise-level or organizational transformation coaching at scale. So you gain some assurances that their experience is broad and deep and contextual.

Beyond that, the ‘bar’ for the CSC is arguably quite high, with roughly 75% of applicants not being accepted. Not only is your knowledge and skill evaluated, but candidates are interviewed by CSC peers in a rather lengthy and rigorous process. As of this writing, there were approximately 200,000 CSM’s in the Scrum Alliance, but only ~ 60 CSC’s in the world, ~25 of which are in North America.

Now I think certification has to compliment real world chops, so don’t blindly hire CSC’s. But the credential (s) a coach brings to the table certainly matters and should be a part of your decision-making process.

Models – Embedded vs. Others

There seems to be two overriding models in the coaching community. Some coaches want to embed with your teams full-time. The contract is usually for a set period of time and the coaching is by and large continuous. Usually these engagements are in larger organizations so that the coaches can influence more than one team at a time. They typically get involved in organizational transformation as well.

The other model, and the one that I subscribe to, is a more part-time coaching model. Usually this model is more tightly coupled to your Sprint tempo, with the coaches engaging at the endpoints of each Sprint. They help close the previous Sprint and then plan for the next. Sometimes they’ll provide remote coaching between the endpoints, but it’s essentially an iterative model that parallels your own team(s) Sprint and Release tempos.

The key differences in the approaches are cost and autonomy, with the latter approach typically being less costly and promoting the teams to more quickly stand on their own. However, the former approach does align with most consulting contract experience and it is a simpler business model to orchestrate.

My experience is that the latter model places pressure on the teams to become self-directed, self-reliant, and higher performance more quickly. But both models can be effective.

Trainer vs. Coach

I’ll use the CST (Certified Scrum Trainer) vs. CSC (Certified Scrum Coach) comparison here to make the point. There are quite a few CST’s who also do a bit of coaching. The challenge is the ratio of coaching vs. training. If you teach classes too often, you lose your edge when it comes to “in the trenches” coaching experience and ability. Essentially, you’re too academic and you’ve lost touch with real world challenges. There are quite a few trainers who do a majority of training and high-level consulting, and very little coaching. In my opinion, they should largely decline coaching assignments as they’ve lost their relevancy.

At the same time, every good coach must have the ability to do training classes as part of their toolkit. The key is to looking for coaches first, who are also knowledgeable and experienced trainers. This combination turns out to be the most powerful.

Prescription Balance

There is a genre of agile coach that doesn’t tell teams how to do things…under any circumstances. They are intentionally non-prescriptive. The thinking generally goes that in order for a self-directed team to form and gel, it’s inappropriate to tell them what to do. They have to discover the path on their own, with the coach being their guide. This is honorable and true for a more experienced agile team, but what about providing guidance for new or inexperienced teams?

It would be like throwing a group of 8-10 years olds without baseball experience on a field, giving them the “rule book”, and the tools (bats, balls, bases, etc.) and saying—go play baseball. They would be spinning their wheels mightily for quite a while and they might never figure out the entire nuance of the game.

It turns out that coaches need to be balanced, but also comfortable in giving team’s firm direction when it’s necessary and important. Many are uncomfortable with that, and you’ll want to stay away from those IF you’re just beginning your transformation / adoption.

I believe that constraints, rules, and direction are actually an important part of creating the landscape for agile teams and organizations to mature quickly. It’s getting the right level of experience to understand when to tell and when to allow the direction to emerge that is developed across years of coaching experience.

But should you also ensure that your potential coaches aren’t “too prescriptive”? Of course you should because that will undermine your agile path as well.

Wrapping Up

This is a two-part article with advice towards selecting your next agile coach. As with anything in life, you need to leverage your own experience, context, and common sense in this process. I would also like to mention your “gut”. I’ve found that my gut gives me quite a lot of information when I’m looking for specific individuals on my teams. I’d encourage you to use yours when selecting a coach.

When your interviewing your coaches, please strive to create conversations instead of simply Q&A interviewing. Not that long ago, I went through a coaching interview. It was a panel of 4 interviewers and for 90 minutes they peppered me with questions. Only at the very end, did I have some time for my own questions and they were cut off by the lack of time.

This isn’t a good interviewing strategy in general and certainly not for an experienced coach. I’d strongly encourage for you to ask situational, open-ended questions in an effort to share stories and get to learn about each other. In other words, simply have a conversation. I think you’ll get more out it.

Stay agile my friends,

Bob.