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/