Agile coaching is a hot topic. It is in vogue in the IT world to heap derision on the whole profession of agile coaching. There may be a quality issue, but stop saying agile coaches need to be software developers. The discussion is of interest to non-IT people too, so I share it here.
I saw a post “Has your Agile Coach actually done Agile Software Development?”. The comments were awash with cynicism and bile:
“it is laughable what a lot of people who have never coded in their lives openly tell coders”
“Surprised they have right?”
“Very unlikely, any development at all.”
“A rubber duck is more helpful for a struggling team than someone who has no clue whatsoever what the team is doing all day”
This triggered me. I still remember being told I couldn’t possibly consult on Devops because I hadn’t cut code (actually I have but woteva). So I commented:
“This kind of elitism is harmful. The role of an agile coach is to develop human behaviours within a team and patterns within the work. They no more need to be able to code than a sports physiotherapist needs to play the sport. Developers need to get down off their high horse.”
And away we went…
I drew two conclusions from the resulting fracas:
Some people don’t know the difference between coaching and teaching, or even bossing. They expect an agile coach to “tell” teams how to do their work.
Some also confuse agile coaching with development coaching. Agile is not about how to write programs. No part of the Agile Manifesto refers to the actual craft of programming. An agile coach should not be telling people how to cut code. To coach a software development team, a coach does not need to know much about how to build software. The same agile coach could coach a team of software developers or a team of graphic designers or architects or any knowledge-workers. Agile is a pattern of behaviour, not a way to write software. In any field, an agile coach should not be telling you how to do your job. They should be helping you discover better ways to organise your work so as to explore and improve. The technical aspects are up to the team. I’ve worked with a clothing factory to improve their manufacturing value stream but I don’t know how to make shirts. Agile coaches don’t coach software development, they coach agility.
Does a sports physiotherapist or psychologist need to play football? No.
Any intelligent person can understand enough about any field of work in a few weeks to be able to coach them in team dynamics, visualisation of work, Scrum, Kanban, and other work patterns etc… That’s the expertise of an agile coach, that and how to do coaching. Any coach understands the work. They don’t need to understand it enough to do it as a day job. They can understand the work in a few weeks of study, sufficient to have a meaningful discussion with the team about what is going wrong and facilitate finding solutions. In fact a basic understanding can be obtained in an hour at a whiteboard with the team expert but a better one is had after a few weeks immersed with the team.
If the problems are technical, within the actual techniques of software development, and the team don’t hold the answers within themselves (which most workers anywhere do.), then they don’t need an agile coach, they need a specialist development advisor and/or teacher, or some other means of injecting expertise. A coach will identify and agree this need with the team, and work to find someone.
If an agile coach has expertise in the specific field the team work in, that’s useful. I’m not saying an agile coach should NOT be an ex-developer (although that brings its own problems of keeping them from interfering ). I’m saying it’s not a prerequisite because it is not what they are coaching on. An agile coach is coaching on agile ways of thinking and working.
This “you can’t possibly understand we developers unless you have done it” is prima donna snobbery. It’s just work. I’ve done software development. There is nothing special about it to distinguish it from other work.
If there is a quality problem with agile coaches, that is a different issue. The explosion in adoption of agile principles is a good thing. If the rapid growth led to a shortage of good, experienced coaches, then that’s the price we pay for Agile’s success. I know good agile coaches, so I’m sure the profession can sort itself out. Without needing to be developers.
So did most others, but a few people got quite heated. I think they are misunderstanding me, as well as misunderstanding what an agile coach is.
The people at Snowbird (who wrote the software Agile Manifesto) were software developers looking for better ways of organising work when developing software.
But they never said anything in the Manifesto that applied only to software. They uncovered, or possibly stumbled over, a philosophy of universal usefulness, as is clearly demonstrated by its widespread success. That’s what I mean by its not about software. I’m not seeking to exclude anybody from anything. In fact, I am trying to make agile coaching more inclusive by not limiting it to ex-developers.
My post unleashed a lot of anger. I understand why and I’m sympathetic. I don’t like being in the firing line but I guess I did wander onto the firing range.
As I said in that post, “there is a quality problem with agile coaches… The explosion in adoption of agile principles is a good thing. If the rapid growth led to a shortage of good, experienced coaches, then that’s the price we pay for Agile’s success. I know good agile coaches, so I’m sure the profession can sort itself out.”
I get where all the frustration is coming from. There are multiple causes:
- Management who force coaches to “make “a team be agile, to “fix” them, after a decree from the top for “transformation”, and in the absence of any change in the system of management to allow and enable new ways of working.
- People, including many of the coaches, who apparently don’t know what coaching is.
- A label of “coach” slapped on team leads or project managers.
- A shortage of good coaches.
- Companies using Agile as a smokescreen for layoffs.
- Companies driving “Agile transformation” by starting with a big bang reorg, so the coaches are tainted before they can even start.
[Important note: none of these things are about the individual, they’re about the system of work]
Dr Vu and I called our first book “The agile Manager (small a)“. Small-a agile is a generic philosophy that has grown much wider than Agile of the Manifesto. Using principles such as Agile and Lean, we at Teal Unicorn are able to unlock millions of dollars and make people’s working lives better in clothing manufacture, banking, real estate, equipment suppliers, importers, finance, training development etc. We don’t know how to do any of these, and we certainly don’t try to tell the workers.