Consider this quote from James P. Womack: "We've got too little management and therefore need too much leadership".
Someone who has become specialized as an Agile coach necessarily benefits from the perpetuation of Agile coaching. This doesn't mean that Agile coaches are nefarious and interested in suboptimal outcomes, but perpetuated specialization typically creates narrowed perspectives and thus overly-narrow interpretations of conditions and needs.
The result is often the very same counter-productivity that we observe when someone is given the exclusive job of capturing requirements for a software project: they fill all of their time exercising their specialization, creating an inventory of work that is out of sync with the progress of the team.
When we bring Agile coaches into software development efforts, we should recognize the underlying problem that is being signaled: that software development managers are not presently equipped to manage the software development work that they've been tasked to manage.
By failing to recognize the underlying problem, we often go too lightly into engagements with Agile coaches, and we end up failing to use them to solve the root cause problem, and this perpetuates the need for longer engagements with Agile coaches. This, in turn, drives Agile coaches further into the reaches of specialization, and narrower perspectives, accelerating the erosion of their usefulness.
To break this cycle, we need to recognize the most important reason to bring on an Agile coach: The purpose of an Agile coach is to transform managers and the management system so that managers, in turn, can transform their organizations.
Coaches initially take on responsibilities that ultimately need to be the responsibilities of a manager. Even if the outcome is an improvement, when a manager's job is split between an authority position (the Boss), and a guidance position (the Coach), the outcome isn't as good as it can and should be. Nonetheless, if a manager is in a position to need a coach, then the coach is inevitably going to take on some of the manager's responsibilities for teaching and transformation while the manager undergoes rehabilitation of his own.
The coach and the manager must recognize that these conditions are a necessary evil. The goal is a transition away from the split direction of a team between a manager and a coach. The longer that this split is in place, the higher the likelihood that the new behaviors learned by the team will be undone by the manager when the coach moves on.
Agile coaches can find themselves as removed from the work of software development as the managers that they are called to rehabilitate in the work. For an Agile software development coach to remain effective, he has to be an active software developer. Just as managers fall into the trap of losing software development currency, so do Agile coaches. An Agile coach who doesn't also do software product development for a living is a ticking timebomb of counter-productive guidance for a software development team.
Consider this quote from Daniel Markham: "If you're going to train something, you should be able to do it. And I mean do it to a very high level of expertise. An agile coach should be able to code, perform analysis, manage the project, test -- anything that needs doing on a project. If she can't, then how can you talk to her about your particular situation? If your agile trainer was a BA last week, or never slung code in his life, or is a professional trainer, or -- let's be brutally honest -- is making less than the members of the team are, you've got a dud. It seems like common sense but it bears repeating: you can't train something you haven't done. And "done" means a bunch of times, not just on the pilot project."
The qualities and abilities that Daniel outlines are qualities and abilities that we need to expect from software development managers. If they don't have those qualities and abilities, they need to get them, and a coach might be a way to get there. If the coach doesn't have those qualities and abilities, most of what's produced during the engagement doesn't become lasting, transformative value.
Agile coaches who themselves don't know the work of software development can't teach managers to know the work sufficiently to manage it. They can only teach them to become other disconnected Agile coaches. This is how the second half of the first decade of Agile came to be dominated by the doctrine of Servant Leadership. As more senior leaders in the Agile community spend more and more time in roles that are ever distant from the work of software development, Agile itself is becoming more robotic, more mindless, more of an orthodoxy, and even more of a liability than a benefit.
Servant leadership is one approach - one tool - fit for the organizational conditions that it serves best. An Agile coach often embraces the edicts of servant leadership as a universal panacea when his duty to stay sharp in the full curriculum of software development is dulled by the ease of Agile coaching specialization. But any tool used indiscriminately is going to undo any benefits that it provided in the circumstances where it was an appropriate choice.
A servant leader's typical proposition is that an organization's ability to meet expectations will be transformed if only its inherent creativity can be tapped and unleashed. While tapping and unleashing unused creativity is transformative, it's extremely rare that doing so is either sufficient or sustainable. It often creates conditions that not only lead to unmethodical exploration of ideas, but also makes teams feel that they have a right to this kind of behavior. In other words: "self-determination" rather than "self-organization".
Servant Leadership as a panacea is also a real side-effect of past experiences with bully management. It's an over-compensation reaction to some very real and very tangible painful experiences of abusive directed authority. It's an equal and opposite reaction to an extreme. It, as well, is an extreme. It's as much an undesirable specialization of behavior as abusive directed authority. It's often a programmed predisposition, rather than a conscious choice informed by circumstance.
The Servant Leadership doctrine often patently dismisses the greater goal of balance between directed authority and creative enablement, almost entirely eschewing the value of informed directed authority and skilled directed authority in favor of an over-indulged creative enablement.
A job in creative enablement is a lot of fun, and many Agile coaches have come to feel entitled to these kinds of engagements. They're light, they're fluffy, they can come with no measurable expectations, and they're often damned lucrative - especially in software organizations in the thick of the detritus of an unrecognized management crisis.
The increasing prevalence of Servant Leadership also presents a great opportunity for consultants with little real experience in Agile to re-brand themselves as Agile consultants. It allows for anyone with even a modicum of summary knowledge of Agile development to have a role in the Agile bonanza. But we all lose when this happens.
If you don't already know what your problem is, then pre-supposing an Agile(tm) solution further deepens the mindlessness of robotic management, and it diminishes the Agile body of knowledge. And ultimately, it exposes our organizations to the risks of bringing in help that may only have the ability to talk the talk - which is often all that is required of Servant Leadership - and often all that servant leaders assert is required of them.
Again from Daniel Markham: "One guy (famous author again) basically put it like this to me when I told him the team wasn't succeeding: I'm here to demonstrate certain practices and to show that they work, not to just stop everything and attend to what the team is dealing with today."
To move forward through this crisis, we need to set new goals for software development management: To be close enough to the work to be able to manage work, and to use directed authority in service of helping the team meet expectations when creative enablement turns "self-organization" into entitlements for excessive experimentation.
And we need to re-define the role of coaches from servant leaders to temporary co-managers, helping the team to meet expectations while bully management and its detritus is transformed into effective software development management.
Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience
Learn more about my work and how I can help you at ampgt.com
