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

RE: [scrumdevelopment] Scaling Scrum

Expand Messages
  • Steven Gordon
    I agree with what you say here, but it seems at odds with your previous posting about the role of QA. Maybe I am misunderstanding your previous posting. If
    Message 1 of 80 , Feb 1, 2005
    • 0 Attachment
      I agree with what you say here, but it seems at odds with your previous posting
      about the role of QA.

      Maybe I am misunderstanding your previous posting. If not, one way to rationalize
      the two views is to pick my option 1 - you use QA as customer proxies whose
      understanding of what customers want is via information filtered through the product
      manager because of specific constraints of your situation (products for busy doctors).
      This explanation implies that this role for QA might not be a good idea for a project
      in a different context.


      -----Original Message-----
      From: Jeff Sutherland [mailto:jeff.sutherland@...]
      Sent: Tue 2/1/2005 4:37 PM
      To: scrumdevelopment@yahoogroups.com
      Cc:
      Subject: Re: [scrumdevelopment] Scaling Scrum


      Steve,

      Most of my companies have been product companies. The product owner is
      typically the product manager who spends about half his time with
      customers. We also try to get developers out to customer sites.

      In my current company, the customers are physicians. We can't get the
      physicians in the hospital to spend full time with a development team,
      so we hire them as product managers and they serve as product owners.

      They must test any new features against a carefully selected group of
      customer physicians before a feature can come off the product backlog
      into sprint backlog.

      In fact, we have created a special application we sell for $39 bucks
      on the web that is basically a full medical record on the Palm Pilot
      that includes most of the enterprise code we ship to our large
      customers. New features are introduced there and are available to over
      50000 users of the product. We get a tremendous amount of feedback
      this week which is very useful for validation before we drive the
      product backlog for the feature in a sprint backlog for release in the
      enterprise product.

      There are many ways to involve the customer. In web portal companies,
      they usually test market new features to a small subset of users and
      get real time feedback before they build for large scale distribution.

      In projects which are of a consulting nature, I've always had the
      customer right in the Sprint. For some products we have flown
      customers in from around the country for every Sprint review for a new
      product as we built it for them. That was a very successful exercise
      and a memorable and growing experience for some of the customers.

      Jeff Sutherland


      On Tue, 01 Feb 2005 16:20:20 -0700, Steven Gordon <sagordon@...> wrote:
      >
      > Jeff,
      >
      > Interaction with real users appears to be totally missing from your view.
      > It seems that your ideal is for QA to act as customer proxies based on
      > second hand information filtered by the "product owner".
      >
      > Is this lack of direct customer interaction and separate organizations
      > doing documentation and QA activities in parallel with development:
      > - the result of constraints in your particular environment,
      > - a deliberate reduction of agility in exchange for an increase in
      > efficiency, or
      > - something else entirely?
      >
      > Steven A. Gordon, Ph.D.
      > Manager, Software Factory
      > Arizona State University
      > PO Box 875506
      > Tempe, AZ 85287-9509
      > http://sf.asu.edu
      > (480)-727-6271
      >
      > -----Original Message-----
      > From: Jeff Sutherland [mailto:jeff.sutherland@...]
      > Sent: Tuesday, February 01, 2005 4:05 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: Re: [scrumdevelopment] Scaling Scrum
      >
      >
      > 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@...
      >
      > 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@...


      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



      _____

      Yahoo! Groups Links


      * To visit your group on the web, go to:
      http://groups.yahoo.com/group/scrumdevelopment/

      * To unsubscribe from this group, send an email to:
      scrumdevelopment-unsubscribe@yahoogroups.com <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>

      * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
    • 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.