Coaching agile teams - some reflections (#acguk)

It’s been a few weeks now, but I wanted to finish pulling together my responses to the UK’s first Agile Coaches’ Gathering. I’ve written already about the sessions I led at the Open Space (Appreciative Inquiry, Dilbert Considered Harmful), here I’ll talk about the other sessions I joined, and my feelings on coaching as they’ve developed afterwards.

Effective coaching styles

The day opened for me with Xavier Quesada Allue’s discussion on Effective Coaching Styles. The conversation ranged around how we use models in coaching, the influence of character, the relationship of coach and team: in the course of all this it became clearer to me that when we coach we have a number of things at out disposal:

  • Models for sensemaking - Cynefin, Tuckmann, Dreyfus, Situational Leadership - there are many of these. Unless we can form a coherent view of what’s really happening in a situation, we won’t be able to act effectively.
  • Models for action - The category is closely tied to the above: and different sensemaking models can suggest both different opportunities for and types of intervention. But by adopting a model you’re giving yourself a framework that can help focus on the right things at the right times. The danger here is that we get very attached to our models (give a child a hammer, everything becomes a nail), the onus on us as coaches is to avoid this.
  • Tools and techniques - specific interventions that we make at particular points for particular outcomes. The whole zoo of facilitation techniques, the array of influencing tools that we bring to bear.
  • Coaching styles - directive, non-directive, questioning.
  • Coaching Stance - I liken this to the psychotherapeutic notion of “stance”: it’s fundamentally about how a coach relates to the team above and beyond details of interactions, interventions and models. It’s affected by whether you’re coaching a team full-time or whether you’re a consultant-coach, but in either case it’s up to you as coach to identify what sort of relationship you want with a team, what sort of relationship a team needs, in some cases which sorts of relationship are even possible.

One interesting thing here is that these dimensions are somewhat independent: within our character and capabilities we get to choose which stance, styles, techniques and models we bring to bear. Different combinations of these will be appropriate for different teams, individuals, environments, but in principle any combination can be effective in the right circumstances. I think there’s a lot more to be said about this.

cG*P

Keith Braithwaite led a conversation on cG*P - the way that “grown-up people in the world of grown-up things” are organising their industries’ practices to meet business and regulatory goals. Standing for “Current Good (anything) Practice”, it’s roots are in the pharmaceutical industry - sampling is not sufficient to regulate the quality of manufactured goods, so the whole environment is considered and managed There are several applications in pharma - lab practice, manufacturing practice (cGMP), automated manufacturing practice (GAMP). Keith (who’d worked in one of these environments as a summer job while a student) asked - what would cG*P look like for software?

Keith stressed that cGMP isn’t much fun - it’s very closely managed, it’s about proving (via process data collection and audit) that certain things were done in certain ways, and it’s done in order that pharma companies are allowed to trade in US and European markets: if you can’t demonstrate cGMP, you are not allowed to sell your drug, period. The practice is designed to be foolproof: at which point Keith whipped out a disturbing double-hump graph based on research that indicates (i) the “average” developer is significantly less able than the best, and (ii) that the distribution is remarkably stable - there is very little movement between the groups (at least not as a result of a university Computer Science program: many might say that’s not really surprising…). We’re all aware of this, of course, but the point was that cG*P for development is about making the “average” work safely and effectively.

From the point of view of life and death, most software isn’t that important. As an industry, we generally don’t have the regulatory demands placed on us that pharma works under. (And in parts of our industry that do, there are - sometimes - equivalent disciplines in place). Something I pointed out (and have done so in other places) is that - ten or fifteen years ago - Scrum, XP and the other agile approaches were an attempt to define cG*P for development: they did not arise in a vacuum, and all of the practices and processes described had been observed individually in the best software teams in the wild for many years.

Coaching Games

At the end of the day, on the lawn outside Blechley Park Manor House, Tobias Meyer convened a session for people to bring their favourite coaching games. One or two old favourites made their appearances (but the “guided worker” game that’s sometimes used to demonstrate the perils of command-and-control style management was soon abandoned: it doesn’t give rise to a very rich set of circumstances and observations…) plus several that were new to me. I very much liked a disentangling game, where (i) a “manager” has to direct a tangled ring of eight or so individuals into a state of order (which is almost impossible) and (ii) where the ring of people has to figure it out themselves (it took a matter of seconds…)

Why did the event work? It’s always tempting to say “it was well-organised”, but I’m inclined to say it was organised enough. The Open Space adage - whoever’s there, are the right people - certainly held, but I think both the individuals and the number of participants were optimal. And while a handful of the conversations and sessions that occurred seemed to be around more general agile interest, rather than specifically coaching-focussed, there was enough (at least for me) that pushed the boundaries of my thinking on coaching per se.

The event as a whole provided a great environment for reflecting on one’s individual practice in coaching. I came away having learned much about particular techniques, styles, and approaches; having got a lot out of heating others share their experiences and ideas; and with a much stronger sense of a community of practice around coaching in software teams. I’m equivocal, though, about calling ourselves “Agile Coaches”. Though it’s certainly the case that coaching as a function is more explicitly recognised in agile approaches than in other disciplines of software development, so it may be this is a (necessary) alignment for now. The emphasis on teams and collaboration, and the mandate for agile teams to organise themselves around the work they’re doing, provide an environment in which coaching can thrive (what would a coach do in a command-and-control environment? Ensure that orders were being obeyed?) There’s a whole set of interesting paradoxes around how, as coaches, we help teams self-organise. I look forward to the day (again, agreeing with Keith) when we get beyond having to give ourselves names, and just get on with grown-up stuff in the world of grown-up things.

5 Responses to “Coaching agile teams - some reflections (#acguk)”

  • Cees de Groot responded:

    I worked in pharma for years, writing software to support what they called “technical R&D”, which is the ramp-up to manufacturing - as such we worked under GMP rules.

    GMP as it applied to us was a stack of common sense - keep old versions of reports the system generated, keep raw source data, etcetera. Everything you need to track back from a potentially faulty batch to the root cause.

    It didn’t do much for software quality, though. We had extensive testing protocols (including the project lead having to sign off paper copies of the tests results!), but IMNSHO testing is one step too late. The code was a mix of Uniface/4GL, Uniface C extensions, VAX Pascal, SQL*Plus, and I had to introduce version control and documentation generation when joining.

    So, after every dot release, the test software I wrote exercised the product, screen-scraped results, spit out a ream of paper (4-5cm for a dot release, 10-15cm for a major release), and the project lead started reading and signing test cases for half a day. We could - to an extent - prove that the software worked, but was it high quality? Hardly.

    Funny concept, “quality” :)

  • Rachel Davies responded:

    Nice summary of “Effective Coaching Styles” session. Reviewers asked us to cover coaching styles in the book but it’s a can of worms. First you have to explain all those models. Then explain that you need to look at the situation through different lenses. Personally, I think models can get in the way of responding to the individuals and situation.

  • Ilja Preuss responded:

    Hi,

    thanks for the report. Yes, it was a good event. My answer to “why did it work” would be: “because self-organization works.” I yet have to participate in an Open Space that didn’t work. :)

  • David responded:

    Mmmm … I’ve been to a couple of open spaces which were not so productive. Maybe the people there weren’t self-organized enough… :-)

  • David responded:

    Rachel - I agree that models can get in the way, and we’ve all come across people who are so wedded to one model that they can’t see the world in any other way. For me the positive about models is that they give you alternative frameworks for understanding a situation, and can counter any personal biases (our unstated models) that we might bring to bear. I’ve found it helpful to consider some situations I’ve found myself in through several different models’ lenses, even if (as is also common) I end up using none of them to progress the situatuib: models as an analytical tool rather than a prescription for action.

Add your own comment...