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

Re: [scrumdevelopment] Scaling Scrum

Expand Messages
  • Jeff Sutherland
    Scrum is very clear that QA people should be assigned to sprints. My view is that: 1. Documentation should be assigned to the product owner to document the
    Message 1 of 80 , Feb 1, 2005
    • 0 Attachment
      Scrum is very clear that QA people should be assigned to sprints.

      My view is that:

      1. Documentation should be assigned to the product owner to document
      the user experience. This is the first draft of the documentation.

      2. QA people should work from step 1 to define their test cases.
      Development should work with them to understand the user experience

      3. Developers should write their tests. In the first Sprint in 1993 we
      hired a developer to specifically automate component testing who
      worked with tradition QA people. So he wrote the component test
      harness. Developers wrote tests to test individaul components.

      4. Developers should code to the tests

      5. QA should be testing during the sprint. Doc should be refining the doc.

      6. There should be minimal work required at the end of the Sprint to
      package working software that is usuable.

      This was the kind of scenario we worked at in the first Scrum in 1993.
      We are still trying to get there.

      Jeff Sutherland


      On Tue, 1 Feb 2005 15:47:02 -0500, Ron Jeffries
      <ronjeffries@...> wrote:
      >
      > On Tuesday, February 1, 2005, at 9:39:33 AM, John Keane wrote:
      >
      > > I guess the thing that I don't understand about the functions that you
      > > mention is why can't that be handled w/n the main sprints? What is the
      > > need for a separate QA function? I would think that you would want to
      > > have the QA group as tightly integrated into the main sprints as
      > > possible.
      >
      > That's certainly my view (as I suspect you know ;->). The QA
      > functionality needs to be there, certainly. And as much of the
      > feedback as possible wants to be inside the current sprint.
      >
      > > We have been doing SCRUM and haven't gotten there completely
      > > but that is the drum that I am beating w/ my team. I manage our team of
      > > QA engineers here and we are going in an entirely different direction
      > > from an independent QA function. I think it is a testimony to SCRUM how
      > > well it functions in almost any environment; however I am trying to move
      > > my team to more of an xp model with the QA function closer to the
      > > construction task.
      >
      > This seems to be happening more and more. Scrum is silent on just
      > how to develop and test, and the XP canon includes some good ideas
      > that more and more people are adopting as part of their Scrum
      > process.
      >
      > > I would love to say that we are completely there,
      > > but that isn't the case today. The way we currently solve it is that we
      > > have the main sprints and we tack on a release sprint at the end. The
      > > intent of this release sprint is to move the code from dev to out
      > > Production Test environment.
      >
      > This is not uncommon. It might be nearly universal. I believe that
      > the team should be able to get to the point where any CD off the
      > stack is shippable, but for many teams that's kind of a limiting
      > state they never get to. There's always something to clean up.
      >
      > If I were doing a one-week iteration, I'd be more comfortable with a
      > release iteration than with a one-month one. That's a long time to
      > wait with no new functionality. (I'm not a patient man.)
      >
      > > This is as much for IT as it is QA, but
      > > the intent is that most of the new functionality is already tested
      > > before we enter the release sprint. In the final phase we handle the
      > > regression and environment related testing. In the future, I really
      > > want us to be developing a large suite of automated tests ala xp and
      > > using the regression period for only exploratory testing. I think the
      > > tools that we can use to get there is XP, so we are going to prototype
      > > it on one team in the coming months.
      >
      > I'm delighted to hear that! :)
      >
      > Ron Jeffries
      > www.XProgramming.com
      > Make it real or else forget about it -- Carlos Santana
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      >
      >
      >
      >


      --
      Jeff Sutherland, Ph.D.
      CTO PatientKeeper Inc.
      Certified ScrumMaster Practitioner and Inventor of the Agile Scrum Process
      Microsoft Business Framework Advisory Council
      Object Management Group/HL7 Liaison Committee
      Co-Chair, HL7 Orders and Observations Technical Committee
      Co-Investigator, Operating Room of the Future, Univ. of Maryland Medical System
      617-947-7400 mobile
      jeff.sutherland@...
    • kschwaber
      Jeff Sutherland and I are concerned. Many organizations are now trying to scale Scrum to larger projects and to entire organizational units, reaping the
      Message 80 of 80 , Oct 30, 2014
      • 0 Attachment

        Jeff Sutherland and I are concerned. Many organizations are now trying to scale Scrum to larger projects and to entire organizational units, reaping the benefits they have seen in smaller Scrum initiatives. 


        Unfortunately, there isn't a lot of guidance on how to do this. This has given rise to IBM's methodological response to DevOps, and to commercial one-size-fits all methodologies like SAFe and DAD. 


        To read more about how we intend to fill this need in a manner consonant with the Agile Manifesto and the principles of Scrum, I refer you to a blog I wrote at Scaling Scrum.

         

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