RE: Re: Do C-Level managers, and business drivers really need to know about XP?

"Steve Ropa" <[email protected]> Tue, 11 Feb 2003 08:48:50 -0700
Newsgroups gmane.comp.programming.extreme-programming.adoption
Message-ID <[email protected]>
Hi Dale,

> -----Original Message-----
> From: Dale Emery [mailto:[email protected]]
> Sent: Monday, February 10, 2003 5:35 PM
> To: [email protected]
> Subject: Re: [xpAdoption] Re: Do C-Level managers, and 
> business drivers
> really need to know about XP?
> 
> 
> Hi Steve,
> 
>  > I started by putting up a list of opportunities and asking
>  > people to sign up for work.  I did it in "unattended mode" and
>  > came back to find a lot of blank stares and nothing signed up
>  > for...so I then went back to the more old fashioned way of
>  > finding someone who is available, then discussing the project
>  > with them.
> 
> One test of whether you're truly empowering (in a specific 
> situation) is how you react if you don't get the result you were 
> hoping for.  If you react by asserting control, then there's a 
> good chance you were not empowering, but abdicating.  (I'm not 
> saying that you were abdicating here.)
> 
Actually, in this case, they asked me to assert more control.  I was more than ready to go back out of the room and have them try again, or to walk through the process of signing up together.

> I think of three fundamental management questions:
>      - What results do we want?
>      - How will we achieve the results?
>      - What results are we achieving?
> 
I am going to put that up on my whiteboard.

> The team needs to answer each of these questions over and over, 
> at various levels of specificity.  A key meta-question is: Who 
> gets to answer each question?
> 
> In the situation you describe, you answered the first question 
> yourself (what results do we want?): Sign up for the work.  Seems 
> like a directive thing to do, and perhaps an appropriate thing 
> for you to direct.  Is that asserting "too much" control?  I 
> dunno.  What do you think?  What did your team think?

> 
> You left the other questions to the team, and the team didn't 
> know how to answer them, or feared they might do it "wrong," or 
> something.  How can you empower a team who does not know how to 
> achieve the results, or who do not know how to tell what results 
> they are achieving?
Well, my story was a little long, so I left out some details.  I did discuss how we were answering the questions.  In this case, I really feel that I was asking them to answer a question that they didn't want to answer.  The feedback really was "we don't want to sign up for the work.  We want you to assign it."


> 
>  > My definition of success was that they enjoyed what they were
>  > doing, did it the best they could, and grew in the process.
> 
> These is similar to my conditions for success.  I usually include 
> one more:  The customers are happy with the results.
> 
Its a good one.  Usually that one follows naturallyfrom the first three.

>  > Therein lies my dilemna.  How do you strike the right balance?
>  > Is it entirely determined by the team?  They want high command
>  > and control, because that is their current comfort zone.  I am
>  > not particularly comfortable running a development shop like a
>  > military department.  Should I have rigidly defined areas of
>  > doubt and uncertainty?
> 
> Empowering doesn't have to be all-or-nothing.  I often use a tool 
> I invented called The Ladder of Delegation.  I think of a task as 
> involving a number of questions and an action:
> 
>      What result do we want?
>      How will we know we're done?
>      How might we achieve the result?
>      Which approach will we choose?
>      How will we know we're making progress?
>      Do it.
>      Are we making progress?
>      Are we done?
> 
> I order these as a "ladder."  The bottom rung of the ladder is 
> the step I'll most readily allow someone else to do.  The top 
> rung is the step I'm most reluctant to give up.  For most tasks, 
> and for most people to whom I might delegate, my ladder looks 
> like this:
> 
>      (Hardest to delegate) What result do we want?
>      How will we know we're done?
>      Are we done?
>      Which approach will we choose?
>      How might we achieve the result?
>      How will we know we're making progress?
>      Are we making progress?
>      (Easiest to delegate) Do it.
> 
> You might include different rungs in your ladder, or you might 
> order them differently.  The key is to see that you don't have to 
> jump all the way to the top.  You can take it one step at a time, 
> depending on what each of your teammates is prepared to take on, 
> and what you are prepared to trust each to take on.  What would 
> have to happen for me to take one more step up the ladder (for 
> this task, for this person)?  Under what conditions might I take 
> a step down the ladder?
> 
> I'm seeing that the ladder may be useful not just for me (and my 
> trust), but also for people on the team.  What would have to 
> happen for this person to be willing to take one step up the ladder?
> 
> Dale
> 
Very, very nice.

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/LIgTpC/vN2EAA/xGHJAA/nhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/