Transitioning from developer to coach on a client.

[Zee Spencer]

I've been working with one of my clients getting their application to production and building a team to continue developing their application. It's gone amazing, and now there's 4 developers, one designer, and 1 product guy. Both my client and I agree that it's time for me to find something else to focus on, but they don't want me to leave entirely.

They are talking about a retainer model where I provide ~10 hours a month keeping an eye on the teams health; technically and process-wise.

Since this is a giant group of experienced coach-practitioners I figured I'd ask a few of the questions I'm struggling with:

1) How do I maintain credibility when I'm infrequently in the code?

2) I really like knowing how I'm adding value. How do I transfer my deliverables from features to learning? 

3) Which metrics should I be keeping an eye on? I'm thinking release cycle time, story cycle time, project cyclomatic complexity, as well as their business actionable metrics.

Thanks in advance guys!

[Adrian Howard]

Hey Zee,

On 3 February 2013 18:47, Zee Spencer <zspe...@zacharyspencer.com> wrote:
> I've been working with one of my clients getting their application to
> production and building a team to continue developing their application.
> It's gone amazing, and now there's 4 developers, one designer, and 1 product
> guy. Both my client and I agree that it's time for me to find something else
> to focus on, but they don't want me to leave entirely.
>
> They are talking about a retainer model where I provide ~10 hours a month
> keeping an eye on the teams health; technically and process-wise.

Consider tapering it off rather than suddenly switching from full time
to a few hours a week.

So I might go from full time, to three full days, to just the
retrospectives, too on-call offsite.... or something similar. Gradual
withdrawal checking that folk are okay at each stage.

One women of a Scrum-ish persuasion described this process as my
changing myself from a pig into a chicken ;-)

I'd be interested in what others think of this approach since, while I
think it's effective, I do wonder sometimes if it's a mark of my
getting too involved with the practical work of some clients.

> Since this is a giant group of experienced coach-practitioners I figured I'd
> ask a few of the questions I'm struggling with:
>
> 1) How do I maintain credibility when I'm infrequently in the code?

This is not something I worry about because...

> 2) I really like knowing how I'm adding value. How do I transfer my
> deliverables from features to learning?

... I don't consider this part to be adding value - it's validating
that the value I've added has stuck. I'm working with the team to make
sure that they can carry on without me.

> 3) Which metrics should I be keeping an eye on? I'm thinking release cycle
> time, story cycle time, project cyclomatic complexity, as well as their
> business actionable metrics.

Depends what I've been hired to help with, or where I think the
biggest changes have been made. I look back at my journal of what
I've been doing and note down the biggest changes that I think have
happened. I then try and figure out what I should be keeping an eye on
as I back away.

So if I've been spending a lot of my time helping with TDD, I'd be
keeping an eye on test coverage metrics. If I'd been spending my time
on helping get features out more regularly, I'll be keeping an eye on
cycle time.

I pay *lots* of attention in the retrospectives and ask people to
think about whether my withdrawal is causing issues before hand.

Hope this helps.

Cheers,

Adrian
--
http://quietstars.com adr...@quietstars.com twitter.com/adrianh
t. +44 (0)7752 419080 skype adrianjohnhoward pinboard.in/u:adrianh

[George Dinwiddie]

Zee,

On 2/3/13 1:47 PM, Zee Spencer wrote:
> I've been working with one of my clients getting their application to
> production and building a team to continue developing their application.
> It's gone amazing, and now there's 4 developers, one designer, and 1
> product guy. Both my client and I agree that it's time for me to find
> something else to focus on, but they don't want me to leave entirely.
>
> They are talking about a retainer model where I provide ~10 hours a
> month keeping an eye on the teams health; technically and process-wise.

Congratulations! This is an excellent situation. I agree with Adrian
that you might want to taper off gradually, if you can.

>
> Since this is a giant group of experienced coach-practitioners I figured
> I'd ask a few of the questions I'm struggling with:
>
> 1) How do I maintain credibility when I'm infrequently in the code?

Don't pretend you're still an expert with the code. Pair with people who
are now the experts, by working with it every day. (And read the change
logs from the version control.)

> 2) I really like knowing how I'm adding value. How do I transfer my
> deliverables from features to learning?

Have you not already been checking that the others are learning from
your experience? If not, do so. If so, continue.

> 3) Which metrics should I be keeping an eye on? I'm thinking release
> cycle time, story cycle time, project cyclomatic complexity, as well as
> their business actionable metrics.

Those are all good. But look at things other than metrics, too. As Yogi
Berra said, "You can observe a lot by watching." And Einstein reportedly
said, "Not everything that counts can be counted, and not everything
that can be counted counts."

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[mheusser]

Hey man -

1) How do I maintain credibility when I'm infrequently in the code?

Have you talked to Barcomb about the things he does.  If I recall correctly, when he was in South Bend, he didn't touch code.  Not really.  Maybe he paired.  A little.  And that team /loved/ him.

Knowing you, you could folks on pairing. Personally, I like testing because it has such a 'dive in and quit' possibility.  You might also do process stuff - the health of the retros, the strandup, etc.

2) I really like knowing how I'm adding value. How do I transfer my deliverables from features to learning? 

I think I touched on that above, right?

3) Which metrics should I be keeping an eye on? I'm thinking release cycle time, story cycle time, project cyclomatic complexity, as well as their business actionable metrics.

Oh Zach, you were doing so well, then this. :-P

Seriously, many people use metrics as a tool to stay out of the details --- what the Japanese were doing when they were kicking the Big 3's tail was the Gemba walk - Go To The Real Place.  Talk to the customers.  Talk to the developers.  WATCH what is actually going on. Seek to understand.  IF you do that, you might use metrics, from time to time, but you will pick measures grounded in todays problem, as an inquiry, not a control, so you'll throw them away when the problem is solved, or at least radically de-emphasize them.  Control causes dysfunction, see measuring and managing performance in Organizations, Robert Austin, it's on Amazon.

Knowing nothing else, I like cycle time, throughput, and days since we had to drop everything to work on a bug.  By throughput, I mean avg # of stories a week, maybe on a 4-week rolling average.

What are the current problems facing the org?    Tell us about those and I can give more advice.

One thing you /might/ do at this point in your relationship with the company is create a SWOT analysis limited to the scope of the delivery team.  I can probably give you one under NDA from a recent client to get the blood flowing.  Depending on the scope of the problem I just make a 2-10 page list of Strengths, Weaknesses, Opportunities and Threats within Scope of X, which leads to recommendations.  Folks seem to like it.

regards,

--heusser

[Zee Spencer]

Thanks everybody! An added wrinkle is this is a fully distributed team, with it's 'nerve center (Designer, Product Lead)' in San Francisco. 

@Adrian, great thought on the retrospectives bit. That's the core component of the proposal I've sent! 

@George, sadly there's not really a pairing culture. I do a bit here and there; but it's tough with a geo/time dispersed team. Instead we do code reviews for every story. I'll be keeping an eye on those as well as on the campfire room to make sure I keep abreast of the details that compose the big picture.

@Matt, Don't poo-poo metrics man! They're useful! I condensing the ones I'd be watching to these three: Story cycle time, release cycle time, and impact of releases on business goals.

I'm positioning myself as a coach for the product manager + executives; with the option to provide technical training for the team in regards to code hygiene and technical practices. It's something they value and I'm excited about doing, so we'll see where it goes!

[mheusser]

@Matt, Don't poo-poo metrics man! They're useful! I condensing the ones I'd be watching to these three: Story cycle time, release cycle time, and impact of releases on business goals.

They /can be useful/ in some circumstances, sure.  Personally, I prefer inquiry metrics (used to understand what is going on) over control metrics.    Here's a snip from my reply about the metrics I /like/:

"Knowing nothing else, I like cycle time, throughput, and days since we had to drop everything to work on a bug.  By throughput, I mean avg # of stories a week, maybe on a 4-week rolling average."

That doesn't sound /too/ different from what you are thinking. :-)

--heusser