February 7, 2006

...Learn TDD with Codemanship

Agile Coaching

Occasionally complete strangers come up to me in the street, grab me by my lapels and, through their clenched teeth, ask me "what is Agile Coaching?"

And they've got a point. What actually is 'Agile Coaching'?

Just as it sometimes makes sense to eat the pie first and the peas next, we can tackle this conundrum in two distinct parts. Namely:

1. What is 'Agile'?
2. What is coaching?

I've agonised over the first question, as regular readers might know. The concensus (inside my mind, which is good enough for me), is that 'Agile' (with a capital 'A') refers to the core values and practices evangelised by the Agile Alliance in their Agile Manifesto. It should be noted that 'Agile' with a capital 'A' and 'agile' with a small 'a' are not the same thing. There is still some debate over what 'agile' with a small 'a' means, and - again - that's largely in my mind (which is debate enough for me).

The main jist of the Agile Manifesto is that waterfall development is bad, heavyweight processes are bad, and that you shouldn't put anything above the people - and the interactions between the people - on a project. There's a whole bunch of other waffle, but if you're iterative, lightweight and people-centric (to make up another much-needed imaginary word) then you've got the meat and potatoes of 'Agile'. Oh yeah - and you should embrace change. (Phew, almost forgot!)

Actually, and you might miss it amongst the waffle, the 'embracing change' part seems quite crucial. Another - perhaps more practical - way of saying that might be feedback-driven. In Agile Development, we make most of our decisions as a result of customer feedback on what we've delivered. This is opposed to the traditional route of making most of our decisions up front in requirements specifications and design blueprints. The old-fashioned way of doing things is often referred to as 'plan-driven'. So, key to being 'Agile' is being feedback-driven and not plan-driven.

In practice, this has all sorts of implications, and much of "being Agile" is about making change easier. In eXtreme Programming, for example, we deliver some code to pass a test. It might not be pretty, but that's okay. Our first priority is to pass the test. Our next priority is to tidy up after ourselves and keep the code in reasonable order. If we're going to make a lot of changes, the organisation and quality of our code is going to have a major impact on how easy those changes will be. So much of XP is about keeping code liquid enough to be easier to change.

I'm already tying myself in knots trying to explain what 'Agile' is all about. That's okay. It's actually a pretty woolly concept, so we have to expect a woolly definition.

Being 'lightweight' or 'lean' is another part of the 'Agile' definition. The basic premise is that we should maximise the amount of work not done in our projects. We should write the simplest, smallest code to satisfy the requirements, for example. We should employ the least developers to deliver the system. We should produce only the most useful documentation. And so on. If your project has 50 developers, and a 350-page requirements spec, then you're probably not being 'lean' and therefore you're probably not being 'Agile'.

Okay, so I hope you get the general zeitgeist. 'Agile' = feedback-driven, lightweight, people-centric.

Now, what about 'coaching'? There are many definitions of 'coaching', but I like this one best (and that's good enough for me):

Coaching: A process providing an individual with feedback, insight and guidance on achieving their full potential in their business or personal life

I'm especially happy with the inclusion of the 'f' word - feedback. For my sins (and they are many), I've worked with a lot of consultants. The MO of your average UML consultant, for example, is to impart wisdom - often in a classroom or other 1-to-many communication setting. I spend a significant proportion of my time cleaning up after them. After they're done passing on their divine insights into UML, OOA/D, 'enterprise architecture' (whatever the hell that is), and all things model-driven, they rise again into the heavens never to be seen again - leaving their bewildered and ultimately frustrated disciples behind.

The problem is, it would seem, that I already know I can model. What interests me is whether they can model. That, to me, is the essence of coaching. It's not about whether I can write effective unit tests. It's about whether you can write effective unit tests. That's why I redesigned all of my training courses to minimise the amount of time I spend standing up in front of a PowerPoint slide going "blah, blah, blah" (which, believe me, you don't want at any cost). It's not an opportunity for me to demonstrate how great I am - although I am great, even if I say so myself (and that's good enough for me).

Feedback is the critical element in coaching. My job is to give my apprentices informed feedback on what they're doing. It needs to be constructive feedback, too. What is 'constructive feedback'? Contrary to popular myths, 'constructive feedback' does't necessarily mean 'softly spoken' or 'sugar coated'. Coaching isn't a popularity contest, and if it gets results then I don't care about being their friend.

This is another point at which traditional consultants and I part company. Some consultants focus on winning the client over and becoming their best buddies, often at the expense of genuine results. Nobody likes getting bad news, so it makes total commercial sense not to give them any. Still, if your invoices are getting paid every month, I guess that's a result for you.

I'm fond of quoting something that I always attributed to someone very clever and insightful, whose name I forget (quite possibly it was actually me):

The meaning of any communication is the effect it has

Perhaps feedback is constructive if it has a constructive effect. The job of a coach is to give feeback that has a constructive effect. If someone doesn't integrate their code often enough, constructive feedback should encourage them to integrate more often. If someone is holding up planning meetings, constructive feedback should stop them from doing that. And so on.

In order to give constructive feedback, a coach has to know the difference between good and bad. The insight that a coach brings to a team is their knowledge and, more usefully, their experience of what works and what doesn't. A coach is the person that knows that fire burns. They very probably have the scars to prove it.

Of course, in reality a coach knows only a fraction more than his or her apprentices. While the apprentices might get it right 49% of the time, their coach might get it right 51% of the time. And it would be a terrible miscalculation to assume that coaches never make mistakes. Much of the benefit derived from coaching is in having someone who isn't a total novice watch you work and give some feedback. In XP, there's a lot of constructive feedback that goes on in Pair Programming, and - unless the peer-to-peer relationship is dysfunctional - this feedback flows both ways. I can actually 'coach' people who play guitar much better than I do, for example. It's hard to be objective about what you do well and where you need to improve. You don't need to be highly qualified to tell someone that they make a silly face when they use the whammy bar.

So, back to the main question: what is an 'Agile Coach'? Based on what we've seen so far, I think a succint* definition would be:

An Agile Coach is a person who provides constructive feedback - based on any level of experience or insight - to another person who is unable to objectively assess their own abilities in Agile Software Development

Interesting, BOTH sides of the coaching equation apply to pretty much anybody doing Agile Development. We can all provide constructive feedback, even if it is based on minimal experience or knowledge - though someone with more experience might get it right more often. And I can't think of anybody who can truly objectively assess their own capabilities.

I need an audience to know how good a guitar player I am. A layman might be more impressed than a highly accomplished musician, but that doesn't mean I have nothing to learn from the layman. (Unless I only ever want to play to audiences of highly trained guitarists, of course.)

I need peers to know how good a developer I am, and I need apprentices to help me asses how good a coach I am. If they're not improving, then it obviously ain't working. Yes, there should be such a thing as "Agile Coaching Coaching"...

Metrics can help here (and, for those of you who don't like metrics, you can stop reading now before I write something that doth offend thine eyes). There are ways of measuring the raw capabilities of a guitar player. You may not like their style or their taste in music - and many very technically accomplished guitarists lack both style and taste - but you can get a good feel for whether or not they're improving.

Basic metrics for productivity and quality can help give a coach a feel for what effect their constructive feedback is having on their apprentices. Personally, I got tired of never knowing for sure whether I was giving real value to clients, so I resolved to make sure I find out. That's why metrics are now always a component of what I do. They're not the be-all and end-all by any stretch of the imagination - no matter how warped. But they give me a rough feel for what's being achieved in real terms. To be brutally honest, without some objective measurements I would probably be guessing as to whether or not my services deliver value for clients.

* Okay, I lied
Posted 15 years, 3 months ago on February 7, 2006