Agile Coaching – Who should be Coached?
Photo courtesy of Institute for Sustainability
Several people I respect have written recently on the subject of Agile coaching. The question they all pose is ‘who should be your coach?’
The next question is: who should be coached for Agile?
Coach your managers, with their teams
Once management has hired the best coaches they can, it’s easy to believe that Agile adoption has been taken-care of. Everything should happen smoothly and quickly, and go according to plan.
In practice, as the team’s understanding of their process gets better, the gaps between team and management, or team and budget-holders, or developers and QA become clearer to see. This can actually reinforce underlying issues of ‘them and us’.
It’s like when your neighbour decides to repaint the outside of his house, and it looks terrific, but makes yours look bad. Yours is the same house you know and love, theirs just got upgraded, is all.
For this reason, we prefer to coach teams and their managers and leaders. The more holistic the learning, the more effective it is.
Under the title Agile needs Coaching, Ben Linders says that organisations that are not able to coach from within, are the ones who benefit most from hiring an external coach. He wants coaches to establish a culture where people help each other.
In other words, you should use external coaches until your internal resources are strong enough to take-over. I’ve used that successfully myself. Plus it’s easy for the business to measure the success of their external coach – the quicker they make themselves redundant, the better they are!
As an aside to that, Rachel Davies, author of Agile Coaching commented on her own surprise at having held the same coaching role for three years! Reflecting on it, she attributed it to the rate of expansion of the company and the degree to which they challenge themselves to improve.
“Being coached is more important than having a coach. Change doesn’t need coaches, it needs coaching.” Ben Linders
I also endorse Ben’s notion of ‘coachee pull’ for interventions. Part-time coaching can remove the constant pressure of having to live-up to what you think your coach wants and gives people the space to try stuff out, then talk about the experience afterwards. That’s a complete learning cycle, where real value is ingrained retrospectively. We learn best once the pressure of the task has passed.
Dan Tousignant asserts that “Anybody with a passion for learning and sharing can be a coach. As with leaders, coaches can emerge from within a team.”
However, Chuck Cobb distinguishes between team-level and enterprise-level coaching. He highlights the assumption that what’s good for the development process is not necessarily good for the whole business. I recall making a similar point in the post Agile was Designed for Developers not Management.
“The company’s overall culture and business strategy needs to be optimized around whatever the critical success factors are for the business that they are in.” Chuck Cobb
It takes a breadth of business management experience as well as development experience to carry-out an Agile transformation. That’s not the job of a single person, it’s a collaborative effort and it’s best done incrementally.
So let’s adopt Agile, agilely!
Absolutely, Agile, agilely. We nip the ‘them and us’ in the bud at the outset of an engagement. We define, and get agreement from the client, that the product team includes the 4D’s – Definers, Deliverers, Deal Makers and the Deal. Definers include the product owner/manager as well as the executive creating the roadmap. Each ‘D’ has team and executive level involvement across functional roles. Clients quickly see that this vertical and horizontal alignment creates a common language fluency and eliminates the siloed towers of babble.
Good article – well done and thanks for the reference to my own site. I very much agree with you. There is a wealth of information about almost every minute aspect of implementing Agile at a team level but comparatively little is known about how to make it work at an enterprise level. I’m amazed at the number of people who *think* they know how to do that and that it is just a simple extension of team-level Agile practices when it is much more than that.
I’ve developed some online training on this that goes into a lot more detail on Agile Project Management and implementing Agile at an enterprise level and I’ve specifically developed a course called “Making Agile Work For Your Business” that goes into this in more detail. You can find information on my online courses here:
Basically, it is relative easy to implement an Agile development approach in a company that is in the business of developing software products. An example is Intuit that produces TurboTax, Quicken, and QuickBooks. In that kind of company, there is a strong and natural alignment between an Agile development process and the business objectives of the company. A lot of it has to do with how the company manages financials. In that kind of company, there is typically a budget for ongoing development and support of each product and some amount of discretion is normally given to the product team to make more detailed decisions on how to utilize that budget most effectively to maximize the success of that product. That model is very consistent with an Agile development approach.
In a company that is not in the business of developing software products like an Intuit, it can be much more difficult because there may not be as strong and direct a linkage between the development process and the company’s business objectives. Again, a lot has to do with how the company manages financials. In this kind of company, the business is typically much more project-oriented and there may be some level of competition among projects for funding. There is also likely to be some need for providing some kind of portfolio management approach to see that the return on that investment among these project investments is managed effectively and optimized. That will probably require some kind of compromise to adapt to an Agile development approach.
Another important misconception that is directly related to this is that people see “Agile” and “Waterfall” as polar opposites of each other, think that there is a binary and mutually exclusive choice between those two approaches, and attempt to force-fit their business to one of those extremes. The right solution is to go in the other direction and fit the approach to the problem and to the business environment and sometimes that requires a blend of Agile and traditional plan-driven project management. It takes more skill to do that, but it definitely can be done. This is another topic that is addressed in more detail in my online training courses.