Agile Coaches Need Accountability

Imagine a job in which you just give your advice, and if nothing changes, it is never your fault. Quite a gig, yeah?

You might rack your brain and then remember that psychologists and behavioral therapists don’t seem to be on the hook for improving their patients. But actually, if their practice is run well, they collect efficacy metrics, and they track things like recidivism. In my wife’s case - she is a behavioral therapist - her data has shown 80% recidivism without her therapy, and 29% with her therapy - indicating a pretty high efficacy of her approach. It is true that she is not accountable to the patient, but she is accountable to the practice.

But what about Agile coaches? Who measures their effectiveness?

Many Agile coaches advocate that teams should be accountable rather than individuals. While I have strong reservations about a total lack of individual accountability for a team’s performance, it seems that Agile coaches never include themselves in the set of those who are accountable; and organizations do not seem to hold the coaches accountable either.

There is some fairness to that: coaches have no explicit power. They have no actual authority, and so they cannot make any decisions for their teams. Yet, coaches advocate for soft power and influence, claiming that explicit authority should not be needed. While I also have reservations about that (same reference as before), the implication is that a coach does have some power and influence, and therefore should bear some responsibility for the performance of their teams.

If coaches were accountable, what would that look like? We don’t want to turn coaches into managers: that would defeat the purpose of a coach, which is to help their teams and IT managers to learn new ways of working. If coaches had explicit authority, we would then be overloaded with potentially conflicting sources of authority.

The best approach might be a form of joint accountability. The English say, “In for a penny, in for a pound”. If a coach is asked by management to work with some teams, and invests time with those teams, the coach should be, in some measure, jointly accountable for improvements made by the teams. If the teams do not improve, it is partly the coach’s fault, and if the teams improve, it is partly due to the coach’s help.

That makes sense: coaching is a joint venture between the coach and those who are being coached. In the end, those who are being coached must do the heavy lifting, but the coach is providing valuable insights and ideas, stimulating debate about those, and catalyzing decisions and improvements.

The problem today is that coaches are not held accountable at all. They need to be. Today, if things do not improve, the coach moves on to another set of teams, but the technical manager who oversees the teams is left with full accountability; and the teams effectively have no accountability, because - according to the Scrum model at least - the whole team is accountable, and so if a technical manager needs to address the performance of, say, ten teams, he or she needs to talk directly to all the team members of all those teams. That does not scale.

Scaling is an important issue. To scale, there needs to be point-person accountability.

At this point, you might be thinking that I am talking about military style accountability, and that if performance is not up to par, then the accountable person will be demoted, reprimanded, or fired. That is not the kind of accountability that is needed for leading programming teams.

What is needed is a point person who is able to have rich and honest discussions about issues. That way, a technical manager who oversees ten teams can collect the point people of those teams and have a productive discussion about how to improve things.

One practice that I strongly believe in is to not trust what your direct staff tell you: go to the source. Thus, if a technical manager speaks with the team leads or coaches, and hears that the main impediment is a certain issue, the manager should also speak directly with various team members, perhaps some of the tech leads. Do that to verify, and to obtain alternative perspectives.

Nevertheless, a manager needs point people to strategize with, for planning changes across many teams. And there needs to be some accountability: if a team has a team lead, and it also has an Agile coach, those two people should bear some accountability for the improvements that are planned.

That means that if the improvements are not forthcoming, those individuals are the ones who are pulled back in with the manager and asked why - in a collaborative and productive way. And there needs to be measurement of the actual performance of the teams. That way there is clarity about whether things have actually improved.

If coaches were accountable, they would start to demand that the technical managers who assign them have explicit performance based goals for the teams. Today, it is all too common that Agile coaches are assigned to teams without any goals other than “make the teams Agile”. 

Such a vague goal is not measurable. Agile transformation needs to be coupled with tangible business performance goals, and the Agile practices that are coached need to comprise a strategy that supports the business performance goals. Thus, management needs to understand the practices, and how they will support the business goals. An Agile coach is the right person with whom to discuss that linkage.

As a coach, I know that there is a risk in making coaches accountable: a coach “has their hands tied” to a large degree: a coach can only try to persuade - they cannot institute anything. Their power is indeed “soft”. Thus, if things do not improve, it might actually not be the coach’s fault in any degree. That is why full transparency is needed with respect to the coach’s work and the actions of the teams. There should be a record of the things that the coach advocated, and what was actually done. Facts speak for themselves - if one has the facts.

What is the actual problem though? Why bring up this issue? The problem I see is that Agile coaches spend way too much time splitting hairs about Agile practices, when there are much bigger issues pertaining to continuous delivery. Coaches are too comfortable: since they are not measured, their excessive focus on inconsequential things is not tied back to their effectiveness. 

If coaches were jointly accountable for team performance - things like feature cycle time, defect rate, and customer satisfaction - then coaches would suddenly take a much greater interest in all the “technical things” that have a huge impact on team performance. We would see coaches taking AWS training and learning about DevOps. Today, they contentedly rest on their Agile knowledge, secure that they are the “Agile” experts, no matter how well the teams perform.

Accountability is essential. Without accountability things do not improve. Agile coaches need some measure of joint accountability for how their teams perform.