Tailoring an Agile Process

[George Paci]

All,

We talk a lot about tailoring an Agile process to a team (or anyway I do).

When you take a suit to the tailor, you try it on.  When you tell him some part of the
suit is uncomfortable (shoulders too tight, sleeves too long), he changes that part to
make it more comfortable (let out the back, shorten the sleeves).

When you're introducing a process to a team, the team tries it out.  When the
team tells you some part of the process is uncomfortable (TDD is hard, writing
automated integration tests takes too much time), I now think the *last* thing
you should do is change that part to make it more comfortable.

Thoughts?
--George


  To a software guy, the word "Enterprise" has strong connotations of a
  five-year mission -- and cancellation after three.

[George Dinwiddie]

George[0],

On 8/13/13 1:07 PM, George Paci wrote:
> All,
>
> We talk a lot about tailoring an Agile process to a team (or anyway I do).
>
> When you take a suit to the tailor, you try it on. When you tell him
> some part of the suit is uncomfortable (shoulders too tight, sleeves
> too long), he changes that part to make it more comfortable (let out
> the back, shorten the sleeves).
>
> When you're introducing a process to a team, the team tries it out.
> When the team tells you some part of the process is uncomfortable

> (TDD is hard,writing automated integration tests takes too much time), I

> now think the *last* thing you should do is change that part to make it
> more comfortable.
>
> Thoughts?

There are different types of "comfortable." And there are things you can
grow into, and things you cannot.

- George[1]

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

[George Paci]

On 8/13/13 1:56 PM, George[1] wrote:
> George[0],
>
> On 8/13/13 1:07 PM, George Paci wrote:
>> All,
>>
>> We talk a lot about tailoring an Agile process to a team (or anyway I
>> do).
>>
>> When you take a suit to the tailor, you try it on. When you tell him
>> some part of the suit is uncomfortable (shoulders too tight, sleeves
>> too long), he changes that part to make it more comfortable (let out
>> the back, shorten the sleeves).
>>
>> When you're introducing a process to a team, the team tries it out.
>> When the team tells you some part of the process is uncomfortable
>> (TDD is hard,writing automated integration tests takes too much time), I
>> now think the *last* thing you should do is change that part to make it
>> more comfortable.
>>
>> Thoughts?
>
>
> There are different types of "comfortable."

Well, the two types of comfortable -- scratch that, UNcomfortable I'm most
familiar with are:

1) "This is haaaaarrrd!" (sometimes disguised as "This taaaaaakes too
long!")
2) "I don't want to have to say that." (to peers or to management)

Anybody have more?

I hear (1) for planning and estimating a lot, continuous integration
occasionally.
For [TB]DD, I think it's there sometimes, but less audibly (because you
can get the
Coach to do some of the work and teach you how to do it better).

I hear (2) for estimating, functional testing, and tracking things --
mostly velocity
and test coverage. And retrospectives.

Unfortunately, practices that depend on meetings are easier to avoid: by
being
"unavailable", some required participants can delay a meeting until the
point where
they make the case that we'll just roll it into next iteration's, which
they later
turn out to be unavailable for.... [a]

Where else do people see discomfort in teams or individuals? And what
can you
do about it when you're figuring out a process?

A team that does all and only Agile practices that they're *comfortable*
with
is going to hit problems quickly, and if retrospectives are something
they're
not comfortable with, they're never going to course-correct. The
solution isn't
to say, "If you're not doing retrospectives, you're not really Agile" --
not because
that's false, but because it doesn't solve the problem, which is that
they're not
doing retrospectives, which is because some of them don't really want to
change.

I'm beginning to see why Agile coaches charge about the same hourly rate
as psychiatrists. If only I could write Xanax scrips....

> And there are things you can grow into, and things you cannot.

I don't get this, but I get the feeling I'd be better off if I did.

--George[0]

[a] One time I experienced this, the unavailable party was a V.P., which
stands for
"You don't tell me what to do; I tell *you* what to do."


"This is why the Ramones were necessary."
--Tony Nassar, on Procul Harum's "Conquistador"

[George Dinwiddie]

George,

On 8/13/13 2:37 PM, George Paci wrote:
> On 8/13/13 1:56 PM, George[1] wrote:

[snip]

>> And there are things you can grow into, and things you cannot.
>
> I don't get this, but I get the feeling I'd be better off if I did.

1. If the shoulders of the suit are too tight, adjusting the suit is, of
course, the right answer. Your shoulders are unlikely to get smaller. If
they do, it won't be for a long time and will likely be accompanied with
worse things to worry about.

2. When we buy clothes for children, however, we tend to buy them a
little large. Not so large as to be falling off them, but large enough
to give them room to grow.

3. When we're teenagers, we want to buy a suit with a little style, or
what we think is style. Our parents likely realize that the style won't
be suitable in a few years, but they'd rather we wear this suit at Aunt
Mae's wedding than jeans and a t-shirt.

4. For myself, depending on my current state of waistline, I may buy
pants with room to grow, knowing I likely will.

At the team level, dealing with annual budgets and forecasts seems
similar to #1. Sure, it would be better to run the business on a more
frequent cycle time than annually, but we're likely stuck with what
we've got for the time being. We often don't have the influence to
adjust that, and until we can deliver frequently and reliably, don't
have the credibility that we could make shorter cycles work well.

Writing automated acceptance tests is a bit like #2. They're not going
to be doing a great job of it for awhile, but they can grow into it.
They can learn over time to specify the what instead of the how to get
more resilient tests. For now, I'm happy they're writing tests at all.

Estimating in story points and task hours seems like #3 to me. I
consider it waste. I think they'd do better just counting stories. But
if they want to do more estimation work, that's their choice. Someday
they might grow out of that style.

Avoiding transparency in tracking is a bit like #4. Yes, it would be
better to keep my waistline smaller so I don't need room to grow. It
would be better to be totally transparent about progress. Sometimes
knowledge of the situation makes this a naive choice, though.

There are other things that are like buying something other than a suit.
Not doing automated builds is like wearing dirty jeans and a torn
t-shirt to Aunt Mae's wedding. I know Aunt Mae, and it's just not
appropriate.

The metaphor has been stretched to the point the seams are letting go,
but I think you get the point. I'm always looking for the right order of
adopting things. It's different for different teams and for different
organizational contexts. And it's hard to know before the fact.

- George

[Jean-Charles Meyrignac]

Hi George P,

I'll try to make you reflect on the role of a coach, and what is change.

And there are things you can grow into, and things you cannot.

I don't get this, but I get the feeling I'd be better off if I did.

Firstly, you need to imagine what happens to the individuals in a team.

You want them to use all the agile best practices at once, while they are still comfortable with their old process (and most of the times, they believe that they are comfortable even though they are miserable).

Acquiring a new habit takes 60 days if you are alone.

Since it's a team, the team can probably learn 2 or 3 habits at a time, and probably in 1/4 of the time.

Why do you want to change all their old habits at once ?

If you have a team of seniors who work since 20 years, do you think that they can change their habits in a few weeks ?

Since they cannot learn all the best practices at once, you have to concentrate on the most efficient practices for them (and every team is unique about these), and when one habit is acquired, you can encourage them to learn a new one.

Personally, I strongly recommend starting with retrospectives, without forcing anything else.
Perhaps they don't like your retrospectives. Is it a waste of time for them ?

In a retrospective, you have to communicate in a team as follows:

- if the team is new, focus on the tasks

- once the tasks are clear for them, focus on the process

- once the process is clear for them, focus on the human relations

In my case, I directly focus on human relations, since their attitudes change almost instantly once there is openness.

Secondly, you need to realize what change is.

Do you think that you can force change on somebody ?

It's impossible, unless you believe that taming causes change.

Do you think that you can change yourself ?

I'll probably shock you, but you cannot change.

Did you ever look at your own change process ?
I did (I tried to change during 20 years), and believe me, I cannot force it.
Willpower and effort has nothing to do with change.

What is change ?

Change is a mysterious process, and it just happens.

Everybody is always changing, except that nobody notices his own change, because the change is incremental and too small to notice.

But your change is visible when somebody outside of yourself checks every few weeks.

Since change always happens and you cannot force it, how can you help a team change then ?

Simply by accompanying people, by helping them confront their fears and by using a confident stance (after all you are the "expert").

Find where there is fear, work on this fear (just make people look at their fear directly and it will disappear), and change will happen.

Change happens only when there is acceptance.

So, now, I have a few questions for you:
 - what are the differences between coaching and mentoring ?

 - what are the differences between coaching and leading ?
 - what are the differences between coaching and bossing ?
 - do you have children ? And why do you think I ask this question ?

JC

[Tim Ottinger]

Going for comfort is a metaphor sure.

Let's go a different way.

You walk into a workspace and find that people have been getting injured for years, and maybe a few deaths a year. 

People are proud of how badass it is to work there, and show of their scars and stumps. 

Is their comfort and pride the things you want to address? 

Or are you going to look at hazards and safety and risk? 

Will it make them comfortable to have a safer place to work, or will it ruin the badassedness of the place? 

Let's try this one for a while. 

--
You received this message because you are subscribed to the Google Groups "Agile Coaching Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-coaching-su...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------
http://www.industriallogic.com/
http://agileinaflash.com/
http://agileotter.blogspot.com/

[George Paci]

> Hi George P,

> I'll try to make you reflect on the role of a coach, and what is change.

OK, wise and all-knowing Sensei, I will sit at your feet for a bit.

>>> And there are things you can grow into, and things you cannot.

>> I don't get this, but I get the feeling I'd be better off if I did.

> Firstly, you need to imagine what happens to the
> individuals in a team.

> You want them to use all the agile best practices at once,
> while they are still comfortable with their old process
> (and most of the times, they believe that they are
> comfortable even though they are miserable).

1) No, Sensei: I specifically want to pick a set of practices that
will be as useful to this team in the short term as possible. Close
to the optimum set is fine.

2) Not everyone has an old process: I've coached more new-graduate or
new-to-a-team developers in the past year than I had in all previous
years put together. This is a rare and precious opportunity, for is
it not written that as the twig is bent, so grows the tree?

3) Does not the Parable of the Boiled Frog already tell us that
frequently the miserable are at the same time comfortable? Lo, even
the novice monks are familiar with this paradox.

So at this point, Sensei, we stipulate that we're talking about a
jump-into-the-pool Agile transition, with an existing team, that
already has a recognizable (though possibly ad-hoc) process. Time
enough for other situations some other season.

> Acquiring a new habit takes 60 days if you are alone.
> Since it's a team, the team can probably learn 2 or 3
> habits at a time, and probably in 1/4 of the time.

Sensei, whence cometh these numbers -- Brother Gladwell of the Ten
Thousand Hours? For they have the olfactory properties I have come to
associate with the Numerical Method of Rectal Extraction.

> Why do you want to change all their old habits at once?
> If you have a team of seniors who work since 20 years, do
> you think that they can change their habits in a few weeks?

Thus the call went out to me: "Help! Our Old Habits are causing us
pain! Bring us an Agile Process and we shall shovel lots of these
little portraits of former U.S. presidents in your direction!" Was I
wrong, master, to cast out *all* of the Old Habits, which caused such
pain to *someone* with budgetary authority? How am I to know which of
the Old Habits to let lie, which to roust, and which to start shaking
awake because I'm going to get rid of them next month?

And again, Sensei, I see your clever trap, but even the lowliest of
the novices weeding the garden where Object-Oriented Designs grow
could tell you that it is *they* who must change their habits. And I
do believe they have the power within themselves to change, because
let's face it, if you put a gun to their head, they'd bloody well do it.

> Since they cannot learn all the best practices at once, you have to
> concentrate on the most efficient practices for them (and every team
> is unique about these), and when one habit is acquired, you can
> encourage them to learn a new one.

Sensei, you keep saying "best practices," which is the kind of thing
I'd expect to hear from the Master in the Temple of the Heavyweight
Process, where the PMPs do bow and kneel to venerate their Holy
Diagrams with the Boxes and the Arrows, and pile one new Rule on top
of their Process each time they walk by it in the courtyard. Surely
we are discussing Agile practices, are we not?

If we are faced with an array of practices, how are we to tell which
are Most Efficient Practices? Is there a tattoo on the back of their
necks or something? Didn't I start this whole thing by strongly
implying that the Least Comfortable practices may be the ones to push
the strongest for?

> Personally, I strongly recommend starting with retrospectives,
> without forcing anything else. Perhaps they don't like your
> retrospectives. Is it a waste of time for them ?

Seven men drink from the same cask; six say the wine is sweet, and
call for more, but one calls it bitter. Isn't the problem obviously
with Drunk #7, and not the wine? The cask is the one that says
"Bad-Ass Mother----er", and it's where I keep my retrospectives.

And Sensei, just as we are taught that One Can Write COBOL in Any
Language, can one not turn any activity into a waste of time for
oneself by not listening, not contributing, and playing with one's
iPhone during such an activity?

> In a retrospective, you have to communicate in a team as follows:
> - if the team is new, focus on the tasks
> - once the tasks are clear for them, focus on the process
> - once the process is clear for them, focus on the human relations
> In my case, I directly focus on human relations, since their
> attitudes change almost instantly once there is openness.

Are none of your teams new, Old One? I will meditate upon your
Threefold Way of Retrospectives until our next session.

> Secondly, you need to realize what change is.
> Do you think that you can force change on somebody ?
> It's impossible, unless you believe that taming causes change.

Cf. the part about novice monks above, O Wise One. (Also, is "taming"
a mistranslation? I can't make sense of that sentence.)

> Do you think that you can change yourself ?

Once I change, I am no longer myself. And yet I am.

> I'll probably shock you, but you cannot change.
> Did you ever look at your own change process ?
> I did (I tried to change during 20 years), and believe me, I cannot
force it.
> Willpower and effort has nothing to do with change.

Mindfulness is the key to change.

> What is change ? Change is a mysterious process, and it just
> happens. Everybody is always changing, except that nobody notices
> his own change, because the change is incremental and too small to
> notice. But your change is visible when somebody outside of
> yourself checks every few weeks.

Ah, as when the Children go to the Abode of the Grandparents, and
partake of the ritual Marking of the Kids' Heights on the Wall, and
lo! they are much taller than just a couple months ago when they were
there for their cousin's baptism! And this although they themselves
never perceived the growth as it happened!

Sensei, when you say "Change is a mysterious process, and it just
happens," are you just quoting a bumper sticker or something? Because
a lot of us here at the Temple are specifically trying to figure out
things about Change and make it less mysterious, and I'm not sure that
particular teaching helps.

> Since change always happens and you cannot force it, how can you
> help a team change then ?

At long last, I sense that you are about to reveal to me the Key to
This Whole Coaching Thing! I eagerly await the words....

> Simply by accompanying people, by helping them confront their fears
> and by using a confident stance (after all you are the "expert").
> Find where there is fear, work on this fear (just make people look
> at their fear directly and it will disappear), and change will
> happen.

O Master, no offense, but I think a previous Teacher already covered
that, and it's a big chunk of what I do now: with planning, [TB]DD,
deployment: it's fear, fear, fear that's always in the way. In fact,
I just wrote "The feeling is always fear" someplace today, and added
not a little smiley-face, because I was half-serious.

> Change happens only when there is acceptance.

How am I to relate this Acceptance to the Stuff you said above, O Wise
One? Is Acceptance the Transcendence of Fear? The Recognition of
Fear? The Going Ahead and Doing Something in Spite of Fear? Is this
some sort of Test?

> So, now, I have a few questions for you:

> - what are the differences between coaching and mentoring ?

The Coach is always there, but the Mentor you check in with every week
or so, unless something big comes up that you need advice about.
The Mentor is teaching you how to become him, but the Coach is teaching
you how to be you.

> - what are the differences between coaching and leading ?

Leading is grabbing a group people by the heart and pulling them
forward. Moses was a leader. The guys showing the Israelites how to
get the cart wheels free of the Red Sea mud were Coaches.

A Coach helps you change what you do, or how you do it.
A Leader helps you change what you *want* to do.

> - what are the differences between coaching and bossing ?

Does not a Boss say to his Underling, "Do this, and do it thusly;
disobey and I shall cast thee into the Line of Unemployment!"
And does not a Coach endeavor to gain the same result by saying unto
his Teammates, "Hey, we said X was a goal for this Sprint, but we seem
to be impeded by Y. Let me show you how to overcome that. Plus, we
all agreed to do Z, so quit skipping it."

> - do you have children ? And why do you think I ask this question ?

(Since you do not endeavor to employ me:) Yea, I do indeed have children.
And I suspect you inquired so as to demand payment for your Wisdom in
the form of my Firstborn (since mathematically, one of them has to be
Firstborn), who will then become a novice in the Temple of Agile.

--George the Monk

[John Stoneham]

On Aug 13, 2013, at 9:39 PM, George Paci <gp...@tiac.net> wrote:

> Sensei, you keep saying "best practices," which is the kind of thing
> I'd expect to hear from the Master in the Temple of the Heavyweight
> Process, where the PMPs do bow and kneel to venerate their Holy
> Diagrams with the Boxes and the Arrows, and pile one new Rule on top
> of their Process each time they walk by it in the courtyard. Surely
> we are discussing Agile practices, are we not?

I'd like to make a motion that we require all further discourse on this list be conducted in this style. Do I hear a second?

- John

[Prashant Pathak]

I think the analogy of the suite and your body would not be the way I would look at it ..

My analogy would be a portly, slow moving body of a person = current team and its practices,  and Agile= Exercise routine.

Now, you may have big guys with decent muscles that can lift weights (read good programmers with experience etc .. ), but cardio is what they hate .. (read continuous integration and [TB]DD etc ..

I would, using the analogy above, stress upon them that adding the cardio will not only help them lose that extra weight, but also do their heart some good. Now, is it hard to jog at a constant pace for an extended amount of time? ... sure it is .. but look at the benefits !

Now I am probably not as experienced as many of the guys on this group are, but I have been a change leader in my past two companies(current one too) and have been able to mold a few teams and the management to see the benefits of a few changes.

my 0.02 cents anyways ..

Prashant

[Tim Ottinger]

I have trouble with this analogy only because I happily took to TDD but haven't as readily taken to exercise.

But then I think that might make it more apt. 

My reasons for not exercising are exactly the reasons that many people won't take to agile practices...

1) Too busy

2) Usually in a hurry

3) Hard to keep a long-term commitment due to flux in schedule

4) Physical issues (feet, etc) make it difficult

5) No good partner/coach to improve my form -- I learned after 50 years that I run flat-footed

6) It's not fun 

7) I don't have appropriate clothes/shoes

8) I feel rather exposed going out in public to do it, fear looking silly or lame

9) I'm old. 

Hmmmm.

[Mike Burrows]

There seem to be a few things going on with the tailoring analogy and the word has baggage. A lot depends I think on whether you look at things from the perspective of where you want to get to (a target state, a tailored process?), or from where you happen to be now. If you take the latter perspective it's easy to frame a change as an experiment. Make the experiment safe enough and the worst that can happen is that you learn something.

Back to the TDD example: could you introduce it as a safe-to-fail experiment? What would constitute "safe"? How short could a worthwhile experiment be? What results would you hope for? If it failed, how damaging would that be and how could you mitigate that? If it succeeds, what then?

Mike

--

Mike Burrows

m...@asplake.co.uk
http://positiveincline.com
http://twitter.com/asplake
+44 7785 236497

[George Paci]

Tim,

Sorry, you were nice, so you don't get a funny reply.

On 8/13/13 4:14 PM, Tim Ottinger wrote:
> Going for comfort is a metaphor sure.
>
> Let's go a different way.
>
> You walk into a workspace and find that people have been getting
> injured for years, and maybe a few deaths a year.
>

Then I walk right back out. I have dependents. I don't know if that
works with the analogy...

> People are proud of how badass it is to work there, and show of their
> scars and stumps.
>

Making a virtue of necessity. Their work environment is rough, which
means they're tough.

> Is their comfort and pride the things you want to address?
>

I'm not sure what answer you want here, but: Yes. First, I have to suck
it up and realize the bad crap in their workplace is now part of their
*identity*, which is the last thing most people can stand to change. It
may be necessary to substitute in a *new* identity, or piece of one;
direct opposition is likely to fail, but emphasizing something
orthogonal might work (e.g. "We make money!" over "We lose digits!").
I'd probably at least go look at Alec Baldwin's speech from _Glengarry
Glen Ross_ again[1].

> Or are you going to look at hazards and safety and risk?
>

Again, yes. (Wait, is that allowed, or was I supposed to pick one? I
think I have to do this part *before* the comfort and pride.)

(Look, this is a special case, because if someone is literally going to
*die*, I have a moral duty to stop that as directly as I can: not just
working with this group, but siccing OSHA on them, and riling up their
union, and even going to the press. But assuming away those options:)

Hazards are hazards. Find something they care about (and can admit to
caring about) that either gets them to eliminate hazards (best), or let
me find and eliminate them (suboptimal). Money might be a good one,
since nobody in a business minds admitting money as a motivation.

Some hazards are in the environment[2], and are easy to change: put a
safety buffer in yellow tape around the propane tanks so nobody even
comes close to driving a forklift into them; look into moving them
behind a wall. Other hazards are behavior, which is tougher: you need
to get people to ask "Clear?" before starting the stamping machine,
*every time*; that means they need to build up a habit, which means you
need them to want it. Or people keep coming in the side door, where
they almost get hit by forklifts zipping by that use that stretch as a
freeway: that's sticky because *both* behaviors should probably change.
Changing behavior probably requires a clear set of rules that applies
all the time, to everyone. If possible, the team should come up with
(and change) the rules; they might be able to build identity (or anyway
group membership) around it.

Safety is clearly sub-par at this workplace. Is it unsafe because the
workers don't value safety? Or do the workers not value safety because
safety is lacking (and they consider that fixed)? My guess is both.
Don't go check the list of accidents and causes; have some of *them* go
check the list of accidents and causes. Dave might be more bothered by
a bunch of other guys getting hurt than by his own injuries, or anyway
he may be able to think more rationally about it. Get them to figure
out the *costs* of the current situation (not just monetary). Get them
to find *one thing* to fix, and figure out how to fix it. Roll out the
fix. Repeat.

> Will it make them comfortable to have a safer place to work, or will
> it ruin the badassedness of the place?
>

Well, I'm not taking away any scars or reattaching any appendages, so
they can keep basking in badassitude for a good long while without
actually getting further maimed (I think). And the key to comfort is
avoiding discomfort, so once they've made some changes, they'll be back
to comfort with the new, reduced-injury work environment. Hopefully,
they can eventually go from
"We're badass" to
"We're badass and we make money" to
"We make money and we're badass" to
"We're badass because we make money" to
"We make money".
Or something like that.

> Let's try this one for a while.
>

I will ponder your questions, O Venerable Sage. (Oops: wrong email).

--George


[1] http://www.youtube.com/watch?v=8kZg_ALxEz0 -- also,
https://www.youtube.com/watch?v=jQ1TjWbGn_4

[2] This is reminiscent of Donald Norman's knowledge-in-the-environment
vs. knowledge-in-the-head in his book _The Design of Everyday Things_.

[Jean-Charles Meyrignac]

Hi George,

Sorry for the late reply, but I originally didn't want to spend 2 hours to reply, but here is my reply anyway.

First, thank you for calling me Sensei, but I'm no sensei, I'm a total newbie, and my only redeeming feature is my introspection's obsession.
Luckily, not everybody is like me.

I'm very happy to see that you are an expert, so let me call you "Master" and let me be your disciple.

I have to say that I felt a few things when reading your first mail, so that's why I asked a few dumb questions (I'm sorry if you found them too dumb).

Master, what I felt from your first mail is:

1) you believe that a generic method (I call that an algorithm) exists for coaching a team.

2) as an agile coach, you seem to believe that "push" is superior to "pull", which seems contradictory for me

1) No, Sensei: I specifically want to pick a set of practices that

will be as useful to this team in the short term as possible.  Close
to the optimum set is fine.

Master, why do you believe that such an algorithm exists ?

If you coach several teams, you may have noticed that they are totally different individuals.

Why do you believe that an unique optimal way works for everybody ?

 

> Acquiring a new habit takes 60 days if you are alone.
> Since it's a team, the team can probably learn 2 or 3
> habits at a time, and probably in 1/4 of the time.

Sensei, whence cometh these numbers -- Brother Gladwell of the Ten
Thousand Hours?  For they have the olfactory properties I have come to
associate with the Numerical Method of Rectal Extraction.

Master, I don't pull these numbers out of my ass.
It's a recent research in psychology:
http://www.spring.org.uk/2009/09/how-long-to-form-a-habit.php

Of course, I extrapolated to a team, since there is an emulation in a team, so you can consider this extrapolation as a rectal extraction.

You should also take Zeigarnik's effect into account, that is: trying to do several things (for example, habits) at the same time increases stress.

 

And I do believe they have the power within themselves to change, because
let's face it, if you put a gun to their head, they'd bloody well do it.

Not necessarily, I saw groups where this didn't work (in general, self-organizing and mature groups hate this behaviour).

Also, I live in France, and we can't freely use guns here.

If we are faced with an array of practices, how are we to tell which
are Most Efficient Practices?  Is there a tattoo on the back of their

necks or something?  Didn't I start this whole thiit'ay be the ones to push
the strongest for?

Personallly, I find TDD very uncomfortable, so I very well understand their concerns.

Master, I would dare to suggest that you are probably forcing them to do TDD, instead of them consciously embrace this practice.

Could I suggest you a way to change this ?

During one iteration, tell them that they don't need to do any TDD at all !
And during the next iterations, keep a list of the bugs that could be avoided.

Facilitate one retrospective only talking about bugs and TDD after that, do not intervene, just let them realize (I call that "Aha !") without using guilt.

Master, in my humble opinion, I believe that the most important practices are:

1) retrospectives (especially openness in relations)

2) pair review

3) automated tests (in whatever form it is, TDD is preferred but not always enforceable)

My motto is:

 First, quality in the relations

 Second, quality in the process

 Third, quality in the work
 

> Secondly, you need to realize what change is.
> Do you think that you can force change on somebody ?
> It's impossible, unless you believe that taming causes change.

Cf. the part about novice monks above, O Wise One.  (Also, is "taming"
a mistranslation?  I can't make sense of that sentence.)

Master, taming is similar to "dog-training".

I believe that if you take a team and learn them how to sit, stand and lie, you get people that sit, stand and lie, but take no initiative.

The only initiative they take is to stop sitting, standing and lying as soon as you are not behind them.

Of course, as you notice their slacking, you can proudly claim that you are absolutely necessary to this team (this means more money for you, so it's a win-win).

 

> Do you think that you can change yourself ?

Once I change, I am no longer myself.  And yet I am.

Master, what a deep thought, but now I'm quite lost: who am I then ?

 

> I'll probably shock you, but you cannot change.
> Did you ever look at your own change process ?
> I did (I tried to change during 20 years), and believe me, I cannot force it.
> Willpower and effort has nothing to do with change.

Mindfulness is the key to change.

Master, I wholeheartedly agree.
But what does mindfulness mean ?

 

Sensei, when you say "Change is a mysterious process, and it just
happens," are you just quoting a bumper sticker or something?  Because
a lot of us here at the Temple are specifically trying to figure out
things about Change and make it less mysterious, and I'm not sure that
particular teaching helps.

Master, why do you believe that it can be understood intellectually ?

A lot of brilliant minds have worked on it, and even though neuroscience is working on it, change is still mysterious.

 

> Since change always happens and you cannot force it, how can you
> help a team change then ?

At long last, I sense that you are about to reveal to me the Key to
This Whole Coaching Thing!  I eagerly await the words....

Nope, I have no idea, sorry.

 

O Master, no offense, but I think a previous Teacher already covered
that, and it's a big chunk of what I do now: with planning, [TB]DD,
deployment: it's fear, fear, fear that's always in the way.  In fact,
I just wrote "The feeling is always fear" someplace today, and added
not a little smiley-face, because I was half-serious.

In fact, master, I was wrong. Tim used the term Pride, and it's much more about pride than fear.

I'm myself guilty of pride, because I worked 18 years in videogames, and enjoyed so much my miserable life at this time (I was so proud of the death marches, especially about surviving them, I was a veteran warrior at this time).

How can I become agile when the pride of my glorious past gets in the way ?

> Change happens only when there is acceptance.

How am I to relate this Acceptance to the Stuff you said above, O Wise
One?  Is Acceptance the Transcendence of Fear?  The Recognition of
Fear?  The Going Ahead and Doing Something in Spite of Fear? Is this
some sort of Test?

Master, acceptance means that you have to accept without guilt whatever happens (it's difficult because it's mostly shit and problems), and the only control that you have is into doing whatever small things you can do, keeping the hope that the future will be better (though it mostly won't be the case).

And no, I don't believe in God.

> So, now, I have a few questions for you:

>  - what are the differences between coaching and mentoring ?

The Coach is always there, but the Mentor you check in with every week
or so, unless something big comes up that you need advice about.
The Mentor is teaching you how to become him, but the Coach is teaching
you how to be you.

That's really an excellent answer !

Thank you, I asked that, since I really didn't know (I'm not kidding here).

 

>  - what are the differences between coaching and leading ?

Leading is grabbing a group people by the heart and pulling them
forward.  Moses was a leader.  The guys showing the Israelites how to
get the cart wheels free of the Red Sea mud were Coaches.

A Coach helps you change what you do, or how you do it.
A Leader helps you change what you *want* to do.

Master, I would have given a more passive answer: a coach helps you reflect on your behavior (I'm not even sure a coach should suggest "how to do"), hoping there will be some enlightment in the mind of his disciples, I mean the team's members.

From what I read, when a coachee needs help, the coach enumerates several ways, so that the coachee realizes that there is not a single solution, and that he should find the most suitable solution for him.

 

>  - what are the differences between coaching and bossing ?

Does not a Boss say to his Underling, "Do this, and do it thusly;
disobey and I shall cast thee into the Line of Unemployment!"
And does not a Coach endeavor to gain the same result by saying unto
his Teammates, "Hey, we said X was a goal for this Sprint, but we seem
to be impeded by Y.  Let me show you how to overcome that.  Plus, we
all agreed to do Z, so quit skipping it."

Master, I'm not sure about the very last part: "so quit skipping it".

I believe that this is the role of a Scrummaster, not of a coach.

A coach works onto removing people's limitations, since these limitations are the impediments.

In an agile team, the impediments are task-related, process-related and relations-related (and I think the focus of a coach is mostly onto relations).

Perhaps the goal of a coach is to only tell:

I know that you are not slackers (even if in fact, they are), so how can we be even more efficient ?

I'm seeing the coach as a motivator, instead of a supervisor, perhaps I'm biased.

 

>  - do you have children ? And why do you think I ask this question ?

(Since you do not endeavor to employ me:) Yea, I do indeed have children.
And I suspect you inquired so as to demand payment for your Wisdom in
the form of my Firstborn (since mathematically, one of them has to be
Firstborn), who will then become a novice in the Temple of Agile.

Almost, in fact it was to describe the different coaching styles:

1) for your firstborn, you have a lot of expectations. Perhaps you secretly hope that he'll succeed where you failed. You attach much importance on what he'll do and how, and you follow his progress tightly.

2) for your second-born, you have less expectations. You hope that he'll succeed, but you don't push him very hard, as long as you verify that he's on the right path.

3) for your third-born, you have no expectations. You hope that he'll be happy, and whatever he'll do, that he won't fail too much. You are always here if he needs help.

I think that these are the 3 major styles of coaching.

(I'm a first-born, so life has been tough for me)

And finally, master, please excuse me, but I think that you should be gentler with yourself and with others.

You can humiliate me as much as you want, since I'm your disciple and it doesn't bother me at all, but why do you force yourself so much ?

With all my sincere respects,
Your lowly disciple,
Jean-Charles

[Tim Ottinger]

TL;DR

Anyone want to summarize? 

--
You received this message because you are subscribed to the Google Groups "Agile Coaching Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-coaching-su...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.