(Part 1/?) — a series of articles to help coaches increase their chances for successful engagements
“You can’t manufacture inspirado…it arises from a stillness, a quietude” — TenaciousD
My thoughts are an amalgamation of all the discussions with all the brilliant people I’ve been privileged to meet. The extent of my own “hard work” has been putting myself in situations where I get to be a sponge¹.
Part I: Honest Assessments
The agile consulting industry (it certainly has become that) continues to take reputation hits from rightfully frustrated clients’ left under-served by inexperienced & over-certified consultants. A perception that clicking one’s heels together three times and saying “I am an Agile Coach” is qualification enough, plagues this occupation. If I want to hire a Ruby Programmer, I can review the resume of a Ruby Programmer, and intuitively expect what that person brings to the table. Hiring an Agile Coach is not so straightforward. The role (as with as most agile practitioners) is largely misunderstood by staff-augmentation, recruitment, and human resources professionals. The unfamiliarity with this evolving role compounded with an obfuscation by amateurs² who inflict damage upon clients and leave abruptly, has made placing competence and skill within organizations who need help, a difficult and confusing challenge.
Proficiency, or lack thereof, in coaching is a concern in the Lean/Agile community. I assume interested readers are, at the very least, well-intentioned practitioners with some amount of demonstrable skill and success helping organizations deliver valuable software to their customers. I don’t claim to be the final arbiter of competence when it comes to agile coaches, but I do understand and recognize “best practices” well. I can confidently tell my own clients that I invest a tremendous amount of professional and personal time & money in the skill I have aggregated so far and will continue to accrue. With my clients I’ve helped create both delight through leveraged knowledge & experience, and continued improvement & failure through experimentation. Above all, I hope I have earned their respect, as well as that of my peers.
The specific skills, frameworks, tool proficiencies, certifications, and belief systems mandatory for a good agile coach is objective. There is a universe of content out there covering opinions on those topics. Readers should be self-aware enough to judge the state of their own capabilities and deficiencies. Ultimately it is about being cognizant of the importance in putting one’s whole self into the mindset of a coach who wants to help organizations deliver value while protecting the integrity of the agile consulting space, versus merely landing the next gig and cashing the checks.
My most sincere recommendation for those looking to create a coaching engagement built upon a foundation for success: fearlessly and honestly evaluate your own and your client’s compatibility for the challenge at hand.
The typical interview process one goes through when trying to secure a consulting or embedded Agile Coach role (yes, there are opportunities for FTE agile coaches) may not yield information sufficient to determine suitability for either consultant or client. Perhaps this is a systemic flaw with traditional corporate interviewing approaches entirely, regardless of role. Richard Sheridan, CEO of the much heralded Menlo Innovations, in his book “Joy Inc. How We Built a Workplace People Love”, writes of his epiphany on interviewing: “Your interview needs to match your culture” (or the one you want, for orgs looking to hire a consultant to help bring about a culture change). Much has been written about this topic.
In the few hours I have with a potential client, I ask questions — a lot of them. This isn’t some disingenuous gimmicky interview tip like, “When asked about a weakness, respond with, ‘I care too much.’” This is self-preservation advice.
I like to ask clarifying questions that …
- open clients up to identifying pain, successes, and where in the org they prioritize a need for help
- encourage descriptive words, positive or negative, about company culture
- provide insight into WHY and WHO sponsors the “agile transformation” — provoke clarity on specific motivations
- quantify the appetite for additional training for developers, testers, product managers, executives, HR, sales, et al
- list the outcomes expected from an “agile transformation” and coaching engagements; if possible collaboratively create a 30–60–90 day vision
- expose levels of maturity with concepts such as: agile frameworks (e.g. Scrum), testing tools and mindset, automation, DevOps tools and practices, levels-of & approaches-to collaboration
- clearly explain organizational processes: how product visions are ideated, how big visions become actionable, how code evolves beyond “requirements” into value in the hands of users, and how or from whom feedback is given
- explain how product/project decisions are made, which ones are approved, by whom, by what processes
- outline the tech stack: types of products they build, the platforms they run on, cloud vs on-prem, programming languages, IDE/source control/continuous-integration-continuous-deployment/testing/requirements management tools
I never want to finagle my way into a role by manipulating conversations. My goal is not commandeering the discussion; it’s about gaining as much clarity as I possibly can in the short amount of time I have to perform an evaluation, and for clients to perform theirs.
It would be futile to suggest precisely what terminology and style to use with a client, because every situation calls for different strengths and specific skills. However, when I interview a client, my clarifying questions are interspersed between organic conversation and the client’s own questions, to which I respond in ways that show synergy with their needs. Being hyper-aware of how client information I am just learning dovetails with my own values, principles, and skills, is a practiced technique which I continue to hone. I’d urge any consultant to embrace this mindset. Conjecture and pontification have their place, I suppose, but my next client wants to know how I can pragmatically get them out of a bind.
There are plenty of effective ways to determine whether or not a potential client is attractive for me. Now comes the hard part! Am I willing to be honest with myself about my own possible incongruence with the client’s expectations? This is not an easy thing to do. Being a consultant is not an easy thing to do when engagements are measured in months not years, with frequent periods of no billable work. Income instability creates pressure. Panicked urgency to get invoice payments rolling in can cause one to consider misrepresentation, even ever so slightly, just to secure an offer. Resist this temptation.
I’ve fulfilled many agile practitioner roles in a variety of industries and sizes of companies. Marketing via social media platforms and a network of recruiters and agencies, I get upwards of a hundred cold-call job opportunity emails each day. Many are for Agile Coach positions. Some call for specific skills I might not possess. Hypothetically, I may get a job description that asks for a hands-on experience with the CI/CD tool Jenkins. I can certainly evaluate an organization’s needs, tech stack, and make an informed recommendation for Jenkins (if that were the appropriate tool for the situation). However, as an individual contributor I could not architect a Jenkins-based automated CI/CD topography integrated with source control and testing harnesses to take a developer’s code, shelve or merge dependent on test results, through to production. There are other technically rigorous areas where I can be in the weeds, but in this hypothetical case I don’t have practical experience with that tool. In an interview situation, I might be able to abstract my answers about Jenkins for the purpose of sidetracking conversations and misrepresenting my skill, possibly resulting in getting hired. I refuse to do that. I know my limitations, and use them as motivation to grow, not dupe unsuspecting hiring managers. This may be overly idealistic, but I believe protecting the integrity of agile coaching will create more opportunities by creating more trust and proven value.
A problem in the agile coaching space is an overall lack of vision for the long game. As disingenuous and naive consultants overrepresent/overestimate their own ability, and continue to leave damage in their wake, the conceptual idea of the Agile Coach loses more credibility failed engagement by failed engagement. I’ve seen the reputation harm to both coaching and the overarching umbrella of organizational agility under which good practices, behaviors, values, and principles reside. I’ve heard more than enough gross mischaracterizations from scorned Dev Managers and PMO Directors, about what agility is and isn’t, to empathize with what they’ve been through. Anecdotal misuse is not a valid criticism of general Lean/Agile concepts, but as they say, “perception is reality.”
The Agile Coaching Institute has established an “Agile Coaching Competency Framework³” intended to help coaches self-evaluate against 8 core areas (“wedges” — see diagram) of competency. I like Alicia McClain’s, of Agile Coaching Exchange — SoCal, suggested approach to self-measurement: rate our strongest (#1) to weakest (#8) wedges, and for each rating, document a few bullets of the experiences in that wedge that account for the skill level. This framework is a useful tool for visualizing where we, as coaches, rate against the competency model, where we can improve, and where we can most effectively help potential clients. For this framework to be effective, rigorously honest introspection is required. Lyssa Adkins, who helped design the framework, has authored a solid overview here.
The best thing we, as agile coaches, can do for ourselves and our own livelihood, is to protect the role’s credibility across industry. Charlatans and snake-oil salesmen have no place. Honest coaches of different skill-levels and expertise can bring value to organizations using transparent and principled approaches. The organizations who do need help are as numerous as the specific areas where help is required. There’s room for all those with integrity, if we prioritize creating honest assessments of consultant -client compatibility.
Next up - Part II: No Cognitive Bias
Avoid subjective dogmatism in agile coaching engagements — there is a tendency for consultants with narrow skill sets or niche preferences to present their limited proficiencies & biases as the only way to solve organizational problems, giving rise to ineffective, cookie-cutter approaches.
¹ Woody Zuill, mob programming pioneer and creator of the #noestimates conversation, talks about creating and being ready for serendipity. He often quotes artist Robert Henri as it is analagous to software development: “The object isn’t to make art, it’s to be in that wonderful state in which art is inevitable”
² Mike Cohn, prominent Scrum trainer most notably associated with user stories and estimation & planning in an agile environment, wrote a blog on professionals & amateurs
³ Lyssa Adkins is a renowned Scrum trainer who has written what many consider the definitive text on agile coaching — Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition