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

Re: [XP] No customer-side iterations means trouble

Expand Messages
  • yahoogroups@jhrothjr.com
    From: Paolo Nusco Perrotta To: extremeprogramming@yahoogroups.com
    Message 1 of 11 , Feb 27, 2006
    • 0 Attachment
      From: "Paolo Nusco Perrotta"
      <ml.at.paoloperrotta.com@...>
      To: "extremeprogramming@yahoogroups.com"
      <extremeprogramming.at.yahoogroups.com@...>
      Sent: Monday, February 27, 2006 4:52 PM
      Subject: [XP] No customer-side iterations means trouble


      >I used to believe that you can do something that is "almost agile"
      > without telling your customer. You sign a big one-shot deal, you ask
      > some guy in your team to play the customer's role, and you merrily
      > develop the system with internal iterations. When you're finished, you
      > deploy it to the real customer.

      To quote Michael: Belief is silly. Validate.

      > Now I believe that if you do that, you'll waste your potential edge on
      > the market. You won't be able to compete effectively with people doing
      > waterfall or plain old chaos. Iterations are not just a quality problem.
      > They're a price problem.
      >
      > A friend told me that in his company, the concept of Business Value
      > doesn't mean anything at all. Here's how it works there. The customer
      > asks the manager: how much will the system cost? The manager asks the
      > developers: how long will you take? The developers reply with an
      > estimate, the manager turns that into costs, adds the expected earning
      > for the company and reports the price to the customer. This company
      > doesn't (and shouldn't) care what the system's business value is. They
      > only know the expected costs and earnings. Either the customer is
      > willing to pay that, or it's not good business. The depressing
      > conclusion: the only way to "make it better" is to either cut earnings
      > or cut costs.
      >
      > Iterations and the Planning Game give the customer continuous
      > quality/price control. If you don't have iterations, the customer will
      > ask for the only thing that gives her some sort of security - that is,
      > everything and perfect. At this point, all the company can do to win a
      > customer is lower the price. Sure, there is the "promise of quality"
      > that comes from being a big brand, or having previous experience with
      > that particular customer. But in general, quality is invisible when you
      > sign the deal. It cannot be a factor in the customer's choice.
      >
      > So, without customer-side iterations, we can compete on price alone.

      Well yes. You compete for work on price. However, quality has a
      major effect on price: defects are _very_ expensive from a development
      (not just a customer) view. The process that has the fewest outstanding
      defects at any time is pretty much going to be the lowest cost process -
      assuming that it doesn't chew up staff hours in other wasteful practices.

      John Roth


      >
      > Paolo Perrotta
      > Bologna, Italy
      >
      >
      >
      >
      > 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
      >
      >
      >
      >
      >
      >
      >
    • Jeff Nielsen
      ... As you imply, another big thing you lose without customer-side iterations is the ability to cut features that don t turn out to be as valuable than we
      Message 2 of 11 , Feb 27, 2006
      • 0 Attachment
        "Paolo "Nusco" Perrotta" wrote:
        >
        > Iterations and the Planning Game give the customer continuous
        > quality/price control. If you don't have iterations, the customer will
        > ask for the only thing that gives her some sort of security - that is,
        > everything and perfect. At this point, all the company can do to win a
        > customer is lower the price. Sure, there is the "promise of quality"
        > that comes from being a big brand, or having previous experience with
        > that particular customer. But in general, quality is invisible when you
        > sign the deal. It cannot be a factor in the customer's choice.

        As you imply, another big thing you lose without "customer-side iterations"
        is the ability to cut features that don't turn out to be as valuable than we
        originally thought up front, and the ability to add features that are more
        valuable than we originally thought. This is where a lot of the cost
        savings comes. No one--no matter how smart they are--can specify a new
        system up front that will be a better use of the investment $$ than a system
        where the whole team (including the customer) is allowed to learn as they
        see working software evolve.

        Jeff Nielsen
        Digital Focus
        www.digitalfocus.com
      • Philip Doherty
        Is there any value in doing iterations if the customer is not involved? ... From: extremeprogramming@yahoogroups.com
        Message 3 of 11 , Feb 28, 2006
        • 0 Attachment
          Is there any value in doing iterations if the customer is not involved?

          -----Original Message-----
          From: extremeprogramming@yahoogroups.com
          [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Paolo "Nusco"
          Perrotta
          Sent: 28 February 2006 12:51
          To: extremeprogramming@yahoogroups.com
          Subject: Re: [XP] No customer-side iterations means trouble

          Ron Jeffries wrote:
          > On Monday, February 27, 2006, at 3:52:45 PM, Paolo "Nusco" Perrotta
          wrote:
          >
          >> So, without customer-side iterations, we can compete on price alone.
          >>
          >
          > Yes, but with XP-style iterations, I can generate more software faster

          > and better. So perhaps I can either charge a lower price, or collect a

          > higher profit.
          >

          I'm very aware of this (John pointed this out well too). I agree that
          "internal iterations" are better than no iteration at all because they
          provide better ROI. You'll have better quality, hence wider margins.

          What I say is: the customer doesn't know about this when she signs the
          contract. She cannot foresee future quality (expect in the cases I
          mentioned). She can only compare your price with the price of your
          competitor.

          Of course you can apply XP "internally", get less defects, and lower
          your price because of that. But you're bound to have some bad surprises,
          because you don't have the continuous validation that customer-side
          iterations provide. As Jeff writes, you cannot specify the whole system
          in advance. So, you have to keep your price high enough to cover risks.

          Now let's see what your competitor is doing. They have another approach
          to keeping their prices low: they hire cheap people. They'll have lots
          of defects, they'll be overtime, and in the end the customer will
          probably be sorry. Still, they'll be very competitive when it comes to
          winning the client in the first place. If demand is low, they'll
          effectively win the market.

          Unfortunately, I'm not talking from a theoretical point of view. This is
          exactly what is happening in my Country right now. Software houses tend
          to hire very cheap, unexperienced people. I heard many companies
          formulating this explicitly: "We don't need experienced developers, we
          need developers within our budget". Of course, there is wide distrust of
          software development because of that. Still, that's the market for us.
          Other than moving abroad, I wonder if I can do anything about it. How
          can I make a promise of quality before the system is built?

          Paolo Perrotta
          Bologna, Italy




          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
        • Ron Jeffries
          ... A few, including ... Faster feedback on how well things are going. Reduction of risk before the bulk of the spending is committed. Greater readiness if and
          Message 4 of 11 , Feb 28, 2006
          • 0 Attachment
            On Tuesday, February 28, 2006, at 5:08:34 AM, Philip Doherty wrote:

            > Is there any value in doing iterations if the customer is not involved?

            A few, including ...

            Faster feedback on how well things are going. Reduction of risk
            before the bulk of the spending is committed. Greater readiness if
            and when things change. More fun. Quite probably lower overall
            expense to the end point. Possibility of going back to the customer
            with something to show, plus new ideas for how to proceed.

            Did I mention more fun?

            Ron Jeffries
            www.XProgramming.com
            I must create a system, or be enslaved by another man's;
            I will not reason and compare; my business is to create. --William Blake
          • Paul Grew
            I ve started to introduce the practice of pair programming to my team of 9 staff with mixed enthusiasm; however i m keen that it will be a success as previous
            Message 5 of 11 , Feb 28, 2006
            • 0 Attachment
              I've started to introduce the practice of pair programming to my team of 9
              staff with mixed enthusiasm; however i'm keen that it will be a success as
              previous experience has shown benefits in productivity and quality.

              My feeling is that being a good pair is a skill in itself. I've been
              involved in XP for a couple of years and a reading Laurie Williams book.

              My question for the group is how do you coach and teach people to be good
              pairs?

              thanks

              Paul
            • Ilja Preuss
              ... There are some good ideas at http://www.xprogramming.com/xpmag/Etudes.htm#N84 Other than that, talk about it. Discuss what works and what not, and why, and
              Message 6 of 11 , Feb 28, 2006
              • 0 Attachment
                > My question for the group is how do you coach and teach people to be
                > good pairs?

                There are some good ideas at
                http://www.xprogramming.com/xpmag/Etudes.htm#N84

                Other than that, talk about it. Discuss what works and what not, and why,
                and what you can try to do differently in the future.

                Cheers, Ilja
              • Thierry Cros
                pair programming : - first of all, i explain that PP needs to be.. explained (~1 hour) - some explanations about PP benefits (e.g. risk mitigation, quality
                Message 7 of 11 , Feb 28, 2006
                • 0 Attachment
                  pair programming :
                  - first of all, i explain that PP needs to be.. explained (~1 hour)
                  - some explanations about PP benefits (e.g. risk mitigation, quality improvment)
                  - some explanations about PP rules (let me drive...)
                  - and example
                  - and the 1st set of rules for the team : "what do you think ? do we change pairs every hour ? day ? when do we meeting again (debriefing of the 1st experience)"


                  Paul Grew <paul.grew@...> a écrit :
                  I've started to introduce the practice of pair programming to my team of 9
                  staff with mixed enthusiasm; however i'm keen that it will be a success as
                  previous experience has shown benefits in productivity and quality.

                  My feeling is that being a good pair is a skill in itself. I've been
                  involved in XP for a couple of years and a reading Laurie Williams book.

                  My question for the group is how do you coach and teach people to be good
                  pairs?

                  thanks

                  Paul



                  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









                  -- Thierry Cros --

                  http://www.thierrycros.net

                  "Maîtrisez les projets avec l'Extreme Programming"
                  Editions Cépaduès - 2004











                  <pub>

                  ---------------------------------
                  Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.Téléchargez la version beta.

                  [Non-text portions of this message have been removed]
                • William Wake
                  ... One little exercise I use I think of as ping pong - Sharon writes a test, Bob writes the code to makes it pass then writes the next test, then Sharon
                  Message 8 of 11 , Feb 28, 2006
                  • 0 Attachment
                    On 2/28/06, Paul Grew <paul.grew@...> wrote:
                    > My question for the group is how do you coach and teach
                    > people to be good pairs?

                    One little exercise I use I think of as "ping pong" - Sharon writes a
                    test, Bob writes the code to makes it pass then writes the next test,
                    then Sharon makes that pass and writes a third test, etc. (I don't
                    work this way all day, but it's a good introduction for test-driven
                    development and it demonstrates some pairing principles.)

                    I tell people if they're starting to lose focus they should ask to
                    drive for a while, and when I've got the keyoard I try to notice if my
                    partner's zoning out and hand over the keyboard.

                    We have a chart where we track who paired with who each week. (And
                    also who paired "with themselves"). This helps nudge people into
                    different pairs each day.


                    When we go to check in, if changes are significant, we'll diff each
                    file before checking it in. This is another chance for code review.

                    After a checkin, I like to do a mini-retrospective and talk about what
                    we just saw and did. I'm not particularly steady on this, though. (I
                    intend to make it a more frequent habit.)

                    We have a "half-day for research" built in for each person each week.
                    That gives a little escape valve so you're not pairing all the time.
                    --
                    Bill Wake William.Wake@... www.xp123.com
                  • yahoogroups@jhrothjr.com
                    From: Paolo Nusco Perrotta To: extremeprogramming@yahoogroups.com
                    Message 9 of 11 , Feb 28, 2006
                    • 0 Attachment
                      From: "Paolo Nusco Perrotta"
                      <ml.at.paoloperrotta.com@...>
                      To: "extremeprogramming@yahoogroups.com"
                      <extremeprogramming.at.yahoogroups.com@...>
                      Sent: Tuesday, February 28, 2006 5:50 AM
                      Subject: Re: [XP] No customer-side iterations means trouble


                      > Ron Jeffries wrote:
                      >> On Monday, February 27, 2006, at 3:52:45 PM, Paolo "Nusco" Perrotta
                      >> wrote:
                      >>
                      >>> So, without customer-side iterations, we can compete on price alone.
                      >>>
                      >>
                      >> Yes, but with XP-style iterations, I can generate more software
                      >> faster and better. So perhaps I can either charge a lower price, or
                      >> collect a higher profit.
                      >>
                      >
                      > I'm very aware of this (John pointed this out well too). I agree that
                      > "internal iterations" are better than no iteration at all because they
                      > provide better ROI. You'll have better quality, hence wider margins.
                      >
                      > What I say is: the customer doesn't know about this when she signs the
                      > contract. She cannot foresee future quality (expect in the cases I
                      > mentioned). She can only compare your price with the price of your
                      > competitor.
                      >
                      > Of course you can apply XP "internally", get less defects, and lower
                      > your price because of that. But you're bound to have some bad surprises,
                      > because you don't have the continuous validation that customer-side
                      > iterations provide. As Jeff writes, you cannot specify the whole system
                      > in advance. So, you have to keep your price high enough to cover risks.
                      >
                      > Now let's see what your competitor is doing. They have another approach
                      > to keeping their prices low: they hire cheap people. They'll have lots
                      > of defects, they'll be overtime, and in the end the customer will
                      > probably be sorry. Still, they'll be very competitive when it comes to
                      > winning the client in the first place. If demand is low, they'll
                      > effectively win the market.
                      >
                      > Unfortunately, I'm not talking from a theoretical point of view. This is
                      > exactly what is happening in my Country right now. Software houses tend
                      > to hire very cheap, unexperienced people. I heard many companies
                      > formulating this explicitly: "We don't need experienced developers, we
                      > need developers within our budget". Of course, there is wide distrust of
                      > software development because of that. Still, that's the market for us.
                      > Other than moving abroad, I wonder if I can do anything about it. How
                      > can I make a promise of quality before the system is built?

                      This is a sales issue. There's an old saying in English about the
                      customer who looks only at price getting what they deserve (I'm
                      a bit too lazy to look up the exact quote at the moment).

                      Your selling point should be your strong points: anyone can crank
                      out garbage code but a real XP shop works with the customer to
                      insure that the result is what they want to the quality they want.

                      In English law there are two basic warrenties: merchantability and
                      fitness for purpose. The software industry has been given a free pass
                      on these for several decades now, which is one of the reasons why
                      we have the mess we currently have. However, that's a side issue
                      to your question.

                      Code quality deals with the warrenty of merchantability. It has
                      two aspects: as seen by the developer,
                      and as seen by the customer. An XP development team is going
                      to get to a level of quality that lets them keep a sustainable pace.
                      The customer's view is in terms of crashes, field reported defects
                      and how easy it is to get changes.

                      Fitness for purpose deals with whether the software actually
                      does the job that the customer thought it was going to do.
                      Having the customer steer the direction the product is taking
                      is the only way I know of to insure that.

                      John Roth

                      >
                      > Paolo Perrotta
                      > Bologna, Italy
                      >
                      >
                      >
                      >
                      > 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
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                    • Ron Jeffries
                      ... I don t think I can /teach/ people much of anything. What I can do is to show them how I do things, tell them how other people of skill do things, invite
                      Message 10 of 11 , Feb 28, 2006
                      • 0 Attachment
                        On Tuesday, February 28, 2006, at 5:51:55 AM, Paul Grew wrote:

                        > I've started to introduce the practice of pair programming to my team of 9
                        > staff with mixed enthusiasm; however i'm keen that it will be a success as
                        > previous experience has shown benefits in productivity and quality.

                        > My feeling is that being a good pair is a skill in itself. I've been
                        > involved in XP for a couple of years and a reading Laurie Williams book.

                        > My question for the group is how do you coach and teach people to be good
                        > pairs?

                        I don't think I can /teach/ people much of anything. What I can do
                        is to show them how I do things, tell them how other people of skill
                        do things, invite them to practice, and offer suggestions and hints
                        as to how to observe and assess themselves and their pair.

                        It's the practice that does it, in my opinion.

                        Ron Jeffries
                        www.XProgramming.com
                        Sometimes you just have to stop holding on with both hands, both
                        feet, and your tail, to get someplace better. Of course you might
                        plummet to the earth and die, but probably not:
                        You were made for this.
                      • Andrew McDonagh
                        ... I don t think I can anything to what you already know. But I did find this report interesting and when I showed it to my last XP team it helped them and
                        Message 11 of 11 , Mar 5, 2006
                        • 0 Attachment
                          Paul Grew wrote:
                          > I've started to introduce the practice of pair programming to my team of 9
                          > staff with mixed enthusiasm; however i'm keen that it will be a success as
                          > previous experience has shown benefits in productivity and quality.
                          >
                          > My feeling is that being a good pair is a skill in itself. I've been
                          > involved in XP for a couple of years and a reading Laurie Williams book.
                          >
                          > My question for the group is how do you coach and teach people to be good
                          > pairs?
                          >
                          > thanks
                          >
                          > Paul
                          >

                          I don't think I can anything to what you already know.

                          But I did find this report interesting and when I showed it to my last
                          XP team it helped them and other managers consider pairing rather than
                          rejecting it out of hand.

                          http://www.stsc.hill.af.mil/crosstalk/2003/03/jensen.html

                          Andrew
                        Your message has been successfully submitted and would be delivered to recipients shortly.