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

Re: [scrumdevelopment] Re: task switching

Expand Messages
  • Eric Deslauriers
    - What s your team s definition of Done ? - Has your team bought into that? How do you know? - Is your QA team automating tests or manually running them? If
    Message 1 of 13 , Sep 3, 2007
    View Source
    • 0 Attachment
      - What's your team's definition of "Done"?
      - Has your team bought into that? How do you know?
      - Is your QA team automating tests or manually running them? If they're doing things manually, IMHO, they cannot be part of the Sprint. They can't attain the velocity required to even keep up. I do QA, and that's IMHO.

      If QA members are part of your Sprint project team, saying Dev is creating a regression suite for QA is like saying a father "babysits" his children when the mother is away from home. BS. One team means one team.

      Scrum is about doing the right thing. Not telling the manager that you feel it's not working out... Hmm? Right for the project, or right for the company culture, or...? Reality of a situation can be a tough cookie when trying to do the right thing, but sometimes how you put it can get the point across while allowing you to remain politcally safe.

      Some of the training classes are pretty lame, I'll grant you that.

      1:5 ratio (2 QA, 10 dev) can be hard to keep up with, or it can be easy - it depends on the project. Don't worry about ratios, first make sure the QA folks are doing the right work, then size the work and staff for that. QA:Dev ratios are a load of hooey - it's all about the work.

      WHAT are your QA testing for? The User POV, or the Unit POV? If Unit, no wonder they can't keep up. QA should focus on how the user will use the product (functional testing, not to be confused with testing a function (aka method) but rather how the functionality works). Dev should focus on unit testing it. That's part of delivering quality to other members on their team (including devs who rely on their functionality for their own work).

      This is a common miss, and can dramatically impact QA velocity.

      Also, QA should be staffed with very strong OO developers who can create a framework for reusability across tests. If not, here's another reason they can't keep up. It's amazing how a strong OO person can go through QA tests and refactor them, gaining significant reusability and streamlining the work significantly.

      Just some thoughts.

      HTH,
      Eric D

      On 8/29/07, Keith Sader <ksader@...> wrote:

      Is there anything the developers can do to put more quality in before going to QA?  I.e. TDD, BDD or some such?  How about generating a regression test suite for QA?

      In response to the "quotes", there's learning and then there's doing.  I don't think I've ever seen a "pat answer" to many problems.

      If your manager won't accept that things aren't working, then you have another problem - Management by wishful thinking, and I don't think there's a cure for that :-)

      On 8/29/07, quinton@... < quinton@...> wrote:

      Actually, the only big problem we had before having Agile "brought in" was
      a quality issue.

      We did not have enough QA - I think that's why we had the quality issues -
      there were two testers testing the code written by 10 developers.

      The SM's are new, but we cannot complain about them, nor can we have them
      fired - the new Manager that brought in Agile brought in the SM's too.
      We don't dare tell the new Manager that things are not working - that
      would imply that he was incompetent.

      We've been asking for companies that are using Scrum / Agile - but the
      coaches were "by the book" and not into naming names. When problems came
      up, they recited lines from books - just like you can imagine a robot
      doing - and then pretended the problem went away



      --
      Keith Sader
      ksader@...


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