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

[XP] Re: SD Times front page article, and issues of accountability

Expand Messages
  • Jeff Grigg
    ... A strength of XP has been its prescriptive nature: Do this. (...until you get good enough at it to know what to do.) Reversing that emphasis seems to
    Message 1 of 10 , Feb 13, 2005
      --- "Kent Beck" <kentb@e...> wrote:
      > Thanks for looking up the URL. I would like to hear more
      > about your reaction.

      A strength of XP has been its prescriptive nature: "Do this.
      (...until you get good enough at it to know what to do.)" Reversing
      that emphasis seems to be the downfall of approaches like RUP.

      Yes, RUP is popular; almost no matter what people are doing, they
      can describe it with the RUP model, and get a "pat on the back," and
      a welcome into the RUP camp. If they happen to be successful, all
      the better for RUP. RUP can be kind of like this: "Here are a
      bunch of good ideas. Without even a suggestion that you try them,
      pick out the ones you feel comfortable with, throw them together,
      and now you have a RUP project plan. Congratulations; you're now
      one of us."


      I haven't read the new book, and the interview quotes could be taken
      out of context. (But I'll spout off at the mouth anyway... ;-)

      The Amazon reviews of the new book, "Extreme Programming Explained :
      Embrace Change (2nd Edition)" look good. http://tinyurl.com/7xdxp
      The additional material looks helpful. I haven't seen anything I
      object to, but then I haven't read the book.


      Something that troubles me about the article is the frequent use of
      the term "accountable," without being clear about what you mean by
      it. I've been through plenty of dysfunctional organizations with
      unhealthy views on accountability: "You're responsible for
      estimating work, in spite of vague requirements. Then you're
      responsible for delivering on the estimate, regardless of personal
      cost, in spite of requirements discovery, imposed scope creep, and
      denial of resources that were promised." I've seen Deming give good
      demonstrations showing how "holding people accountable" for their
      results, in a flawed process, can be nothing but destructive.

      Saying "we'll hold programmers /accountable/ for their results"
      without saying how we would enable them to achieve good results,
      troubles me.



      >> --- "Kent Beck" <kentb@e...> wrote:
      >>> SD Times covered XP and agile development on the front
      >>> page of their February 1 issue. I'm curious how people
      >>> on this list react to it.

      >> From: Jeff Grigg [mailto:jeffgrigg@c...]
      >> http://68.236.189.240/article/story-20050201-03.html
    • Charles R Martin
      ... Jeff, I think you ve got a really good point here. One of the real strengths of the white book (TOS) was that it says Do this: you ll observe good
      Message 2 of 10 , Feb 13, 2005
        Jeff Grigg wrote:
        >
        > --- "Kent Beck" <kentb@e...> wrote:
        >
        >>Thanks for looking up the URL. I would like to hear more
        >>about your reaction.
        >
        >
        > A strength of XP has been its prescriptive nature: "Do this.
        > (...until you get good enough at it to know what to do.)" Reversing
        > that emphasis seems to be the downfall of approaches like RUP.

        Jeff, I think you've got a really good point here. One of the real
        strengths of the white book (TOS) was that it says "Do this: you'll
        observe good results." RUP, and before that for example IBM's WSSDM
        methodology, were handy because they had *lots* of methods and lots of
        practices, allowing you to pick the ones you need. The hazard is, as
        you say, that you can pick and choose almost anything. It thus requires
        lots of experience and knowledge and wisdom to know what to pick and how
        to use it.

        XP (TOS) avoids that problem by having a small collection of
        well-integrated practices that almost always work, at least within the
        intended limits of XP. If you give up the prescriptive part of the
        process, I think you may lose that.

        I don't think that means you're trying to control people: you're just
        informing them that *if* they want the good results, *then* they should
        apply all, or nearly all, of these methods.

        [....]

        > Something that troubles me about the article is the frequent use of
        > the term "accountable," without being clear about what you mean by
        > it. I've been through plenty of dysfunctional organizations with
        > unhealthy views on accountability: "You're responsible for
        > estimating work, in spite of vague requirements. Then you're
        > responsible for delivering on the estimate, regardless of personal
        > cost, in spite of requirements discovery, imposed scope creep, and
        > denial of resources that were promised." I've seen Deming give good
        > demonstrations showing how "holding people accountable" for their
        > results, in a flawed process, can be nothing but destructive.
        >
        > Saying "we'll hold programmers /accountable/ for their results"
        > without saying how we would enable them to achieve good results,
        > troubles me.

        Another excellent point. Something I think is really central to XP,
        although it isn't said explicitly so far as I recall, is "believe in
        reality". You can't do more than so much work a week, and generally
        working overtime won't help, telling people "work smarter" won't help,
        and imagining you'll make up a slip by, say, shortening testing won't
        help. What *will* help is: estimating on a small scale, which is more
        accurate; measuring the actual results; and adjusting your plans and
        estimates to match reality, instead of what you *wish* were true.
      • Ron Jeffries
        ... Pray permit me to elaborate a bit on what you ve said here. I agree that trying to control people is not necessary (and I ve recently mentioned that I try
        Message 3 of 10 , Feb 13, 2005
          On Sunday, February 13, 2005, at 1:49:24 PM, Charles R Martin wrote:

          > XP (TOS) avoids that problem by having a small collection of
          > well-integrated practices that almost always work, at least within the
          > intended limits of XP. If you give up the prescriptive part of the
          > process, I think you may lose that.

          > I don't think that means you're trying to control people: you're just
          > informing them that *if* they want the good results, *then* they should
          > apply all, or nearly all, of these methods.

          Pray permit me to elaborate a bit on what you've said here.

          I agree that trying to control people is not necessary (and I've
          recently mentioned that I try not to use the practice anyway,
          because I don't want it used on me).

          That said, I think of the XP practices more as skills, rather than
          as things one "must do" in order to succeed. There are many ways to
          succeed. By practicing the XP skills, especially in concert, we
          learn some specifics, such as some better ways to test. But we also
          learn things that are much harder to write about, prescriptively or
          otherwise. We learn things about ourselves and our colleagues, and
          through working within and around the basic practices, we find ways
          to work together more effectively.

          I believe that XP practices teach, and that they /enable/ good
          results. In the absence of the learning that is the other side of
          teaching, I do not believe that XP practices will /cause/ good
          results.

          Ron Jeffries
          www.XProgramming.com
          Replacing an on-site customer with some use cases is about as effective
          as replacing a hug from your Mom with a friendly note.
        • Dale Emery
          Hi Ron, ... I have an additional reason: To the extent that I fail to control people, trying is a waste of time. To the extent that I succeed, trying is a
          Message 4 of 10 , Feb 13, 2005
            Hi Ron,

            > I agree that trying to control people is not necessary (and
            > I've recently mentioned that I try not to use the practice
            > anyway, because I don't want it used on me).

            I have an additional reason: To the extent that I fail to
            control people, trying is a waste of time. To the extent that I
            succeed, trying is a bigger waste of time.

            Dale

            --
            Dale Emery, Consultant
            Inspiring Leadership for Software People
            Web: http://www.dhemery.com
            Weblog: http://www.dhemery.com/cwd

            Consistency requires you to be as ignorant today as you were a
            year ago. --Bernard Berenson
          • Charles R Martin
            ... I *like* it.
            Message 5 of 10 , Feb 13, 2005
              Dale Emery wrote:
              > I have an additional reason: To the extent that I fail to
              > control people, trying is a waste of time. To the extent that I
              > succeed, trying is a bigger waste of time.

              I *like* it.
            • Kent Beck
              ... I don t believe that the XP practices almost always work. They are the best way I know how to develop, but I m not like other people (nor are they like me
              Message 6 of 10 , Feb 15, 2005
                > -----Original Message-----
                > From: Charles R Martin [mailto:crmartin@...]
                > Sent: Sunday, February 13, 2005 10:49 AM
                > To: extremeprogramming@yahoogroups.com
                > Subject: Re: [XP] Re: SD Times front page article, and issues
                > of accountability
                >
                > Jeff Grigg wrote:
                > >
                > > --- "Kent Beck" <kentb@e...> wrote:
                > >
                > >>Thanks for looking up the URL. I would like to hear more
                > >>about your reaction.
                > >
                > >
                > > A strength of XP has been its prescriptive nature: "Do this.
                > > (...until you get good enough at it to know what to do.)"
                > Reversing
                > > that emphasis seems to be the downfall of approaches like RUP.
                >
                > Jeff, I think you've got a really good point here. One of the real
                > strengths of the white book (TOS) was that it says "Do this: you'll
                > observe good results." RUP, and before that for example IBM's WSSDM
                > methodology, were handy because they had *lots* of methods
                > and lots of
                > practices, allowing you to pick the ones you need. The hazard is, as
                > you say, that you can pick and choose almost anything. It
                > thus requires
                > lots of experience and knowledge and wisdom to know what to
                > pick and how
                > to use it.
                >
                > XP (TOS) avoids that problem by having a small collection of
                > well-integrated practices that almost always work, at least
                > within the
                > intended limits of XP. If you give up the prescriptive part of the
                > process, I think you may lose that.

                I don't believe that the XP practices almost always work. They are the best
                way I know how to develop, but I'm not like other people (nor are they like
                me :-) XPE2 is clearer about practices (there are twice as many, for a
                start) than XPE1, but it doesn't pretend that they are magic, which is what
                I read in your message.

                > I don't think that means you're trying to control people: you're just
                > informing them that *if* they want the good results, *then*
                > they should
                > apply all, or nearly all, of these methods.

                Yes, I *was* trying to control people. In XPE1, I was trying to get people
                to program like I program. I was trying to control the readers by getting
                them to think how I think. (Good programmers do it just like me.) In XPE2, I
                am trying to encourage people to improve their own process their own way,
                but with some very specific and, I hope, challenging examples of how far
                they could improve. Ironically the values and principles didn't change much,
                except for the addition of respect and integrity. We have added more
                practices as we gained experience.

                No one can guarantee good results for a particular team doing embedded
                controllers or a high-capacity web site or a medical device. The situation
                isn't hopeless, however. I think I can suggest values, principles, and
                practices that can help people improve their own situations dramatically.
              • Kent Beck
                Jeff, Thank you for your comments on the article. I re-read it to see how I used the word accountable . I will certainly be more careful how I use it in the
                Message 7 of 10 , Feb 15, 2005
                  Jeff,

                  Thank you for your comments on the article. I re-read it to see how I used
                  the word "accountable". I will certainly be more careful how I use it in the
                  future. From the article it sounds like I think accountability is something
                  that needs to be forced on programmers. My intention is quite the opposite.
                  I think accountability is something that should be offered by programmers
                  because it is in their best interest.

                  Before I say what I mean by accountability, I will say that what you
                  describe below sounds more like blame or shame than accountability: I didn't
                  get what I wanted so I'm going to make you feel bad so I can feel better. I
                  don't think blame in a relationship benefits any of the parties.

                  Accountability, on the other, can be to everyone's benefit. Accountability
                  is saying what you intend to do, doing your best to meet those commitments,
                  and rendering account for what you actually did. Accountability is hard when
                  I don't feel good about what I did, but that's also when it is most
                  valuable. If I am prepared to stand up and say that I was the one who didn't
                  run the tests and broke the build, then I might not be a good programmer but
                  at least I can be trusted to own my own mistakes. Whether my team
                  appreciates my candor, I can sleep soundly at night knowing that I'm not
                  holding any secrets back.

                  This reminds me of William Petri's team that was given two year's worth of
                  impossible deadlines and then fired for underperforming. Such a team would
                  be accountable if they published their own plan for what they intended to
                  do, regardless of the decreed scope/deadline. They would then do their best
                  to execute on that plan, with plentiful opportunities for steering in case
                  the sponsors wanted to change priorities. When they had reached the deadline
                  they would stand up and say exactly what they had worked on and what they
                  hadn't worked on. The team could be satisfied that they communicated clearly
                  and that they did their best.

                  The article makes accountability sound like a more advanced technique for
                  holding programmers feet to the fire. One way I can think of to head this
                  off is to offer more accountability than is demanded. If you publish your
                  "dirty secrets" yourself, the surprise factor is gone.

                  Jeff, how does this sound to you?

                  Kent Beck
                  Three Rivers Institute

                  > -----Original Message-----
                  > From: Jeff Grigg [mailto:jeffgrigg@...]
                  > Sent: Sunday, February 13, 2005 7:07 AM
                  > To: extremeprogramming@yahoogroups.com
                  > Subject: [XP] Re: SD Times front page article, and issues of
                  > accountability
                  >
                  > Something that troubles me about the article is the frequent use of
                  > the term "accountable," without being clear about what you mean by
                  > it. I've been through plenty of dysfunctional organizations with
                  > unhealthy views on accountability: "You're responsible for
                  > estimating work, in spite of vague requirements. Then you're
                  > responsible for delivering on the estimate, regardless of personal
                  > cost, in spite of requirements discovery, imposed scope creep, and
                  > denial of resources that were promised." I've seen Deming give good
                  > demonstrations showing how "holding people accountable" for their
                  > results, in a flawed process, can be nothing but destructive.
                  >
                  > Saying "we'll hold programmers /accountable/ for their results"
                  > without saying how we would enable them to achieve good results,
                  > troubles me.
                • Charles R Martin
                  ... Not magic. There are nine-and-eighty way of composing tribal lays, and every single one of them is right. But if you don t have an idea how to start a
                  Message 8 of 10 , Feb 15, 2005
                    Kent Beck wrote:
                    >
                    >
                    >
                    >>-----Original Message-----
                    >>From: Charles R Martin [mailto:crmartin@...]
                    >>Sent: Sunday, February 13, 2005 10:49 AM
                    >>To: extremeprogramming@yahoogroups.com
                    >>Subject: Re: [XP] Re: SD Times front page article, and issues
                    >>of accountability
                    >>
                    >>Jeff Grigg wrote:
                    >>
                    >>>--- "Kent Beck" <kentb@e...> wrote:
                    >>>
                    >>>
                    >>>>Thanks for looking up the URL. I would like to hear more
                    >>>>about your reaction.
                    >>>
                    >>>
                    >>>A strength of XP has been its prescriptive nature: "Do this.
                    >>>(...until you get good enough at it to know what to do.)"
                    >>
                    >>Reversing
                    >>
                    >>>that emphasis seems to be the downfall of approaches like RUP.
                    >>
                    >>Jeff, I think you've got a really good point here. One of the real
                    >>strengths of the white book (TOS) was that it says "Do this: you'll
                    >>observe good results." RUP, and before that for example IBM's WSSDM
                    >>methodology, were handy because they had *lots* of methods
                    >>and lots of
                    >>practices, allowing you to pick the ones you need. The hazard is, as
                    >>you say, that you can pick and choose almost anything. It
                    >>thus requires
                    >>lots of experience and knowledge and wisdom to know what to
                    >>pick and how
                    >>to use it.
                    >>
                    >>XP (TOS) avoids that problem by having a small collection of
                    >>well-integrated practices that almost always work, at least
                    >>within the
                    >>intended limits of XP. If you give up the prescriptive part of the
                    >>process, I think you may lose that.
                    >
                    >
                    > I don't believe that the XP practices almost always work. They are the best
                    > way I know how to develop, but I'm not like other people (nor are they like
                    > me :-) XPE2 is clearer about practices (there are twice as many, for a
                    > start) than XPE1, but it doesn't pretend that they are magic, which is what
                    > I read in your message.

                    Not magic. "There are nine-and-eighty way of composing tribal lays, and
                    every single one of them is right." But if you don't have an idea how
                    to start a large poem, studying iambic pentameter doesn't hurt.

                    >>I don't think that means you're trying to control people: you're just
                    >>informing them that *if* they want the good results, *then*
                    >>they should
                    >>apply all, or nearly all, of these methods.
                    >
                    >
                    > Yes, I *was* trying to control people. In XPE1, I was trying to get people
                    > to program like I program. I was trying to control the readers by getting
                    > them to think how I think. (Good programmers do it just like me.) In XPE2, I
                    > am trying to encourage people to improve their own process their own way,
                    > but with some very specific and, I hope, challenging examples of how far
                    > they could improve. Ironically the values and principles didn't change much,
                    > except for the addition of respect and integrity. We have added more
                    > practices as we gained experience.

                    Based on that description --- since I haven't finished the new book yet
                    --- I think you're losing something very valuable from the first edition.

                    Maybe the issue is analogous to the difference between moving from
                    apprentice to journeyman, and from journeyman to master?
                  • Devin Mullins
                    ... This is something I have practiced regularly for quite a while. It is high up there in my book, and helps improve process by establishing visibility on the
                    Message 9 of 10 , Feb 15, 2005
                      Kent Beck wrote:

                      >If you publish your
                      >"dirty secrets" yourself, the surprise factor is gone.
                      >
                      >
                      This is something I have practiced regularly for quite a while. It is
                      high up there in my book, and helps improve process by establishing
                      visibility on the flaws to those that can fix it. (If I were less tired,
                      I would make more sense in that previous sentence...) Maybe, though, I'm
                      just on a particularly forgiving (i.e. common sense) project.

                      Devin
                    • Kent Beck
                      I think the difference is that in XPE2 I am not offering people the illusion that they aren t responsible for their own choices. After all, if you just copy
                      Message 10 of 10 , Mar 1, 2005
                        I think the difference is that in XPE2 I am not offering people the illusion
                        that they aren't responsible for their own choices. After all, if you just
                        copy what I do, then it appears to the twisted that I am responsible for the
                        outcome. That's not now it works out. If you get fired, you still get fired.
                        I think some people who resonated with XPE1 find solace in, "...but I'm just
                        doing XP."

                        Kent Beck
                        Three Rivers Institute

                        > -----Original Message-----
                        > From: Charles R Martin [mailto:crmartin@...]
                        > Sent: Tuesday, February 15, 2005 6:36 PM
                        > To: extremeprogramming@yahoogroups.com
                        > Subject: Re: [XP] Re: SD Times front page article, and issues
                        > of accountability
                        >
                        > Based on that description --- since I haven't finished the
                        > new book yet
                        > --- I think you're losing something very valuable from the
                        > first edition.
                        >
                        > Maybe the issue is analogous to the difference between moving from
                        > apprentice to journeyman, and from journeyman to master?
                      Your message has been successfully submitted and would be delivered to recipients shortly.