Re: [scrumdevelopment] Scaling Scrum
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
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.
On Tue, 01 Feb 2005 16:20:20 -0700, Steven Gordon <sagordon@...> wrote:
> 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
> -----Original Message-----
> From: Jeff Sutherland [mailto:jeff.sutherland@...]
> Sent: Tuesday, February 01, 2005 4:05 PM
> To: email@example.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
> 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
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.