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

Re: Scrum Testing time management

Expand Messages
  • Mary Poppendieck
    Sorry for the late response to this.... Shiego Shingo was the Industrial Engineer behind the Toyota Production System. He worked hand-in-hand with Taiichi
    Message 1 of 51 , Feb 27, 2006
      Sorry for the late response to this....

      Shiego Shingo was the Industrial Engineer behind the Toyota
      Production System. He worked hand-in-hand with Taiichi Ohno to
      develop the details of the TPS. He has written many books, none of
      which I could recommend since they are boring manufacturing stuff.

      But in the one book of his that I studied when I was in
      manufacturing, he says something that I think is very relevant to
      this discussion:

      Shiego Shingo said: Testing to find defects is waste. Testing to
      prevent defects is essential. His whole idea was to mistake-proof
      every step so that no mistake could move forward in the system, even
      for a moment. To me, this is what test-first is all about.

      I believe that if there are test-and-fix cycles at the end of
      development, even at the end of a Sprint, then the testing is
      occurring too late. If the purpose of testing is to find defects
      instead of to prevent them, and that testing is waste.

      Mary Poppendieck

      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
      <ronjeffries@...> wrote:
      > On Thursday, February 23, 2006, at 1:36:31 AM, Jeff wrote:
      > >> I can't speak for Scrum, but I think that having identified QA
      > >> people on teams is a second- or third-class practice.
      > > Um.. What does the above mean?
      > It means that I, Ron Jeffries, think that while having people who
      > are part of a QA organization, or who think of themselves as QA
      > people (or even who think of themselves as testers) on a team is
      > a bad thing, it is not the best thing.
      > > Is this coming from an XP perspective?
      > It's coming from my perspective.
      > You might now be wondering something that could politely be put as
      > "Why?" So I put this article up on my web site:
      > Designated QA People on the Team Ron Jeffries 02/23/2006
      > Recently on the Scrum list, I characterized the practice of
      > designated "QA" people on the team as a "second- or third-class
      > practice." Here's some expansion on that ...
      > http://www.xprogramming.com/xpmag/jatQAonTeam.htm
      > One of the most common problems I see Scrum teams have is the
      > inability to be "done" at the end of the Sprint. We have just heard
      > recently about having a whole 'nother Sprint to get things done.
      > More commonly I just see teams who get most of their items "90
      > percent" done, or who have a high defect rate.
      > The "fix" for this problem starts with testing. All the backlog
      > items need to be tested within the Sprint, if they are to be done
      > within the Sprint. (As I write this, I realize that one would think
      > that this would be obvious. Apparently it is not.)
      > One common solution is to add "testers" or "QA" to a team, and it
      > can improve things. However, it results in an inevitable testing
      > crunch, usually at the end of the Sprint. Since testing is hard to
      > estimate, the results are not ideal. Things improve, but it becomes
      > common for the testers not to be done, and there is even the
      > infamous "QA Sprint" that some teams use to "clean up" the work of
      > the preceding Sprint.
      > It turns out that what is going on is that testing is getting done
      > mostly at the end of the development cycle of each backlog item,
      > that it is being done primarily by the "testing people". This
      > results in a number of ill effects:
      > * Developers don't test very effectively. (*)
      > * A testing queue builds up, slowing things down.
      > * Defect fixing becomes a large and unpredictable part of
      > the team's work.
      > * The burn chart is incorrect to some unknown degree, resulting
      > in uncertainty about progress.
      > What seems to work better is to have the Whole Team focused on on
      > each story being fully tested by the end of the Sprint, rather than
      > letting the developers feel that they're done and "waiting for QA".
      > Teams with this focus wind up devising some very productive
      > approaches. For example, they'll have their testing experts work
      > early with the customers or product owners, to clarify up front how
      > a backlog item will be tested. This builds greater understanding of
      > what has to be done, which itself reduces defects.
      > Then, teams with a team focus on stories being tested will tend to
      > focus on each story until it is done, rather than the developers
      > screaming through as much code as they can, while testers struggle
      > to keep up, followed by developers fixing bugs late in the Sprint
      > or, worse yet, in the next one.
      > Finally, teams with this focus tend to develop much better
      > automation techniques, as everyone is faced with the drudgery of
      > manual testing, and everyone sees the value of repeating as many
      > tests as possible, as often as possible.
      > Therefore, while adding testing skills to a team is a very valuable
      > thing, I find that adding those skills by providing individuals
      > whose job is thought to be "testing" is not the strongest move. A
      > stronger move is to bring the whole team to the realization that no
      > feature, and no individual, is done until the testing is done.
      > -------------------------------------------
      > (*) Poor testing by developers is commonly thought to be an
      > trait of developers, or to be a psychological effect due to the
      > difficulty of effectively testing something one has created. The
      > primary cause, I think, is simpler. If there are testers on the
      > team, it is obviously the developers' job to give them things to
      > test, and the testers' job to tell the developers if their code
      > works.
      > ----------------------------------------------
      > Regards,
      > Ron Jeffries
      > www.XProgramming.com
      > Accept your conditions, but not your fate. -- Rod Walsh & Dan
    • Deb
      Mary, this raises an odd question: aren t our Backlogs queues? But we like our Backlogs. What is different about them? deb ... pretty ... Okay, so ...
      Message 51 of 51 , Mar 8, 2006
        Mary, this raises an odd question: aren't our Backlogs queues? But we
        like our Backlogs. What is different about them?

        --- In scrumdevelopment@yahoogroups.com, "Mary Poppendieck" <mary@...>
        > ...
        > Putting aside the theory of constraints, queuing theory says that things
        > flow faster if and only if you remove queues. In Lean, queues are
        > much regarded as evil and every effort is made to diminish them.
        Okay, so
        > you need a few short queues (TOC would put a queue only at a
        constraint) -
        > but they should be few and they should be short, and they should be
        > grudgingly as an impediment to flow. It is almost never a better idea to
        > queue work to be done later.
        > ...
        > Mary Poppendieck
        > www.poppendieck.com
      Your message has been successfully submitted and would be delivered to recipients shortly.