Opinion: Agile Coaches Frequently a Source of Adoption Problems

I'm starting to grow uncomfortable with the notion that managers are a bunch of idiots that should be suppressed so the real workers can get things done. While that works in a book by Karl Marx, it doesn't fit many corporations, who are, for better or worse, run by people who believe in management-driven projects with individual responsibility.

When I gave up on trying to change that fact, I found lean and kanban, which address the same issues without the mandate to shift the culture to be like a San Fransisco start-up company. You end up in the same place (TDD, fast releases, minimal waste), but with the managers on board this time, which means it's going to be sustainable.

My golden rule of managers: if they don't feel like they at least had a part in coming up with the idea, it will fail, no matter how good or effective it is.

Particularly when the client, for one reason or another, does not give the time to do extensively more than introduce values and install practices? Namely, in a bad economy, with consulting/training budgets tighter, when the client can't be convinced to keep you on board long enough to cultivate in-house shepherds.



Have you done better for them by at least getting them "this far", or have you failed? Have you done a service, or disservice? Should you have declined from the start?



Hm...and what is the meaning of life?

Let's realize that some coaches come in as independent contractors while others are employees of firms and may have less control over whether or not they can choose to take the assignment. The larger the firm, the further they may be from those they will actually work with. Indeed, they may never talk to the client until the day they show up and find out what the client really wants. But the issue, in either case, is gaining an accurate assessment of what the client expects when they bring in an agile coach/trainer.



I certainly don't think "managers are a bunch of idiots." An important fact of any change management is that management got to where they are, presumably, by behaving the way they have been. What's in it for them to change what they are doing? Who wants to be different and why? Why has an agile approach been chosen as the solution to the reasons change is needed? And are they really looking for an agile coach or some sort of project manager to oversee the teams?



A good bit of analysis like this may not be done to a level that would help identify what "tailoring" a company expects based on their understanding of an agile approach combined with what level of change they are willing to tolerate.



One issue raised is the topic of "long enough" and how that is measured. Is it embedded time (i.e., full-time over some calendar period)? Is it part-time (again over some calendar period)? Is it a specified number of "contact" days or hours? Firms take very different approaches to this, larger ones preferring the embedded approach while smaller ones usually preferring the "contact" approach.



As to "champions," one would hope one or more of these exist before the organization moves into an agile approach. If no one in the company is championing the effort and truly understands what they're getting into, then I think any coach could find it hard going. And, the larger the company, the somewhat more senior the champion needs to be because of how broadly the move to an agile approach might affect the organization. In an organization with very discreet functional areas, a cross-functional team can involve many managers having to support the effort. A champion needs to be able to have credibility across all of those areas, which may mean someone higher up in the hierarchy than first level managers.



I do not think one has to be "arrogant" to accept the fact that people may not like the loss of control, especially if there were pre-determined functionality, cost and schedule deadlines and the agile approach was expect to "fit in" to an existing set of constraints. If all of these were set before the organization had a clear idea of what going to an agile approach would mean, early progress may be extrapolated to "show" that a more aggressive velocity needs to be required to meet schedules and complete all the functionality. If it does not look like that will happen and there is no way to be flexible about schedule or scope, it should not be surprising that folks used to dealing with this in other ways would want to step in and (re-)introduce traditional development management practices.



Regarding dependence on the coach, I have found that it is management that expects the coach to do much of what you describe, not the teams. This suggests to me that they really expected project manager, not coach, behavior and may have communicated that expectation, without using those words, to the teams as well.



So, the question is, how does the coach "own" all this? How can expectations best be set given the various ways coaches come into an organization? And, perhaps most importantly, how do we (know to) chose NOT to take on the coach role if we sense we cannot reasonably "own" the situation?

When I gave up on trying to change that fact, I found lean and kanban, which address the same issues without the mandate to shift the culture to be like a San Fransisco start-up company. You end up in the same place (TDD, fast releases, minimal waste), but with the managers on board this time, which means it's going to be sustainable.

Have you done better for them by at least getting them "this far", or have you failed? Have you done a service, or disservice? Should you have declined from the start?

So, the question is, how does the coach "own" all this? How can expectations best be set given the various ways coaches come into an organization? And, perhaps most importantly, how do we (know to) chose NOT to take on the coach role if we sense we cannot reasonably "own" the situation?

I agree with all you have said above but also that as coaches our sales pitch is wrong-We should not just sell our skills on a per project basis but stay involved to ensure the project does achieve the expected results post go-live. Coaches should also continue as a mentor as the team moves onto their next assignements.
I try to promote a See One -Do One approach to coaching - its a harder sell because fundamentally we are asking clients to fork out more money to keep the coach on board longer - but the benefits of this approach overcome the issues you identified above- With this model we actually become 'coaches' and mentors and pretty much take a back seat while the team puts in place the learnings and skills they have acquired- of course the model works even better if the coach is moved onto the next project team and only becomes a sounding board to the previous project team.
So I guess I am suggesting that we are setting the wrong expectations with our clients and need to modify the message to stop selling a silver bullet.
Cheers I enjoyed your opinions.

Yes, I see this too. I often propose ongoing coaching for the dev team, PO team or (at least) the ScrumMaster. Although I proposed it as "required", this service is perceived as nice-to-have and often gets cut out of the final contract.


I always *assume* there will be clashes with the predominant organizational culture. This should not surprise anyone. To counter this I stress the learning cycle with teams I train, so they understant the basic tools to continue learning themeselves. But human nature being what it is, people need to learn through experience, not teaching. And an outside POV can be very helpful for learning from experience, because it can reframe events in a new way, that opens up new possibilities. It's about raising awareness so smart people can make more effective choices.



Last year I retrained as a professional coach, and I now see enormous opportunity to better teamwork simply by supporting individuals, ongoing, in a light-handed way (ideally: in addition to training and initial mentoring). I should also be passing on basic coaching skills, to make myself redundant, as a coach, over time :-)



Perhaps I need to sell the value of this service better. Yes, we can be a safety net - and it's prudent to keep the safety net even after the first day of trapeze lessons! And, to be a safety net does not require that I am there 100% of the time. I agree with Amr, this can breed dependence and slow learning.



But I don't what to be a scare-monger either. This is a good thinking exercise: How will I sell this as contributing toward the team's/organization's most important goals?



(By the way - it's great being back and active on InfoQ again. After some time out, I'm back in business, folks! And I love the improvements to these comment threads :-)