9158RE: [scrumdevelopment] Digest Number 1114
- Sep 2, 2005Jeff and I have been talking about this for quite some time. At Patient
Keeper Jeff talks about a cache of tasks that are still being defined
outside of the Continuous Scrum. In doing this, Jeff applies the quality
filter before the workcenter (development) in classic Goldratt (The Goal)
At American Healthways, we need to show traceability (who, what, when how
long) for anything that impacts the revenue stream including the development
of business rules. Interestingly enough, when SOX came along we thought we
were going to be hammered. It turns out that the collaborative rapid,
delivery based Agile approach acts as a wrapper for many SOX issues, because
we had the CIO and CFO require that all backlog items be entered into a
tracking system so that SOX issues would be captured. This solved the issue
of getting business to use the product backlog for all requests.
Since we do this in a collaborative manner, the team as a direct impact on
what is approved for code and in doing so buttress the product owner when
dealing with the 'best judgement' tactic. It also helps move Scrum like
methods and Agile Practices out into the business community, as it the
fastest way to deliver credible requests.
While we are not yet at Jeff's full description of a "C" Scrum, we have seen
an order of magnitude improvement in both quality of backlog items as well
as volume of completed tasks. While this may sound like I am challenging
'yesterday's weather' as far as determining velocity, what I am finding out
- as Jeff has - that if you put your quality controls in place before you
work on a backlog item, you will go faster, and do better because many of
the reasons for delays have been filtered out. This has taken us from 'The
Goal' model to what is shaping up to be a 'Critical Chain' problem not
unlike Bryan Stalling and Tom Dorsey talked about at the last Gathering in
The approach we are going to use at American Healthways is to extend the
Daily Update into the business community and follow that with extending the
Scrum-Like methods into the business - effectively chasing down the
constraints by implementing Scrum-Like methods wherever a group is
identified as an impediment-constraint. Again, the assumed antipathy has
not always appeared, in fact the approach is being embraced in some areas
and mandated in others.
Very interesting to be in this.
Michael F. Dwyer
"Planning constantly peers into the future for indications as to where a
solution may emerge."
"A Plan is a complex situation, adapting to an emerging solution."
[mailto:firstname.lastname@example.org] On Behalf Of Mary Poppendieck
Sent: Friday, September 02, 2005 11:13 AM
Subject: RE: [scrumdevelopment] Digest Number 1114
In his presentation at Agile 2005, Jeff Sutherland notes that nothing is
allowed in the PatientKeeper development backlog until it is fully ready to
code. This means, for example, that a change in UI must be prototyped and
tested in a focus group before it may be considered for development.
I think this is similar to what you are suggesting here, Mike.
Author of: Lean Software Development: An Agile Toolkit
Subject: Re: Re: WIP
While getting the whip put down it the goal, a tactic that sometimes works
is to have management perform self-flagelation by strictly limiting the
amount of business assumptions the team and developers in particular can
This can done by simply deferring to the business, those business rules that
are not well enough understood to be expressed in boolean terms. Many times
the Product Owner (proxies in particular) has been squeezed by management to
"use your best judgement" and the team ends up being guided by the product
owner's 'best guess' unsupported by management.
This also helps filter out 'wish list' functionality as management can't
expect to see what they can't describe or vision well enough to build.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Yahoo! Groups Links
- << Previous post in topic