Why is it so hard to find qualified agile coaches?

Questioning peopleI was hoping to come up with a pithy, short answer to this question but the only thing that I can come up with is “people.”  The not-so-pithy answer is that there is no sort of agreement around what it means to be a “qualified agile coach”, the people hiring coaches aren’t thinking things through in many cases, and the agile community suffers from a myriad of integrity challenges when it comes to professionalism. In this blog I work through the following ideas:

  1. Why is there a dearth of qualified agile coaches?
  2. Sports coaches as an example
  3. What should we expect from agile coaches?
  4. Our solution: Certified Disciplined Agile Coaches (CDACs)
  5. Parting thoughts

Why is There A Dearth of Qualified Agile Coaches?

Let’s answer this in two parts: Why is there a dearth of agile coaches and why are there so many unqualified coaches available?  The first question is very easy to answer.  The demand for agile coaches far outstrips the supply.  The adoption rate for agile has been growing steadily since 2001, hence the growing demand.  As you’ll see later in this blog, it takes years to grow good coaches.  As a result there is little hope for the supply to catch up with demand any time soon.

The second question, why are there so many unqualified coaches available, is easy but uncomfortable to answer.  In general we have systemic challenges in the IT industry and in many ways we’ve managed to exacerbate these problems within the agile community. Some of the challenges within the IT community include:

  • A person is just as likely to be a self taught programmer, and more likely in fact, than they are to have a computer science or engineering degree
  • Although we throw the term “software engineering” around a lot, there is no agreement around what it means or even if it’s an appropriate concept (the IEEE/ACM promotes one, but there are many others)
  • There is no sort of apprenticeship culture in this industry
  • Few people have a personal goal of mastery, and few organizations support the gaining of mastery amongst their staff
  • There is a shortage of talented people, so It is very easy to find and retain employment regardless of your level of talent, and the market for IT people is still growing
  • No country has a licensing body for software professionals that is commonly required by organizations, unlike other professions such as doctors, lawyers, engineers, architects, and many more
  • Many people in the IT community believe this normal for a professional, or if they do perceive a problem they are (rightfully) overwhelmed with the challenge of addressing it
  • Colleges and universities are endemically years behind the quickly changing IT industry (there are a handful of schools that work closely with industry, so it’s getting better)

Then we have the agile community, with its various certification training scams.  You can become a certified master after staying awake during a two-day workshop and passing an online test that almost nobody fails.  To put this into context, a Starbucks barista, the kid who pours your morning coffee, get’s three days of training before being let loose on customers.  Yet it somehow makes sense that someone with 50% less training becomes the lead of a software development team?  Really?  Another example: Someone can become a scaling program consultant after attending a four-day workshop, and worse yet are now “qualified” to teach a two-day workshop to others so as to impart their vast agile scaling knowledge upon them.  Amazingly, because of the demand by companies desperate to hire agile-skilled people, the demand for these “designations” is incredible (shameful would be a more appropriate word).

In practice many agile designations are little more than “participation ribbons”, yet most organizations take them seriously often either because they don’t realize how trivial they are to earn or because they’ve given up expecting any better from agilists.  Is it any surprise that it’s hard to find qualified coaches when we’ve watered things down so much?

Sports Coaches as an Example

CoachCoaching is very common in sports and with the exception of “pick up” games few sports teams are without a coach.  In fact, serious sports teams tend to have several coaches, typically lead by a head coach. In professional sports coaches are paid significant salaries, sometimes millions of dollars a year, as coaching is perceived to be a critical success factor.  It makes sense to look at sports coaching works to see how agile coaching might work.

Most sports coaches are former players.  They’ve typically played for years, and sometimes decades, having been coached themselves all along the way.  They’ll often start off as children, in Canada it’s common for kids to start learning to skate and play hockey at the age of two, being coached and drilled in basic skills and knowledge for years.  They also gain practical experience playing games.  Most kids drop out eventually, although many still play their sport (be it hockey, football, cricket, baseball, …) well into middle age.  And some decide to stay in the sport, but make the shift from being a player into being a coach.

The transition to becoming a sports coach generally isn’t easy.  There are three common strategies for this:

  1. Formal training.  One path is to go to university, get a teaching degree, and become a gym teacher at a middle school or high school and begin coaching children.  These coaches tend to coach a wide range of sports, although in some cases you’ll often see a coach specialize on a single sport, such as high school football or hockey, because that’s what their passion was a child (and often because they hope to move up the ranks at eventually, see point #3 below).
  2. Informal apprenticing.  Another path is to apprentice, asking your existing coach to allow you opportunities to coach others under their guidance.  When I trained in karate this was very common, with senior students helping to teach less senior students.  My daughter is currently learning to skate and they follow a similar pattern with senior skating coaches (adults) being helped by assistants (typically teenagers who have been skating for many years) to coach and teach the younger children.  Helping to teach or coach others is recognized as an important part of your own learning process.
  3. Formal apprenticing.  Because of the money involved professional sports teams tend to take a more formal approach to coaching.  They will often expect coaches either come up through the coaching ranks – start as a high school coach, then become a college-level coach, then finally a professional coach – or to come up through the professional sports ranks – when your star players are past their peak they sometimes move into coaching roles.  Each time you move up to a new level of coaching, say from high school football to college football, you often start as an assistant coach to first prove yourself.  The head coach at each level recognizes that it’s their responsibility to grow more coaches, so they impart their skills and knowledge on to the junior coaches.

So, what are some important observations we can make out of all of this?  First, sports coaches have deep skills and experience at the sports that they are coaching.  Second, we expect this of them.  Would you pay to have your child to be given skating lessons by a “Certified Skating Master” who had two days of training in the “skating mindset” and how to facilitate a handful of skating meetings?  Of course you wouldn’t.  Instead you’d want someone who had been skating for years, and better yet may have even been a competitor at some point in the past.  Third, it takes years of apprenticing or training to become a good sports coach, not just several days in a certification workshop.

What Should We Expect From Agile Coaches?

Here is what we’ve found to be the critical success factors for agile coaches:

  1. They should have years of agile experience, not days of training.  If someone doesn’t have years of experience in something, and more importantly years of varied experience, then why they heck would you hire them as a coach?
  2. They should have coaching skills and experience.  Being experienced in agile isn’t enough.  Apprenticing under another good agile coach is a great way to get coaching skill as is getting training in agile coaching (the Agile Coaching Institute is a start for this although the program at International Coaching Federation (ICF) is far more thorough).  The need for experience is a bit of a catch-22 of course – you need to already be an agile coach to be qualified to be an agile coach.  But, if someone has no previous coaching experience then at best I’d put them into a junior coaching role under the guidance of an experienced coach.  This provides them with the opportunity to gain the requisite experience and to prove themselves in practice.
  3. They should have robust agile skills and knowledge.  Years of agile experience is a good start, but better yet is a range of experience at all aspects of the lifecycle in which they are coaching.  It’s reasonable to expect a delivery team coach to understand all aspects of agile solution delivery so that they can coach the entire team in the skills they need to succeed.  Furthermore, it’s reasonable to expect an Agile IT coach to have experience in the full agile IT lifecycle, including areas such as Enterprise Architecture, Data Management, Portfolio Management, and many others.
  4. They should have experience in a similar context.  Ideally they should have skills in a similar context to what you currently face – someone who only has small team coaching experience will struggle to coach a large programme, someone who only has only coached in startup companies will struggle in a large financial institution, someone who has only coached co-located teams will struggle with globally distributed teams.  Context counts.

Criteria for Effective Agile Coaches
All four of these factors are equally important.  Any “coach” who is deficient in one or more of these areas still has some work to do.  Nobody is perfect of course, given the rates that agile coaches demand it’s reasonable to expect these people to be qualified.

Our Solution: Certified Disciplined Agile Coaches (CDACs)

A fair question to ask is how do we deal with this in the Disciplined Agile (DA) space. We believe that it’s critical to your success to have qualified coaches so we’ve built a principled certification program based on the martial arts philosophy of Shu-Ha-Ri.  Certifications must be earned and that takes time.  The following diagram summarizes our strategy for how practitioners must earn DA certifications.

Agile Practitioner CertificationsTo become a Certified Disciplined Agile Coach (CDAC) you need to have at least five years of experience in agile (which is verified by the Disciplined Agile Consortium (DAC)), plus evidence that you’ve already been sharing your skills and knowledge (we call this give back), plus you must be a Certified Disciplined Agile Practitioner (CDAP).  To become a CDAP you must have at least two years of proven agile experience (validated by DAC), have passed a comprehensive test of your agile knowledge, and already be a Certified Disciplined Agile Practitioner (CDA).  To be a CDA you must have passed a comprehensive test of your knowledge and skills.  So, this process of certification ensures that CDACs have comprehensive skills and knowledge in agile techniques, at least five years experiences in agile, and at least initial experience in coaching/teaching (the giveback component). Note: Not shown in the diagram above is Certified Disciplined Agile Instructor (CDAI), which you must be at least a CDAP and have proven ability to teach DA.

Parting Thoughts

It isn’t easy to find qualified agile coaches, but then again it isn’t impossible either. Our hope is that this blog has provided you with some insight into what you should be looking for in a good agile coach.  Anyone can put a shingle up and say that they’re an “agile coach”, but anyone who wants to say that they are a Certified Disciplined Agile Coach (CDAC) needs to have worked through a rigorous process to earn that qualification.  CDACs have proven knowledge, experience, and give back.  Why settle for less?

Related Reading

Have any Question or Comment?

15 comments on “Why is it so hard to find qualified agile coaches?

Adrian Lander

Hi Scott, I totally agree with you on almost all points. Great post! I have one caveat. While I like the agile coaching competency model of the Agile Coaching Institute as an overview of skill areas that are needed, I do not think their 4 or 5 day program is sufficient in any way. I took their program in 2011 or so. It was an eye opener and it influenced me. That’s positive. Later I took coaching programs with several organisations, Marshall Goldsmith, University level Executive education, WABC (World Association of Business Coaches), IC-Agile and ICF (International Coaching Federation). So I can compare. I helped me to re-evaluate the ACI program. While I came from a background in coaching individuals, teams, senior management and organisations since 1995, the one program that clearly stood out was from ICF. It was the only rigorous program, that takes more than 6 months in practice, includes proof of active coaching, includes examination of tapes of real coaching sessions, includes a live demonstration of skills test, study and reflection by essay of several key coaching books, mentoring by a coach with vast proven experience and solid certification and a 3 hour 180 hard questions on ethics and coaching principles, small groups so that during the various modules the proven Ri coach can work with the Shu candidate coach. And people actually fail. The ACI has none of that. The actual coaching content is extremely thin compared to ICF. It is not more than a coaching awareness session.


Adrian, thanks for the input. I will update the article to reflect this.


“so we’ve built a…”


Thats the problem again. You pointed out earlier that we need a licensing body for software professionals. Yes, true and need to ALL agree what coach means.

Basically, we need everyone to put their ideas together and jointly form a coaching certification that everyone can agree to. This means that if I say I am a coach, I am not a DAD Coach or a SAFe Coach or an Agile alliance coach or a Scrum.org coach and so on, but rather a coach in everyone’s eyes.

Maybe its time for all the various fractures to unite on a standard that they all teach. 🙂


So you’d like to see everyone get together and develop a Unified Process?

Thomas Owens

I disagree with a few points in the article.

“Although we throw the term “software engineering” around a lot, there is no agreement around what it means or even if it’s an appropriate concept”

I think the scope of software engineering is pretty well defined at this point. In the United States, ABET is accrediting software engineering programs. The IEEE has published Version 3 of the Guide to the Software Engineering Body of Knowledge. The ACM and IEEE publishd “Software Engineering 2014 Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering” (a revision to the the 2004 version). Maybe people aren’t aware of or contributing to the various professional organizations, but there is ongoing work to keep refining and improving the scope of what is software engineering.

“No country has a licensing body for software professionals, unlike other professions such as doctors, lawyers, engineers, architects, and many more”

Canada has had licensed software engineers for quite a while now. More recently (in the past few years), the National Countil of Examiners for Engineering and Surveying (NCESS) in the US has offered a Software Engineering PE exam. I believe other countries also have a licensing process for software engineers. I do think that there are problems with the NCESS licensing process in the US. When I looked at it, there weren’t any FE exams that lined up with the content taught in undergraduate software engineering programs, making that first step extremely difficult. The requirements to work under a licensed engineer and a lack of employers who would need a licensed software engineer also make it difficult. But the licensing does exist.

“Colleges and universities are endemically years behind the quickly changing IT industry”

Some, or even many, may be, but I don’t think it’s fair to all college and universities, especially those with strong ties to industry.

Now, I do agree with several other points you make – the number of people who don’t have a degree in computer science, software engineering, computer engineering, information technology, or some other program but are either self-taught or have gone through a boot-camp style program, a lack of apprenticeship culture, a lack of interest in the IT community to identifying this problem and solving it, certification scams…

I do think that one point is generally missing, though. As a community, we recognize the importance of knowing certain things in the field. Individuals and companies recognize the importance of the skill of being able to elicit, analyze, document, and validate requirements. They recognize the importance of understanding systems and software architectures and designs. They recognize the importance of constructing and testing software and then maintaining the software (and tests). They recognize the importance of releasing and managing versions and dependencies. They recognize the importance of people to manage and lead the people doing all of the previous tasks.

What’s missing is a general recognition of the value of people who understand processes and methods. I also mean in the broader context, beyond agile. People who know about the Rational Unified Process. Who know about Scrum and Nexus. Who know about Disciplined Agile Delivery. Who know about Lean Software Development. Who know about the CMMI. Or applying Six Sigma to software projects. Or Kanban. Or PSP/TSP. Or ISO 9001 and its industry-specific derivatives. Or…well, I think you get the idea.

This is something beyond an “agile coach” or a Certified Disciplined Agile Coach. This is someone who not only has at least a basic understanding of all of the different things that go into a software project, from user need and requirements to maintenance and obsolesce, but a wide variety of different processes and methods for achieving those steps. Someone who can analyze the industry, the business, understand constraints (regulations, industry standards, various good practices) and help an organization choose and develop the best possible practices and processes.

I don’t think people with this type of general knowledge will be out seeking these various certifications because they are far too many. Instead, they will have a track record of working in various capacities on various projects and demonstrating knowledge in how individuals and teams work.


Thomas, thanks for the feedback. Here are some thoughts:
1. Regarding the definition of software engineering from the IEEE/ACM, so what? It hasn’t gained wide acceptance outside of that community. I’ll update the article to link to it, but unfortunately the effort around the SWEBoK never really gained traction outside of academia.
2. As far as licensing body goes, also, so what? The Canadian licensing body is virtually unknown by hiring organizations. Do you think that a single one of the banks have even heard of it? Or if so, care about it? If it’s not a common requirement for employment then the licensing body really isn’t relevant. I’ll update the article to reference them, but frankly neither of your examples are going anywhere.
3. Yes, a handful of universities have a reasonably practical curriculum. I’ll update.

Thomas Owens

This speaks to a broader concern that I have. Dismissing the work of the IEEE, ACM, and licensing bodies because they haven’t gained traction in industry yet doesn’t help to solve any of the problems.

This post mentions several problems: not everyone in software engineering comes from a related university program, there’s no widespread agreement on what software engineering is, there is a lack of a personal goal of mastery, there are no widely accepted or recognized licensing bodies, there are too many college and universities that are behind industry, and practitioners see this as normal.

I think the real question is why this work hasn’t gained traction in industry.

The ACM states a membership of around 100,000 people, with about half outside of the United States. The IEEE Computer Society says that they have more than 60,000 members. There’s probably significant overlap between these two organizations. According to Bureau of Labor Statistics data, this number is a small fraction of the potential membership pool in the US alone.

The work being done by the ACM and IEEE helps to mitigate nearly all of the problems you’ve identified early in the post. They are working to define the boundaries of software engineering. They have resources (digital libraries, magazines, journals, articles, blogs) to share knowledge for both industry practitioners and academics. Membership often includes or offers discounts to ebooks, videos, training courses and conferences.

Now, I’m not saying it solves all problems. I think there’s a lot of work to be done to gain acceptance for non-university educational programs, improving licensing (if it’s even necessary – I’m not personally convinced yet), and improving the state of the profession as a whole.

Instead, I think it’s important to focus on the following questions:

Why are so few practitioners members of professional organizations?

Why do so few individuals and organizations outside of academia recognize the work being done by these professional organizations? Perhaps it’s related to the first question of why so few practitioners are members of the professional organizations to begin with.

Why are so few people that I would consider thought leaders in software engineering involved in working with these organizations to develop and then promote training and educational programs, associations, codes of ethics, and reputable certification and license programs?

I think that if you were to see a dramatic rise in membership and active participation in professional organizations, you would begin to see the community begin to normalize around the core concepts and terms. Practitioners would begin to demand a certain baseline knowledge, and you’d see this reflected in educational programs at college, universities, and even bootcamps. If the access to knowledge grew, you would have more people taking advantage of using these resources to learn and grow, and as highly motivated individuals did it on their own, organizations would begin to demand it as these people moved into positions of leadership.

It’s definitely a very challenging program, and solutions are long term. But I think it starts here, by not dismissing the work done by highly motivated and highly dedicated people, but by promoting the things that can actually help solve the very problems identified in this post here.


Thomas, good points.

To put things in context, I’ve been a member of the ACM since the early 90s, have attended a few of their conferences over the years, and regularly read CACM. I have also subscribed to various IEEE publications over the years, particularly IEEE Software but others as well.

I believe that IEEE does in fact have very good recognition within the electrical engineering community although could very well be wrong about that. But, from the point of view of the IT community that is certainly not the case. In the IT space I see IEEE/ACM as insular in many ways. They tend to focus on the academic space, which is important, but outside of that not much so. For the most part ACM is virtually unknown amongst practitioners. For example, next time you bump into “Joe Programmer” ask him or her what CACM is. They likely won’t know. So if practitioners have never heard of them, then whatever good work they do will be ignored (which is what I believe we’re seeing).

Many of the publications of IEEE/ACM are written by academics for academics, so are difficult to consume. In my writings I have this crazy habit of referencing the work of others, nowhere near the level rightfully expected by academia, yet I’m often criticized for over referencing. Very different expectations. For example, in the current issue of CACM there’s a very interesting article (to me at least) about who owns the social web. It’s well written but academic. Joe Programmer, however, if he’s interested in the social web at all is more likely to want an article about programming to the Facebook API.

As far as membership in professional organizations, where’s the value for Joe Programmer? He can take a two-day workshop and become a Certified Scum Master, which is being asked for by many organizations. Or, here in Canada, he could work his butt off and become an ICP or ICTP via CIPS which is being asked for by almost no one.

As far as thought leaders working with these organizations, some do but not many. I’ve tried in the past and found it to be too difficult. I’ve had leading-edge papers rejected, or had ridiculous changes required of them, because the old farts reviewing them had zero focus on practical concerns. In one case one of the papers became the foundation of an award-winning book afterwards. I’ve attended and spoken at academic conferences, keynoted sometimes, only to discover how insular and self-reinforcing that world is. And slow moving. Yikes.

I’ve also worked on ISO standards committees and with the OMG in the past, similar but different kettles of fish. Also frustrating orgs to work with, and due to political reasons the efforts came to naught.

If the IEEE/ACM crowds wants someone like me to promote their work, I think that the first step is for them to be a little easier to work with. Frankly, I’ve gone out of my way to try to work with them and actively help researchers whenever I can. Now it’s their turn to focus on becoming more accessible to practitioners.

I think that they also need to do something to make their work more consumable by the average IT person. User groups around the world are usually desperate for interesting and practical presentations. Does IEEE/ACM groom their members to do things like this? Or at least motivate universities to stop punishing them for doing so? Why would an academic do all the work to present at a practitioner conference, or write for a practitioner publication, without getting “publication credit” for doing so? Seems to me that they’re far more motivated to do the work to publish in an obscure academic journal or conference proceedings instead.

Thomas Owens

Thank you for these thoughts.

I do appreciate the thoughtfulness throughout Disciplined Agile, including in the training and certification programs. Although it’s not for me right now, I do think it’s good that there are certifications out there created by the leading experts in a given subject and have a certain level of rigor behind them. I hope that more certification programs in software engineering learn from what you’re trying to do here. So many are out there where you pay some money and take an exam and get a piece of paper that opens up doors, yet there’s no real assurance of experience and knowledge behind that piece of paper.

I’m still wrestling with if certifications are actually good for the community or the profession, though.

I’m going to use myself as an example. Now, I know that I’m no where near the level that I would consider myself to be a coach. But I focused on more of a process/methods side of software engineering with a little bit of business, management, leadership, and communication sprinkled throughout. I spent about 5 years working in engineering process in a company that embraced Lean Software Development and came from a CMMI background while implementing ISO 9001. Now, I’m working in a Scrum environment and am being trained under a far more experienced agile person (close to your definition of coach) for a Scrum Master role. Both of these have been a secondary role to other software engineering duties, which I think is crucial – it’s easier to help build, define, and improve processes when you’re actually living the process. Along the way, I’ve learned about RUP, DA, XP, Crystal, and so on, but generally informally.

For someone like me, I have course work and education in what I would generically call process improvement or continuous improvement (specifically in the context of software engineering). But not having a certification in various methods or processes or frameworks, I feel, has held me back from a lot of companies and positions. I also feel like getting and maintaining the certifications can be costly, especially if you tie a demonstration of recent and relevant experience to the certification program. My current employer may not be using a particular methodology or framework, preventing me from achieving levels of certification that would open up doors in other companies. But those same requirements for recent and relevant experience also make the certification worth something, so not having them would be doing disservice to the certification and certification holders.

I think that is where professional organizations can come in, if they can better serve a broader audience. I fully agree that organizations like the IEEE and ACM need to do a better job catering to Joe Programmer and also recognizing all the Joe Programmers out there – the self-taught, the people with a college degree in a totally unrelated field but may have some kind of formal training (including boot camps), the people with a computing degree, the managerial and leadership level individuals, the academics, and more. These organizations tend to have the infrastructure to store, organize, and distribute content, or partnerships with providers who can manage the content. In some cases, professional organizations even offer certifications. If only they were more recognized by industry and offered what more practitioners were looking for.

I did find your comments on your interactions with the IEEE and ACM and other organizations rather enlightening. I’ve consumed their publications (the very CACM you mentioned arrived the other day and I’m looking forward to reading it). However, I’ve always wondered why so many people that I respect as not only bloggers, but authors of reputable books don’t regularly contribute to these professional organizations, but do write blog posts or generate similar content.

These are things that I, and probably others, need to keep considering and revisiting over time. The answers are likely going to be fluid and change as we learn more, probably from our successes and failures as individuals and organizations.

Again – thanks for this discussion. I do appreciate it, and I look forward to reading more of your thoughts and work.

Wayne Hetherington

Great post Scott. I see the same issues you do almost every day. Although I have years in Agile and some coach training/experience, I would not consider myself a senior coach…yet. it is something I aspire to and agree that it takes years to develop.
I have been particularly fascinated for years now with the parallels between software teams and sports teams. Coaching is just another aspect of this.
I think drawing on the knowledge and experience of as many disciplines as possible is highly value able and have been reading voraciously about sports coaching to see what gems I can find cross application for.
I’m not a fan of certifications and only obtain them to satisfy those who view my resume. If an employer is serious they should really thoroughly investigate their potential hire, not just rely on a bunch of papers.

nuno borges

Scott, great insights. Some thoughts. Hopefully not too controversial.

1. The dearth in qualified agile coaches is following a similar trajectory as the technical roles themselves – qa, dev, arch, etc. Moore’s law is pushing demand exponentially past our ability to satisfy with adequately trained supply. Uncle Bob does a good job of doing the ‘maths’ to estimate the average age in our industry at ~25 yrs of age.

2. An average age of 25, and an Industry hungry for talent, has mysteriously conferred upon our members that ‘tenure’ is the only requirement for mastery! The number of 3 yr devs that try and convince me they are ‘senior’, but cannot tell me what a unit test is for, is astonishing.

3. I think that we all have an obligation, as leaders in our industry, to deploy a mastery/apprenticeship model where we can, and to slowly give more credence to certifying bodies like CIPS. However, until the demand curve flattens a bit, i fear that the latter will be near impossible. CIPS needs several ‘software’ disasters to occur to gain any kind of wider awareness and adoption. Regulation is coming, slowly, but it is. Uncle Bob’s fear, for instance, is that any kind of ‘software disaster’ will prompt government regulation before we have the chance to self organize as an industry. I’m not a soothsayer, but I can see some version of that happening.

4. For my part, i’ve created a model that focuses on 6 Professional Principles, and a chosen Craft (dev, qa, devops, exec, arch, etc) to help guide employee skills development and behaviours. Within this model, Mastery is only available after at least 10 years experience. The problem is that this is all piecemeal across the industry, from your CDAD, to a model i created a few years ago, to Spotify’s approach, etc. We need to standardize our mastery models, like PEng for engineers, or residency for Doctors. To add to your example above, McDonalds also spends more time training their short-order chefs than we do our young developers coming out of University. It’s shocking when you think about it in relative terms.

5. Now we get to Agile and Coaching, an I’m not going to be very consulting-friendly here. If you believe that ‘Agile’ represents a transition in our industry between traditional methods and more modern, and people-aware approaches, then you have to accept that the role of an Agile Coach is to deprecate themselves. Sounds awful, but if our industry requires coaches to come in and teach a new method of delivering software, then once it becomes ingrained in the culture and is institutionalized, the need for a coach goes away. In this sense it doesn’t abide by the sports metaphor, because we aren’t struggling with forming teams of youthful athletes filled with ego to subordinate their will for the single-minded sake of a team. Although, given what I said above, it certainly feels that way at present. For my part, having delivered software for 20 years, and doing it in an Agile fashion for 15 of those, not always successfully, I can tell you that I have never employed the role of a dedicated scrum master or coach. The reason is simple. We gave that role to our organizational leaders (team leads, dev mgrs, directors, execs). These are the individuals who will lead teams in the future, because they are the institutional coaches that have far more influence over the evolution of teams and culture. (see Kotter’s Leading Change to understand where I’m coming from here.)

6. If we look around at small to medium sized software companies today, especially those well on their Agile adoption curve, you’ll notice a conspicuous lack of the ‘forms’ of agile – not because they rejected it, but simply because they absorbed it and moved on. They are truly in the HA, and possibly RI state of mastery. Now, I realize that although my experience is 1st hand, it’s a tiny data sample which is not backed up by survey data. These teams are removing themselves completely from the industry debate and the obsession with Agile. Unfortunately, this narrative is getting drowned out by the delayed Gartner fuelled fervour around Agile, and now DevOps, and all the money being thrown at it from Enterprise. If they are getting drowned out by media, they are getting buried by the degree of mediocrity apparent from the dearth of not just coaches, but every other craft in the domain of IT. A casual perusal through LinkedIn is enough to assuage you of any fear that this is not the case. If true, then the final frontier remains ‘enterprise’, whose adoption curve started later, and is far longer temporally. The first widely-read article on the ‘Death of Agile’ was published in 2008, and now we are seeing them published for ‘DevOps’ in 2017. I work in the financial sector today, and as far as everyone here is concerned, Agile is new and unproven! 🙂 However, we are far more clever than we realize, because DevOps and the ‘digital revolution’ have become the new trojan horse packages for the principles of development that make sense.

7. Finally, I think our approaches to coaching is necessary for now, but I firmly believe it to be temporal to the state of immaturity in our industry. As a consultant, I am obligated to my client to provide the best service I can, and if coaching is a need, then I will give them coaching. However, as a craftsman, I am obligated to my profession to wean the industry off of the dependency on coaching, because I am optimistic that we will grow into a strong self-directed profession one day. At that time, ‘Agile Principles’ will become standard ‘organizational principles of development’, and it’s partially our responsibility to guide our clients, and our industry, in that direction. May take 10-30 years, but hey, we don’t do this because we lack passion and commitment! 🙂 Or as Steve Jobs was fond of saying – we must be insane.

Paul Oldfield

Hmm… I think one of the problems with this is that there is a scarcity of Agile Coaches.

Anyone who already *IS* an Agile Coach has no need to invest the time and effort to get certified.

Adrian Potter

Was asked in a Client interview once how my team could create agile coaches within an organisation from people with no agile experience. I replied, I’m sorry but I think the most important element is having been there and experienced what it is like to be part of a team, so either hire people with this experience and grow the talent or allow people to participate as a team member and grow from there. This reply didn’t fit their expectations. Another consultant said it could be done within months by attending a training course. I didn’t get the role. The other consultant did.


Ugh. If it’s any consolation I suspect that organization will get what it deserves. Sadly, in the end, they’ll blame agile and convince themselves that they were special which is why agile didn’t work for them.


Scott, thanks for this amazing and insightful blog post!
I totally agree that we have a lots of scammers in the market, and lots of self-claimed agile coaches that do nothing except spreading bull$###

I am not an exception here. When I look back, I see that in point of times I faked it too. and I am shameful of that. But no doubt that the role of the Mentor/Guide is invaluable here. After 8 years of practising and preaching agility, I came back to start the basic of coaching. I found the ICF program valuable. especially for helping those arrogant practitioners, like me, to show them there are different ways of coaching – professional coaching.

thanks again 🙂


Leave a Reply to Scott Ambler Cancel reply

Your email address will not be published. Required fields are marked *