Loading ...
Sorry, an error occurred while loading the content.
 

Selling Management on XP

Expand Messages
  • James Carr
    Hi, The place where I am currently employed had zero planning/development processes in place, and several of my first projects went way overdue (there is even
    Message 1 of 14 , Apr 27, 2005
      Hi,

      The place where I am currently employed had zero planning/development
      processes in place, and several of my first projects went way overdue
      (there is even a horrible Death March project lurching forward
      defiantly, 500 hours overquote, but that's another story). I've read a
      majority of books on RUP, XP, and SCRUM, and feel we should implement
      all the good stuff I've read.

      However, a problem arises. They don't want me working on it until
      paid work is done, and there's a steady stream of paid work! Also,
      management doesn't like any of the "unorthodox" ideas I presented,
      such as pair programming (the assuption being made was that one
      programmer would be wasting time that could be spent working on
      something).

      Any suggestions on selling management on XP? Or should I just throw
      my hands up and pray for a new job soon? ;)

      Thanks,
      JC
    • William Pietri
      ... I think your diagnosis of the problem is good. But What do they see as the biggest problem? William
      Message 2 of 14 , Apr 27, 2005
        On Wed, 2005-04-27 at 17:56, James Carr wrote:
        > Any suggestions on selling management on XP? Or should I just throw
        > my hands up and pray for a new job soon? ;)

        I think your diagnosis of the problem is good. But What do they see as
        the biggest problem?

        William
      • banshee858
        ... Depends on how tolerant you are to stress. Also ask yourself this question: Do they want improvement or change? . Here is something I picked up from Kent
        Message 3 of 14 , Apr 27, 2005
          >
          > Any suggestions on selling management on XP? Or should I just throw
          > my hands up and pray for a new job soon? ;)
          >
          Depends on how tolerant you are to stress. Also ask yourself this
          question: "Do they want improvement or change?".

          Here is something I picked up from Kent Beck just a short while ago
          and saved it:

          "In the interest of preserving your Enya collection, here's my
          take--what an XP team offers is accountability to your
          appropriately-skeptical VP. The team will say what they intend to do
          and then will say exactly what they did. It offers fewer surprises,
          both the gross kind like, "I know last week we said we were one week
          from being done but actually it'll be more like four to six months"
          and the integrity-related surprises, "I know we said we would have a
          testing phase but we just don't have time--you'll have to
          manage the customers when they hit a raft of defects." It offers
          responsibility. The team will own their results without making
          excuses. If things don't go well, they will report the current state
          and then focus on what can be done next. It offers flexibility. If the
          market for the software changes suddenly, the team can adapt instantly
          and maintain morale at the same time."

          "XP offers measurable results--dramatically fewer defects; gradually
          reducing overhead (your Process Efficiency); higher productivity;
          higher morale; more frequent feedback in the form of deployable
          software with measurable properties like number of tests, complexity,
          and coverage. If applying XP doesn't achieve these in visible,
          measureable ways in a matter of months, XP has failed in your
          organization."

          "There are aspects of XP that are hard to measure; like confidence,
          peace of mind, justified pride in work well done, joy at both coming
          to work and leaving at the end of the day, creativity, level of
          tension in the workspace, rapport. For the VP those can be pleasant
          surprises to discover later. What you can promise up front are higher
          levels of productivity, accountability, flexibility, honesty and
          predictability and lower levels of defects, schedule slips, valueless
          features, wasted effort, cost and surprises. This is often enough to
          warrant an experiment in XP."

          Carlton
        • Adam Wildavsky
          ... You ll probably want to join the Selling Agile group and peruse its archives: http://groups.yahoo.com/group/sellingagile/ -- Adam Wildavsky
          Message 4 of 14 , May 1, 2005
            At 12:56 AM +0000 4/28/05, James Carr wrote:
            >Any suggestions on selling management on XP? Or should I just throw
            >my hands up and pray for a new job soon? ;)

            You'll probably want to join the "Selling Agile" group and peruse its archives:

            http://groups.yahoo.com/group/sellingagile/

            --
            Adam Wildavsky adam@... http://www.tameware.com
          • Kent Beck
            JC, It can be difficult to figure out the motivations of someone with different perspectives and values from your own. However, since you are working for the
            Message 5 of 14 , May 5, 2005
              JC,

              It can be difficult to figure out the motivations of someone with different
              perspectives and values from your own. However, since you are working for
              the same company you have some goals in common (however difficult it is to
              see that some times). Build relationships with managers. Understand what
              they want. Figure out how to use XP to give them what they want (assuming XP
              is appropriate). If you do that you'll have support. If you use XP to give
              managers things they don't want, you'll have resistance.

              Kent Beck
              Three Rivers Institute

              > -----Original Message-----
              > From: extremeprogramming@yahoogroups.com
              > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of James Carr
              > Sent: Wednesday, April 27, 2005 5:57 PM
              > To: extremeprogramming@yahoogroups.com
              > Subject: [XP] Selling Management on XP
              >
              >
              > Hi,
              >
              > The place where I am currently employed had zero planning/development
              > processes in place, and several of my first projects went way overdue
              > (there is even a horrible Death March project lurching forward
              > defiantly, 500 hours overquote, but that's another story). I've read a
              > majority of books on RUP, XP, and SCRUM, and feel we should implement
              > all the good stuff I've read.
              >
              > However, a problem arises. They don't want me working on it until
              > paid work is done, and there's a steady stream of paid work! Also,
              > management doesn't like any of the "unorthodox" ideas I presented,
              > such as pair programming (the assuption being made was that one
              > programmer would be wasting time that could be spent working on
              > something).
              >
              > Any suggestions on selling management on XP? Or should I just throw
              > my hands up and pray for a new job soon? ;)
              >
              > Thanks,
              > JC
              >
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to:
              > extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.com
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
              >
              >
              >
            • Willem Bogaerts
              ... Isn t that the problem? What managers want is security. They want to know everything beforehand. Otherwise, they might have the feeling they can t
              Message 6 of 14 , May 6, 2005
                Kent Beck wrote:
                > It can be difficult to figure out the motivations of someone with different
                > perspectives and values from your own. However, since you are working for
                > the same company you have some goals in common (however difficult it is to
                > see that some times). Build relationships with managers. Understand what
                > they want. Figure out how to use XP to give them what they want (assuming XP
                > is appropriate). If you do that you'll have support. If you use XP to give
                > managers things they don't want, you'll have resistance.

                Isn't that the problem? What managers want is security. They want to
                know everything beforehand. Otherwise, they might have the feeling they
                "can't manage". Even with not fully specified customer requests, they
                want to know how much time it takes to implement them.

                One line of thought I had lately, was to play the devil's advocate
                towards never-ending projects: If you have experienced your projects to
                be never-ending, why not use that knowledge and treat them as such?
                Off course, that would mean you would:
                - switch to a different pricing (no fixed contracts anymore)
                - keep delivering (otherwise no client would want the project)
                - keep the client involved, as you know he will give feedback.
                - keep the codebase understandable at all times
                - etc.
                This would imply that a never-ending projects may _not_ be at all bad,
                quite manageable, and be agile almost automatically. And, as an extra
                option, you can end them whenever you like.

                Alas, this line of thought of me was so recent that I could not try it
                on a "fresh" manager yet.

                Best regards,
                Willem Bogaerts
              • Larry Brunelle
                I have had (and maybe even posted) such thoughts before, but you have cast them better. Suppose for a moment we did as you suggest, but also stopped calling it
                Message 7 of 14 , May 6, 2005
                  I have had (and maybe even posted) such thoughts before,
                  but you have cast them better.

                  Suppose for a moment we did as you suggest, but also
                  stopped calling it a "project" as opposed to, say, an
                  "activity" or even "our regular business"?

                  If software development is our regular business, then
                  it is the processing of requests or needs - similar
                  to other ongoing business activities:
                  o accounts payable, processing invoices
                  o IT, processing user access requests, machine
                  maintenance, etc.
                  o vehicle maintenance, processing scheduled maintenance
                  and unscheduled repair

                  All of these activities have some amount of unpredictable
                  work. All may have occasional projects, but "project" is
                  not the normal form of work. Something unpredictable
                  occurs, and there is not a deadline so much as "ASAP",
                  and communication of downtime expected in consequence
                  is more important than accurate cost prediction.

                  Thing is, that description often better models the
                  reality of software development than the typical
                  project model. Seems to me that there is some minimum
                  that is takes to get something done, and that's as
                  long as it takes - not some predicted value.


                  Willem Bogaerts wrote:
                  > Kent Beck wrote:
                  >
                  >>It can be difficult to figure out the motivations of someone with different
                  >>perspectives and values from your own. However, since you are working for
                  >>the same company you have some goals in common (however difficult it is to
                  >>see that some times). Build relationships with managers. Understand what
                  >>they want. Figure out how to use XP to give them what they want (assuming XP
                  >>is appropriate). If you do that you'll have support. If you use XP to give
                  >>managers things they don't want, you'll have resistance.
                  >
                  >
                  > Isn't that the problem? What managers want is security. They want to
                  > know everything beforehand. Otherwise, they might have the feeling they
                  > "can't manage". Even with not fully specified customer requests, they
                  > want to know how much time it takes to implement them.
                  >
                  > One line of thought I had lately, was to play the devil's advocate
                  > towards never-ending projects: If you have experienced your projects to
                  > be never-ending, why not use that knowledge and treat them as such?
                  > Off course, that would mean you would:
                  > - switch to a different pricing (no fixed contracts anymore)
                  > - keep delivering (otherwise no client would want the project)
                  > - keep the client involved, as you know he will give feedback.
                  > - keep the codebase understandable at all times
                  > - etc.
                  > This would imply that a never-ending projects may _not_ be at all bad,
                  > quite manageable, and be agile almost automatically. And, as an extra
                  > option, you can end them whenever you like.
                  >
                  > Alas, this line of thought of me was so recent that I could not try it
                  > on a "fresh" manager yet.
                  >
                  > Best regards,
                  > Willem Bogaerts
                • James Carr
                  I think the biggest problem has been pair programming. How can I convince management this is a good idea and not wasted time? Thanks, JC
                  Message 8 of 14 , May 6, 2005
                    I think the biggest problem has been pair programming. How can I
                    convince management this is a good idea and not wasted time?

                    Thanks,
                    JC

                    On 5/6/05, Larry Brunelle <brunelle@...> wrote:
                    > I have had (and maybe even posted) such thoughts before,
                    > but you have cast them better.
                    >
                    > Suppose for a moment we did as you suggest, but also
                    > stopped calling it a "project" as opposed to, say, an
                    > "activity" or even "our regular business"?
                    >
                    > If software development is our regular business, then
                    > it is the processing of requests or needs - similar
                    > to other ongoing business activities:
                    > o accounts payable, processing invoices
                    > o IT, processing user access requests, machine
                    > maintenance, etc.
                    > o vehicle maintenance, processing scheduled maintenance
                    > and unscheduled repair
                    >
                    > All of these activities have some amount of unpredictable
                    > work. All may have occasional projects, but "project" is
                    > not the normal form of work. Something unpredictable
                    > occurs, and there is not a deadline so much as "ASAP",
                    > and communication of downtime expected in consequence
                    > is more important than accurate cost prediction.
                    >
                    > Thing is, that description often better models the
                    > reality of software development than the typical
                    > project model. Seems to me that there is some minimum
                    > that is takes to get something done, and that's as
                    > long as it takes - not some predicted value.
                    >
                    >
                    > Willem Bogaerts wrote:
                    > > Kent Beck wrote:
                    > >
                    > >>It can be difficult to figure out the motivations of someone with different
                    > >>perspectives and values from your own. However, since you are working for
                    > >>the same company you have some goals in common (however difficult it is to
                    > >>see that some times). Build relationships with managers. Understand what
                    > >>they want. Figure out how to use XP to give them what they want (assuming XP
                    > >>is appropriate). If you do that you'll have support. If you use XP to give
                    > >>managers things they don't want, you'll have resistance.
                    > >
                    > >
                    > > Isn't that the problem? What managers want is security. They want to
                    > > know everything beforehand. Otherwise, they might have the feeling they
                    > > "can't manage". Even with not fully specified customer requests, they
                    > > want to know how much time it takes to implement them.
                    > >
                    > > One line of thought I had lately, was to play the devil's advocate
                    > > towards never-ending projects: If you have experienced your projects to
                    > > be never-ending, why not use that knowledge and treat them as such?
                    > > Off course, that would mean you would:
                    > > - switch to a different pricing (no fixed contracts anymore)
                    > > - keep delivering (otherwise no client would want the project)
                    > > - keep the client involved, as you know he will give feedback.
                    > > - keep the codebase understandable at all times
                    > > - etc.
                    > > This would imply that a never-ending projects may _not_ be at all bad,
                    > > quite manageable, and be agile almost automatically. And, as an extra
                    > > option, you can end them whenever you like.
                    > >
                    > > Alas, this line of thought of me was so recent that I could not try it
                    > > on a "fresh" manager yet.
                    > >
                    > > Best regards,
                    > > Willem Bogaerts
                    >
                    > To Post a message, send it to: extremeprogramming@...
                    >
                    > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                    >
                    > ad-free courtesy of objectmentor.com
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                    >
                  • Tony Byrne
                    Hello James, Friday, May 6, 2005, 1:33:49 PM, you wrote: JC I think the biggest problem has been pair programming. How can I JC convince management this is a
                    Message 9 of 14 , May 6, 2005
                      Hello James,

                      Friday, May 6, 2005, 1:33:49 PM, you wrote:

                      JC> I think the biggest problem has been pair programming. How can I
                      JC> convince management this is a good idea and not wasted time?

                      You can point them in the direction of, or distill for them,
                      some of the usual studies and papers:

                      http://alistair.cockburn.us/crystal/articles/ppcb/pairprogrammingcostbene.html
                      http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF
                      http://www.ipd.uka.de/mitarbeiter/muellerm/publications/metrics03.pdf

                      You may need to make the case for Pair Programming by focusing on
                      things that management really care about. While Pair Programming brings
                      benefits for developers that are also beneficial to the company, (e.g.
                      increased job satisfaction), it has been my experience(*) that it is
                      difficult to make a compelling case for Pair Programming on those terms.

                      * From a sample set of one team.

                      Regards,

                      Tony.

                      --
                      Tony Byrne
                    • Michael Dubakov
                      ... One possible way is to conduct a pilot project. Thus top management will see benefits (if any). But good XP coach required in this case. Michael Agile Blog
                      Message 10 of 14 , May 6, 2005
                        > I think the biggest problem has been pair programming. How can I
                        > convince management this is a good idea and not wasted time?

                        One possible way is to conduct a pilot project.
                        Thus top management will see benefits (if any).
                        But good XP coach required in this case.

                        Michael
                        Agile Blog
                        http://www.targetprocess.com/blog
                      • Tony Byrne
                        Hello Michael, ... MD One possible way is to conduct a pilot project. MD Thus top management will see benefits (if any). MD But good XP coach required in
                        Message 11 of 14 , May 6, 2005
                          Hello Michael,

                          Friday, May 6, 2005, 3:00:20 PM, you wrote:

                          >> I think the biggest problem has been pair programming. How can I
                          >> convince management this is a good idea and not wasted time?

                          MD> One possible way is to conduct a pilot project.
                          MD> Thus top management will see benefits (if any).
                          MD> But good XP coach required in this case.

                          It probably goes without saying, but one should factor in enough
                          time to allow the team to learn the necessary pairing skills and
                          become effective at pairing, before making a judgement. I'm sure an
                          experienced coach would manage the situation on the ground, but for
                          anyone trying this at home, I urge caution.

                          Regards,

                          Tony.

                          --
                          Tony Byrne
                        • banshee858
                          ... Pair programming. The hardest thing to sell about XP. I find this interesting since I would have figured iteratice planning is more disruptive to
                          Message 12 of 14 , May 6, 2005
                            >
                            > I think the biggest problem has been pair programming. How can I
                            > convince management this is a good idea and not wasted time?
                            >
                            Pair programming. The "hardest" thing to sell about XP. I find this
                            interesting since I would have figured iteratice planning is more
                            disruptive to current management practices than pair programming or
                            perhaps the finding an on-site customer to cause more grief.

                            One big risk that many projects face is the famous issue of the "bus
                            number". Pair programming allows you to raise the "bus number" and
                            reduce the risk for the organization. If management is not concerned
                            about key technical staff moving on, then they are not in tune with
                            the current job market.

                            Carlton
                          • Kent Beck
                            Willem, I hear you saying that in your opinion managers want security, predictability, comfort, and that they expect programmers to provide them with security,
                            Message 13 of 14 , May 7, 2005
                              Willem,

                              I hear you saying that in your opinion managers want security,
                              predictability, comfort, and that they expect programmers to provide them
                              with security, predictability, and comfort. That is not my experience with
                              managers. No manager I have ever met relied on programmers for security.
                              Different managers want different things. Hence my recommendation that the
                              OP try to listen carefully to the actual managers involved.

                              I agree that never-ending projects are a more realistic model than projects
                              with a definite end date. Turning the thinking around further, the team's
                              goal would be to create a software system that offered an endless stream of
                              attractive investment opportunities. If the cruft built up and costs rose,
                              that would discourage further investment.

                              Why wait for a "fresh" manager? Could you discuss this idea with a manager
                              you are already acquainted with? I'd like to hear the results of the
                              conversation.

                              Kent Beck
                              Three Rivers Institute

                              > -----Original Message-----
                              > From: extremeprogramming@yahoogroups.com
                              > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
                              > Willem Bogaerts
                              > Sent: Friday, May 06, 2005 3:08 AM
                              > To: extremeprogramming@yahoogroups.com
                              > Subject: Re: [XP] Selling Management on XP
                              >
                              > Isn't that the problem? What managers want is security. They want to
                              > know everything beforehand. Otherwise, they might have the
                              > feeling they
                              > "can't manage". Even with not fully specified customer requests, they
                              > want to know how much time it takes to implement them.
                              >
                              > One line of thought I had lately, was to play the devil's advocate
                              > towards never-ending projects: If you have experienced your
                              > projects to
                              > be never-ending, why not use that knowledge and treat them as such?
                              > Off course, that would mean you would:
                              > - switch to a different pricing (no fixed contracts anymore)
                              > - keep delivering (otherwise no client would want the project)
                              > - keep the client involved, as you know he will give feedback.
                              > - keep the codebase understandable at all times
                              > - etc.
                              > This would imply that a never-ending projects may _not_ be at
                              > all bad,
                              > quite manageable, and be agile almost automatically. And, as an extra
                              > option, you can end them whenever you like.
                              >
                              > Alas, this line of thought of me was so recent that I could
                              > not try it
                              > on a "fresh" manager yet.
                              >
                              > Best regards,
                              > Willem Bogaerts
                              >
                              >
                              > To Post a message, send it to: extremeprogramming@...
                              >
                              > To Unsubscribe, send a blank message to:
                              > extremeprogramming-unsubscribe@...
                              >
                              > ad-free courtesy of objectmentor.com
                              > Yahoo! Groups Links
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                            • Dakshinamurthy Karra
                              JC, These are some suggestions from my experience. YMMW. 1. Do not start with sustained pace, energised work or 40-hour week - whatever you call it. This
                              Message 14 of 14 , May 8, 2005
                                JC,

                                These are some suggestions from my experience. YMMW.

                                1. Do not start with sustained pace, energised work or 40-hour week -
                                whatever you call it. This generates friction among teams for a newly
                                formed XP team.
                                2. Do not worry about pairing all the time. You can start small. I
                                have seen a team that started pairing only for bug-fixes and tough
                                tasks. Over a period of time the manager could see the benefits and
                                the team moved to full time pairing.
                                3. Talk in terms of numbers. Decide and collect metrics (the bugs
                                reported is a good one) and use a XP practice to solve one problem at
                                a time. Most importantly, publish the metrics where everyone can see.
                                4. Start of with standup meetings ASAP. Try to pull-in the project
                                owner to these meetings.
                                5. See whether TDD can be implemented in the environment. If it is
                                possible, this is one practice that is very effective.
                                6. Do not try to bring in any practice by stealth. The disadvantages
                                far out-weigh the advantages for such an approach.

                                Finally, Planning XP is a good book and can give plenty of ideas
                                suitable for your environment.

                                HTH.

                                Thanks and Regards
                                KD


                                On 5/6/05, James Carr <james.r.carr@...> wrote:
                                > I think the biggest problem has been pair programming. How can I
                                > convince management this is a good idea and not wasted time?
                                >
                                > Thanks,
                                > JC
                                >
                                > On 5/6/05, Larry Brunelle <brunelle@...> wrote:
                                > > I have had (and maybe even posted) such thoughts before,
                                > > but you have cast them better.
                                > >
                                > > Suppose for a moment we did as you suggest, but also
                                > > stopped calling it a "project" as opposed to, say, an
                                > > "activity" or even "our regular business"?
                                > >
                                > > If software development is our regular business, then
                                > > it is the processing of requests or needs - similar
                                > > to other ongoing business activities:
                                > > o accounts payable, processing invoices
                                > > o IT, processing user access requests, machine
                                > > maintenance, etc.
                                > > o vehicle maintenance, processing scheduled maintenance
                                > > and unscheduled repair
                                > >
                                > > All of these activities have some amount of unpredictable
                                > > work. All may have occasional projects, but "project" is
                                > > not the normal form of work. Something unpredictable
                                > > occurs, and there is not a deadline so much as "ASAP",
                                > > and communication of downtime expected in consequence
                                > > is more important than accurate cost prediction.
                                > >
                                > > Thing is, that description often better models the
                                > > reality of software development than the typical
                                > > project model. Seems to me that there is some minimum
                                > > that is takes to get something done, and that's as
                                > > long as it takes - not some predicted value.
                                > >
                                > >
                                > > Willem Bogaerts wrote:
                                > > > Kent Beck wrote:
                                > > >
                                > > >>It can be difficult to figure out the motivations of someone with different
                                > > >>perspectives and values from your own. However, since you are working for
                                > > >>the same company you have some goals in common (however difficult it is to
                                > > >>see that some times). Build relationships with managers. Understand what
                                > > >>they want. Figure out how to use XP to give them what they want (assuming XP
                                > > >>is appropriate). If you do that you'll have support. If you use XP to give
                                > > >>managers things they don't want, you'll have resistance.
                                > > >
                                > > >
                                > > > Isn't that the problem? What managers want is security. They want to
                                > > > know everything beforehand. Otherwise, they might have the feeling they
                                > > > "can't manage". Even with not fully specified customer requests, they
                                > > > want to know how much time it takes to implement them.
                                > > >
                                > > > One line of thought I had lately, was to play the devil's advocate
                                > > > towards never-ending projects: If you have experienced your projects to
                                > > > be never-ending, why not use that knowledge and treat them as such?
                                > > > Off course, that would mean you would:
                                > > > - switch to a different pricing (no fixed contracts anymore)
                                > > > - keep delivering (otherwise no client would want the project)
                                > > > - keep the client involved, as you know he will give feedback.
                                > > > - keep the codebase understandable at all times
                                > > > - etc.
                                > > > This would imply that a never-ending projects may _not_ be at all bad,
                                > > > quite manageable, and be agile almost automatically. And, as an extra
                                > > > option, you can end them whenever you like.
                                > > >
                                > > > Alas, this line of thought of me was so recent that I could not try it
                                > > > on a "fresh" manager yet.
                                > > >
                                > > > Best regards,
                                > > > Willem Bogaerts
                                > >
                                > > To Post a message, send it to: extremeprogramming@...
                                > >
                                > > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                > >
                                > > ad-free courtesy of objectmentor.com
                                > > Yahoo! Groups Links
                                > >
                                > >
                                > >
                                > >
                                > >
                                >
                                > To Post a message, send it to: extremeprogramming@...
                                >
                                > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                >
                                > ad-free courtesy of objectmentor.com
                                > Yahoo! Groups Links
                                >
                                >
                                >
                                >
                                >


                                --
                                Dakshinamurthy Karra (http://xperiencingagility.blogspot.com)
                              Your message has been successfully submitted and would be delivered to recipients shortly.