BT

Opinion: Agile Coaches Frequently a Source of Adoption Problems

by Amr Elssamadisy on Jul 20, 2009 |

Coaching and mentoring is one of the key roles and practices that are very beneficial to aspiring Agile teams. Coaches help teams learn Agile practices get from 'Agile seems to be something we should do' to 'we are practicing Agile development and succeeding by regularly delivering business value'.

Increasingly there are reports of initial success followed by failures with Agile adoption. The first team in an organization does really well. This team is frequently formed from the organizations top-performers and an experienced Agile coach(es) is brought in to help learn the new skills. This is usually followed by less successful Agile adoption by other teams and frequently it gets so bad that Agile is discontinued within the organization.

There are several reasons that this typically happens, and in the literature it is often blamed on the culture of the parent organization or a mistake of the teams coming afterwards. These reasons can be summarized as follows:

    The organization has a culture that is hostile/contrary to the Agile cultures of visibility, self-organization, and decisions made on-the-line instead of in management. After the initial success of the Agile team, politics take over and parts of the organization that are intimidated by the success of the Agile teams or annoyed by the loss of control attack and destroy the initiative.

    The members of the initial Agile team are now anointed "experts" and the team is broken up and each one of the team members seeds another team and acts as their coach. Unfortunately, these team members only have one experience under their belt and (probably) in a different context on the new team. So as they attempt to apply what they learned in one context to another, they get less than stellar results.

 

The reasoning above is valid in many ways, but it also put's the blame squarely on someone other than the original Agile coach(es) since they are usually no longer in the picture. Also, depending on who you are, the first point seems incredibly arrogant. But what if there is a different reason, one that precedes the attempt for growth within the company? What if the original Agile coach(es), in general, are failing to properly prepare the teams for success after the first project?

I believe that there is a problem to how current Agile coaches - especially external ones (such as the author) - have traditionally performed their jobs. In fact, I think we are part of the problem. Let me explain:

    We do a very good job - in general - teaching the skills. That is, teaching the team to run an iteration with a kickoff, demo and retrospective. Teaching test driven development. Some of us even do a very good job teaching the team to be pseudo-self-organizing by taking a socratic approach to coaching and standing back and letting the teams make their own mistakes and learn from them.

    We even do a good job - in many ways - teaching the team the values of Agile development. If we are there long enough, the values come from diligent and disciplined application of the practices.

    What many of us do not do good job of is help the teams to be independent of us. We are there as a safety net.

 

Given today's economic model, an external Agile coach may be with the team 100% of the time and they tend to rely on her. Or, even if she is there only periodically - say 1 week a month - she is still there for an extended period of time. The teams depend on her in the difficult problems. She is called in to help 'convince' others of the value of the initiative. She is called in to keep exceptions from creeping in and sliding back to 'the old way of doing things.' She is also expensive. She frequently isn't there after the first significant success. When she is gone, things slip and eventually the Agile initiative goes down the toilet. The perceived value of Agile goes from 'wow!!!!' to 'it's not as bad as it was before.'

This is the problem I have seen again and again. I've been guilty of being this type of coach in the past when I wasn't with the team 'long enough' so that other champions are there and I step back before I leave the team. But that's not good enough. I think that as Agile coaches we should look in the mirror and stop blaming our clients (even though there are legitimate concerns) for the problem and take ownership of it.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Maybe the problem is deeper than that by Michael Hedgpeth

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.

So what do you do? by Mike Bria

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?

Coaching is like a box of chocolates by Scott Duncan

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?

Re: Maybe the problem is deeper than that by Amr Elssamadisy


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.


Michael, this is a very astute observation. Kanban is lighter and still produces significant benefits. I'm not sure I agree that Kanban/Lean are equivalent to Scrum or XP (for that matter Scrum and XP are vastly different and address different areas). They produce benefits and if they are the benefits that you are looking for then great :)

Re: So what do you do? by Amr Elssamadisy


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?


Mike, I can't claim that I have this problem solved, but by being aware of it, I let the team fail much more often and learn earlier. I do my best to let them present and be champions from as-close-to-day-one as possible.

2008/2009 economic stresses are bringing this to the surface and I hope to have more than just theories, but specific approaches that work.

With that said, one of the main reasons I wrote this news piece was to see if this was my observation alone. Thanks for your note!

Re: Coaching is like a box of chocolates by Amr Elssamadisy


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?


All good questions that should be asked and - IMHO - answered by the coaches if we are truly to deliver lasting value to our clients. Isn't fun eating our own dogfood?

what can you do by stephen lawrence

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.

Re: So what do you do? by Deborah Hartmann

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 :-)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT