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

RE: [scrumdevelopment] Digest Number 1114

Expand Messages
  • Mike Dwyer
    Jeff 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
    Message 1 of 2 , Sep 2, 2005
    • 0 Attachment
      Jeff 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."

      -----Original Message-----
      From: scrumdevelopment@yahoogroups.com
      [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mary Poppendieck
      Sent: Friday, September 02, 2005 11:13 AM
      To: scrumdevelopment@yahoogroups.com
      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.

      Mary Poppendieck
      Author of: Lean Software Development: An Agile Toolkit

      From: mike.dwyer1@...
      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
    Your message has been successfully submitted and would be delivered to recipients shortly.