Mixing Coaching and Delivery

10 10 2011

After a year and a half of exploring what happens when you try to mix coaching and delivery, I have formed some fairly strong opinions on the subject.

In more than one way, it’s like grinding up an entire bicycle into a barrel of steel filings and then eating them with mustard.

Is it possible? I don’t know. But I’m pretty sure that even if it is possible, it’s not a good idea.

When a coaching-plus-delivery coach is pairing with a client developer and they encounter something the client developer doesn’t understand, the coach has three choices.

A) Be in slow, pedagogical, I-don’t-care-how-many-iterations-this-one-point-card-takes coaching mode, and explain in full detail, making sure the coachee gets it and maybe even doing some spikes on the side to demonstrate concepts.

B) Explain what you’re doing as you bang out the solution, allowing enough drag to answer a few questions, but maybe slowing down only to half speed and not getting distracted from the task at hand.

C) Say, “You should have learned this when I explained it to you last week” and just abandon the client developer, leaving him in the dust in order to crank out delivery.

Choice A has definite value, as it’s the best learning environment there is and builds proficiency in the client developer if the coach is any good. This increased proficiency is the client’s reward for paying confiscatory prices for developer coaches.

Choice C has definite value, as it produces velocity and at least one useful piece of information about the client developer: whether he shrugs, gives up, and goes out to have a smoke, or whether he grabs hold, hangs on, and guts it out immediately, then goes home and sticks his nose in the books to catch up. The client buys unusually high velocity, plus information about whether his developers have what it takes to operate at that level or not.

Choice B has no real value. For a long time I thought it did, but not after long and bitter experience with it. Explanations of that sort seem to have little traction on real-world clients in real-world situations, and they serve chiefly to further frustrate the coach as he abrades his velocity yet again for what he has learned is no good purpose. The client buys low velocity and unimproved proficiency, and the consulting firm looks bad.

We need to keep our coaches choosing Choice A and Choice C appropriately, and rescue them (and our clients, and our companies) from Choice B.

How do we keep our folks in Choices A and C and rescue them from Choice B?

I think we need a changeover point, or at the least a well-defined set of changeover points. An individual coaching engagement should look broadly like this:

1) First, I coach you. Every time a basic question comes up, I’m always in Choice A mode, never Choice C. Make the wrong decision and we’ll have a pleasant, humorous, unhurried talk about why the right decision is better.

2) Now, some well-defined milestone comes up–one that cannot be postponed, at least not indefinitely.

3) Then, I depend on you for delivery. Every basic question automatically gets a Choice C answer. Make the wrong decision and I take the keyboard from you and do it right. Maybe you can cut it; maybe you can’t.

4) Finally (if you can cut it), I trust you to make the right decisions on your own as you crank out the delivery, and I move on to another developer or another team or another engagement.

I should note here that when I say “basic question”, I mean not, “Why are you using a map there instead of a list?” but “Mock? What’s a mock?”

If we have no official changeover point, or if we try to install one but get no support from management, then every coach is constantly having to make judgment calls among Choices A, B, and C, and since he’s always going to be wrong by somebody’s lights for choosing A or C, he’s going to choose B most often, and everybody will suffer.

If we can get a management-supported changeover point, then there’s never any question between Choice A and Choice C for the coach, and he never has to get anywhere near Choice B.

If a manager hassles him about Choice A, he can defend himself: “You agreed that we weren’t going to start seeing real delivery until the changeover point. You want velocity this iteration? Fine, I can give it to you; but it’s going to push the changeover point out an iteration.”

If a client developer hassles him about Choice C, he can defend himself: “Hey, you’ve been through the changeover point. You should know this stuff. Are you a software developer or a princess?”

Another reason for management support: if we get management support for the changeover point, the implication the client developers will take away is that after the changeover point, developers who can’t make the grade may get scraped off. From that implication will come questions like, “Say, can we pick a card with lots of mocking in it this time? I’m still a little weak on mocking, and my changeover point is coming up next week.”

“Changeover point” is pretty vague and ambiguous. What do I mean?

Specifically, I mean a changeover point between coaching and delivery. However, in the real world things are a little more complex.

A client developer has to learn a number of discrete kinds of things during a Pillar coaching engagement. For example, at a recent client, a bunch of Java developers and a few Perl developers had to learn Groovy and Grails. They have to understand the concept of a development environment with CI as its nerve center. They have to learn how to write automated tests in general; then they have to learn how to write each different kind of automated test. They probably have to learn to use new technologies, like DBMaintain or maven or git. They have to learn to do little-design-up-front from the perspective of TDD, which is different from the way you think about design when you’re not testing. They have to learn how to pair, and get over the ego- and agoraphobia-related aversions almost everyone has. They have to learn to think in terms of business value rather than functionality. They have to learn various code smells and how to avoid them, and various code patterns and how to apply them.

And any halfway-competent developer coach is going to be able to at least double the length of this list. It’s unrealistic to expect anyone to be a tyro in all this stuff up to a given point, and then to be an expert in all of it.

So instead of one changeover point, the optimal situation would probably be to have more than one, where you have to concentrate on the basic stuff to pass the first, more advanced stuff to pass the next, and so on.

For example, I really wish we could have seen how BJ Allmon’s plan for a recent client would have worked out.

On one of the teams there, we decided that a new client developer entering the project ought to be able to run a one-point card all by herself (except for very minimal help, on the order of “Hey, you misspelled that!”) from beginning to end, including any defects, after three weeks of coaching. That requires a certain level of aptitude in a few fairly low-level skills, and the developer can get a definite feel for the skills required by going through some representative one-point cards with her coach.

And we decided that that same developer, after six weeks on the team, should be able to run a three-point card all by herself with the same very minimal level of help. Three-point cards require both different skills and more aptitude in already-acquired skills.

We never got to see how this would have worked in real life; but I had high expectations for it. Something like this: “Bill is still an Egg, because he just started, so we’ll be coaching him exclusively. Mary passed her one-point test, so she’s a Tadpole. We’ll coach her too, but harder. Jeff, on the other hand, is through his three-point test and a full-grown Bullfrog. He’s a hair-on-fire high-velocity delivery hound, and solidly in Choice C territory.”

I’m going to recommend that something like this be part of any future coaching engagements I’m part of.

Advertisements

Actions

Information

One response

11 10 2011
DJ Daugherty

very well written… I completely agree !

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: