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

Re: [XP] Back of the Door Sticky Note Issue Tracking.

Expand Messages
  • Ron Jeffries
    Hi Steven, ... Could you perhaps phrase this idea in such a way as to do two things that this does not: First, offer advice on what one might do, rather than
    Message 1 of 24 , Mar 13, 2013
    • 0 Attachment
      Hi Steven,

      On Mar 13, 2013, at 3:16 PM, Steven Gordon <sgordonphd@...> wrote:

      > A process that attempts to make it impossible for people to produce defects
      > would be too prescriptive to be efficient or to produce learning or
      > innovation. We would all much prefer a process that facilitates people
      > learning to get better, but then such a process would allow defects along
      > the way.


      Could you perhaps phrase this idea in such a way as to do two things that this does not:

      First, offer advice on what one might do, rather than on what one ought not do, and, second, offer advice that tends to lead to a continuing reduction of defects?

      Ron Jeffries
      www.XProgramming.com
      I have two cats, and a big house full of cat stuff.
      The cats fight and divide up the house, messing up their own lives.
      Nice work cats.
      Meow.



      [Non-text portions of this message have been removed]
    • John Carter
      ... Problems found later became a (possibly high priority) story. That is effectively, although perhaps not consciously, the lean manufacturing route. ie.
      Message 2 of 24 , Mar 13, 2013
      • 0 Attachment
        On Wed, Mar 13, 2013 at 5:07 PM, Charlie Poole <charliepoole@...>wrote:

        > Problems found when a story was initially believed to be finished either
        > meant the story wasn't finished or that a new story had to be written.
        >
        Problems found later became a (possibly high priority) story.


        That is effectively, although perhaps not consciously, the "lean
        manufacturing" route.

        ie. Throttle the rate of defect injection / increase defect fix to match
        that of defect discovery.

        ie. No queues.


        > > b) The "lean manufacturing", less desirable, but still sane answer that
        > you
        > > balance the number of testers, new feature developers, and defect fixers
        > > until the rates of defect injection, discovery and fix are identical. (No
        > > queues)
        >




        --
        John Carter Phone : (64)(3) 358 6639
        Tait Electronics Fax : (64)(3) 359 4632
        PO Box 1645 Christchurch Email : john.carter@...
        New Zealand

        --

        ------------------------------
        This email, including any attachments, is only for the intended recipient.
        It is subject to copyright, is confidential and may be the subject of legal
        or other privilege, none of which is waived or lost by reason of this
        transmission.
        If you are not an intended recipient, you may not use, disseminate,
        distribute or reproduce such email, any attachments, or any part thereof.
        If you have received a message in error, please notify the sender
        immediately and erase all copies of the message and any attachments.
        Unfortunately, we cannot warrant that the email has not been altered or
        corrupted during transmission nor can we guarantee that any email or any
        attachments are free from computer viruses or other conditions which may
        damage or interfere with recipient data, hardware or software. The
        recipient relies upon its own procedures and assumes all risk of use and of
        opening any attachments.
        ------------------------------


        [Non-text portions of this message have been removed]
      • Steve Smith
        One might try to create an uber-prescriptive process that makes defects impossible - and it might be successful, in that it might prevent any work at all from
        Message 3 of 24 , Mar 13, 2013
        • 0 Attachment
          One might try to create an uber-prescriptive process that makes defects
          impossible - and it might be successful, in that it might prevent any work
          at all from getting done (but hey, zero bugs!). I think we both agree that
          a more appropriate process is one that is more flexible and adaptable and
          lets the people involved (whom I agree are the most important part) do the
          right things to prevent shipping defects. Of course mistakes and learning
          will happen - the process should simply encourage this kind of learning and
          improving the process to prevent defects from shipping (and to prevent
          known defects from recurring).

          Steve



          On Wed, Mar 13, 2013 at 3:16 PM, Steven Gordon <sgordonphd@...> wrote:

          > **
          >
          >
          > On Wed, Mar 13, 2013 at 11:14 AM, Steve Smith <ssmith.lists@...
          > >wrote:
          >
          >
          > > I'm not sure who said it first (it wasn't me), but I like the quote:
          > > "If you have a process that is producing defects, then you have a
          > defective
          > > process."
          > >
          > > Steve
          > >
          > >
          > A dangerous quote - it is people who do or do not produce defects.
          > Processes can only help or hinder.
          >
          > A process that attempts to make it impossible for people to produce defects
          > would be too prescriptive to be efficient or to produce learning or
          > innovation. We would all much prefer a process that facilitates people
          > learning to get better, but then such a process would allow defects along
          > the way.
          >
          > SteveG
          >
          >
          > [Non-text portions of this message have been removed]
          >
          >
          >



          --
          Steve Smith
          http://Ardalis.com/
          http://twitter.com/ardalis


          [Non-text portions of this message have been removed]
        • Steve Smith
          Sure, I m @ardalis and I actually tweeted it myself right after posting this... :) ... -- Steve Smith http://Ardalis.com/ http://twitter.com/ardalis [Non-text
          Message 4 of 24 , Mar 13, 2013
          • 0 Attachment
            Sure, I'm @ardalis and I actually tweeted it myself right after posting
            this... :)


            On Wed, Mar 13, 2013 at 2:28 PM, Keith Ray <keith.ray@...> wrote:

            > **
            >
            >
            > Can I quote you on that ? (Twitter)
            >
            > C. Keith Ray
            > http://agilesolutionspace.blogspot.com/
            > twitter: @ckeithray
            >
            >
            > On Mar 13, 2013, at 11:14 AM, Steve Smith <ssmith.lists@...> wrote:
            >
            > > I'm not sure who said it first (it wasn't me), but I like the quote:
            > > "If you have a process that is producing defects, then you have a
            > defective
            > > process."
            > >
            > > Steve
            > >
            > >
            > >
            > > On Wed, Mar 13, 2013 at 6:35 AM, Ron Jeffries <ronjeffries@...>
            > wrote:
            > >
            > >> **
            >
            > >>
            > >>
            > >> Hello, John,
            > >>
            > >>
            > >> On Mar 12, 2013, at 11:47 PM, John Carter <john.carter@...>
            > wrote:
            > >>
            > >>> a) The Obvious and most Desirable route is Magic Happens, and
            > developers
            > >>> create so few defects there aren't any defects for the testers to find.
            > >>>
            > >>> b) The "lean manufacturing", less desirable, but still sane answer that
            > >> you
            > >>> balance the number of testers, new feature developers, and defect
            > fixers
            > >>> until the rates of defect injection, discovery and fix are identical.
            > (No
            > >>> queues)
            > >>>
            > >>> c) The even less desirable, but still vaguely sanish answer that when
            > the
            > >>> sticky notes have covered the door... you start throwing away the least
            > >>> important (and rely on the tester's memory that we found that bug
            > before,
            > >>> but threw it away).
            > >>>
            > >>> d) The totally unacceptable route that you have so few / so weak
            > testers
            > >>> that despite an ever growing pool of defects, they aren't finding them.
            > >>
            > >> I have to say that I'm a bit surprised to see you asking this question.
            > >>
            > >> Alistair's point is that good teams don't have very many defects.
            > Frankly
            > >> I don't see why they'd need a whole bloody door.
            > >>
            > >> The correct option is (a), but it's not done with magic, it's done by
            > >> being ****ing competent. Let's face it, if developers are creating
            > defects,
            > >> they are to that extent incompetent.
            > >>
            > >> The notion included in (b) seems to think that only testers can find
            > >> defects and only "defect fixers" can fix them. XP and all Agile methods
            > are
            > >> about cross-functional teams. The team tests, the team finds defects,
            > the
            > >> team fixes them.
            > >>
            > >> How do they do that?
            > >>
            > >> Add testing skill to the development team. One way to do this is to
            > merge
            > >> the existing testers right in. Clearly the team needs all the necessary
            > >> skills to develop each feature, yes? Well, if the features are shipping
            > >> with defects, then clearly the team needs more testing.
            > >> Use Acceptance Test-Driven Development. Each feature's description
            > >> includes defined and preferably automated tests (checks) of examples of
            > >> that feature's correct operation. Developers, not being stupid, do not
            > pass
            > >> code on until it passes all these tests. See the "Three C's" notion.
            > These
            > >> are "Customer Tests".
            > >> Analyze every defect. When defects arise, figure out how each one
            > >> occurred. Since you are doing Acceptance Test-Driven Development, it is
            > >> evident that there is at least one missing test. Write that check, plus
            > all
            > >> the others that occur to you in light of the missing one. Beef up your
            > >> overall approach to ATDD, improving how you define new tests. Retrofit
            > old
            > >> tests as indicated.
            > >> Use Test-Driven Development. Developers write no line of code until they
            > >> have a failing test asking for that very line of code. These are
            > >> "Programmer Tests", sometimes called unit tests. As in step 3 above,
            > when
            > >> defects show up, they also indicate that TDD tests are missing. Write
            > >> those, learn from it.
            > >>
            > >> "Won't that take forever, all that testing? We'll never get done!"
            > >>
            > >> You'll never get done now! Your god-blessed bug database is filling up
            > and
            > >> your thrice-blessed programmers are piling more dead code on top of the
            > >> existing dead code. When were you planning to fix all these bugs, in
            > >> Fixtober, Bugvember, and Defectcember? I'm sorry, those months were
            > >> cancelled. Better fix them now.
            > >>
            > >> It takes less time to prevent a defect than to fix it. So invest the
            > time
            > >> to write the tests before you code, and don't stop coding until the
            > tests
            > >> work. Voila, bug production drops by an order of magnitude, even if you
            > >> completely suck at writing tests. If you get good at it, and with all
            > that
            > >> practice you will get good at it, and it'll drop by another order of
            > >> magnitude.
            > >>
            > >> In short, XP.
            > >>
            > >> This topic, and the answer, has been around a long time. A few articles
            > >> relating to this subject:
            > >>
            > >> http://xprogramming.com/articles/which-end-of-the-horse/
            > >> http://xprogramming.com/articles/expcardconversationconfirmation/
            > >> http://xprogramming.com/articles/where-can-we-reduce-quality/
            > >> http://xprogramming.com/blog/discovering-essential-technical-practices/
            > >>
            > http://xprogramming.com/articles/manual-testing-does-exist-and-it-is-bad/
            > >> http://xprogramming.com/articles/kate-oneal-handling-defects/
            > >>
            > >> Ron Jeffries
            > >> www.XProgramming.com
            > >> Perfectionism is the voice of the oppressor -- Anne Lamott
            > >>
            > >>
            > >> [Non-text portions of this message have been removed]
            > >
            > >
            > >
            > > --
            > > Steve Smith
            > > http://Ardalis.com/
            > > http://twitter.com/ardalis
            > >
            > >
            > > [Non-text portions of this message have been removed]
            > >
            > >
            > >
            > > ------------------------------------
            >
            > >
            > > To Post a message, send it to: extremeprogramming@...
            > >
            > > To Unsubscribe, send a blank message to:
            > extremeprogramming-unsubscribe@...
            > >
            > > ad-free courtesy of objectmentor.comYahoo! Groups Links
            > >
            > >
            > >
            >
            >
            >



            --
            Steve Smith
            http://Ardalis.com/
            http://twitter.com/ardalis


            [Non-text portions of this message have been removed]
          • Steven Gordon
            ... I would agree with offering advice, but I would prefer not to prescribe it. In practice, teams generally follow said advice much better if they own it. ...
            Message 5 of 24 , Mar 13, 2013
            • 0 Attachment
              On Wed, Mar 13, 2013 at 12:37 PM, Ron Jeffries <ronjeffries@...> wrote:

              > **
              >
              >
              > Hi Steven,
              >
              >
              > On Mar 13, 2013, at 3:16 PM, Steven Gordon <sgordonphd@...> wrote:
              >
              > > A process that attempts to make it impossible for people to produce
              > defects
              > > would be too prescriptive to be efficient or to produce learning or
              > > innovation. We would all much prefer a process that facilitates people
              > > learning to get better, but then such a process would allow defects along
              > > the way.
              >
              > Could you perhaps phrase this idea in such a way as to do two things that
              > this does not:
              >
              > First, offer advice on what one might do, rather than on what one ought
              > not do, and, second, offer advice that tends to lead to a continuing
              > reduction of defects?
              >

              I would agree with offering advice, but I would prefer not to prescribe it.
              In practice, teams generally follow said advice much better if they own it.


              >
              > Ron Jeffries
              > www.XProgramming.com
              > I have two cats, and a big house full of cat stuff.
              > The cats fight and divide up the house, messing up their own lives.
              > Nice work cats.
              > Meow.
              >
              >
              >


              [Non-text portions of this message have been removed]
            • Michal Svoboda
              ... Fair enough. But I would say that s a natural occurrence, or imperfection if you will. No-one is born with coding skills, we all learn. Now if or how big
              Message 6 of 24 , Mar 13, 2013
              • 0 Attachment
                Ron Jeffries wrote:
                > > ... as if there were other kinds of problems. ;-)
                > Oh, there are. Like if the team doesn't know how to write code that
                > works, and tests that demonstrate that fact.

                Fair enough. But I would say that's a natural occurrence, or imperfection
                if you will. No-one is born with coding skills, we all learn.

                Now if or how big this is a problem, depends on communication. If I don't
                talk about it or they don't listen, then problem grows. So I observe that
                problems in communication are able to create proportionally greater
                disasters than anything else.

                Michal Svoboda
              • Kay A Pentecost
                +1 ... magic.
                Message 7 of 24 , Mar 14, 2013
                • 0 Attachment
                  +1

                  > -----Original Message-----
                  > From: extremeprogramming@yahoogroups.com
                  > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Charlie
                  > Poole
                  > Sent: Wednesday, March 13, 2013 1:58 AM
                  > To: extremeprogramming@yahoogroups.com
                  > Subject: Re: [XP] Back of the Door Sticky Note Issue Tracking.
                  >
                  > Hi George,
                  >
                  > Maybe we should just say "Yes, we cheated. And we figured out a way to
                  > keep cheating, so that tests keep passing. Do you want us to stop?"
                  >
                  > Charlie
                  >
                  >
                  > On Tue, Mar 12, 2013 at 9:52 PM, George Dinwiddie
                  > <lists@...>wrote:
                  >
                  > > **
                  > >
                  > >
                  > > John,
                  > >
                  > > On 3/13/13 12:42 AM, John Carter wrote:
                  > > > On Wed, Mar 13, 2013 at 5:20 PM, George Dinwiddie
                  > > > <lists@...>wrote:
                  > > >
                  > > >> I've seen a team of ordinary programmers reach the state of
                  > > >> frequently shipping zero bugs (even measured after deployment), and
                  > > >> quickly taking care of the ones that escaped an iteration. It's not
                  magic.
                  > > >>
                  > > >
                  > > > This is the Very Interesting Answer which I would like to bring home
                  > > > to
                  > > the
                  > > > rest of the company....
                  > > >
                  > > > My colleagues are quite comfortable with the "lean manufacturing" no
                  > > queues
                  > > > answer, but plain flat out don't believe the "No Defect Magic" answer.
                  > > >
                  > > > So I'm looking for data / evidence / stories / books / papers to
                  > > > convince them that we could do better.
                  > >
                  > > Do you think that will convince them?
                  > >
                  > > It didn't even convince the organization around them. The comment on
                  > > their first release, when 92% of the release test scripts passed on
                  > > the first attempt, was "they cheated; they tested ahead of time." I
                  > > think it was the second or third release when they hit 100%.
                  > >
                  > > Yes, they tested, not always automated. They also had a sign on the
                  > > wall that said "Zero bugs, the new normal."
                  > >
                  > > - George
                  > >
                  > > --
                  > > ----------------------------------------------------------
                  > > * George Dinwiddie * http://blog.gdinwiddie.com Software Development
                  > > http://www.idiacomputing.com Consultant and Coach
                  > > http://www.agilemaryland.org
                  > > ----------------------------------------------------------
                  > >
                  > >
                  > >
                  >
                  >
                  > [Non-text portions of this message have been removed]
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to: extremeprogramming-
                  > unsubscribe@...
                  >
                  > ad-free courtesy of objectmentor.comYahoo! Groups Links
                  >
                  >
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.