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

AW: AW: Ideal Cycle Time (was RE: [scrumdevelopment] Digest Number 1348)

Expand Messages
  • Scherer, Josef
    That s what his book says! A came across this twice, when reading the book and the first time I though it must be a mistake and the Sprint Backlog is meant
    Message 1 of 36 , Mar 18, 2006
      That's what his book says!
      A came across this twice, when reading the book and the first time I though it must be a mistake and the Sprint Backlog is meant instead.
      But then I found this again in Appendix A on the rules of Scrum! So I thought it cannot be a misprint.
      I'm going to ask him on Monday.

      Von: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] Im Auftrag von Ron Jeffries
      Gesendet: Samstag, 18. März 2006 14:41
      An: scrumdevelopment@yahoogroups.com
      Betreff: Re: AW: Ideal Cycle Time (was RE: [scrumdevelopment] Digest Number 1348)

      On Saturday, March 18, 2006, at 8:18:01 AM, Scherer, Josef wrote:

      > "No one is allowed to change the Product Backlog (sic!)
      during the Sprint. The Product Backlog
      > is frozen until the end of the

      The /Sprint/ Backlog is frozen. I don't think the /Product/ Backlog
      is frozen.

      Ron Jeffries
      Wisdom begins when we discover the difference between
      "That makes no sense" and "I don't understand". --Mary Doria Russell

    • rhythmstar
      It seems to me that the desire to enumerate and examine some variations of Scrum practice addressing specific contextual constraints is a Good Thing. However,
      Message 36 of 36 , Mar 26, 2006
        It seems to me that the desire to enumerate and examine some
        variations of Scrum practice addressing specific contextual
        constraints is a Good Thing. However, I suggest that the apparent
        implementation method, "type-A/B/C Scrum", is flawed -- it is a
        confusing and arbitrary naming system that none of us (I hope) would
        use in code. Why use it in Scrum meta-programming? Worse, by having
        these new flavors introduced essentially from 'on high', there is the
        risk of a New Coke style marketing faux pas, which would help no one.

        The essential Scrum principles as described in Ken's book(s) I think
        are great. However, there are a variety of challenges when trying to
        apply these principles outside of a colocated development group in a
        small ISV or consulting shop. Dealing with distributed teams, multiple
        teams and distributed multiple teams are core practice issues.
        Therefore, it seems that core practice principles ought to be used in
        designing and evaluating strategies to address such contexts.

        For example, one practitioner in Santa Barbara reported that making
        all the team members equal in terms of communication channel was key
        to making distributed teams work. Rather than have some folks in a
        room and others dialing in, he elected to have everyone dial in and
        found it worked better. Not better than colocation, but better than
        partial colocation. There might be a core principle... something about
        'equality of bandwidth'... lurking in there. However, does that mean
        he is practicing something other than Scrum, like New Scrum? I think
        not. He has just done some creative work towards the application of
        Scrum when you cannot have everyone in the same room.

        As for transitional strategies, which some of the "Type A" talk seems
        to be about, these are particularly confusing when referred to as an
        actual kind of Scrum. They are not, if we are to use normal concepts
        of typeness. All in, I think I'd rather see these things referred to
        more along the lines of Transitioning to Scrum, Scrum in the Virtual
        Office, or Scaling Scrum. Static typing is still not the answer. :-)

        Bill House

        --- In scrumdevelopment@yahoogroups.com, Tobias Mayer <tobyanon@...>
        > I find all this discussion on type-A/B/C Scrum, Advanced Scrum,
        Enterprise Scrum, to be very confusing. It implies that Scrum in it's
        original form is deficient. It isn't. It is only deficient if people
        practice it in deficient ways. Adding more rules, and categorizations
        will not solve that - in fact, I wonder if all these new
        categorizations will make it more deficient, as people (like me)
        struggle to understand the rules of each type. With such focus on
        process, we are almost certain lose the focus on people.
        > Tobias
        > Jeff Sutherland <jeff.sutherland@...> wrote:
        > Mike,
        > I think I am in agreement with you here.
        > We are positing the goal of a Type B Scrum as focused on the release
        > of a product set, usually to multiple market targets. This often takes
        > more than one Sprint. Changing the Product Backlog in the middle of
        > the Sprint would generally cause unnecessary disruption in flow, other
        > than a little wiggle room as requirements are clarified during a Sprint.
        > My Type C Scrum paper presented at Agile 2005 defines "done" at the
        > end of the Sprint as live at multiple customer sites. The Product
        > Backlog must be allowed to change if the customer will not go live
        > without minor enhancements identified during acceptance testing, or if
        > the customer mix changes during the Sprint. Failure to change the
        > Product Backlog when required will result in failure of the Sprint, a
        > huge disruption of flow. So I would leave Type C as the "extreme" case.
        > A 3 person team putting out a web site every two weeks is 26 on the
        > complexity scale. Obviously, they can succeed very well with Type A.
        > Perhaps we should insist on more than one team and more than one
        > product or raise it to 50.
        > However, even in the 3 person team case, properly investing in the
        > backlog to get it "ready" for the next Sprint will improve throughput
        > and reduce flow disruption. If this is done well, it will start to
        > move towards a Type B implementation.
        > I use Ken's slides for CSM training to stay completely aligned with
        > what he is communicating. In their current state, they are a Type A+
        > Scrum as they address scaling issues and preparing the next Sprint
        > Product Backlog during the current Sprint. However, they are focused
        > on new ScrumMasters and we have to work on keeping the basics clear
        > and simple.
        > The paper I just submitted to Agile 2006 and put up on the
        > Scrumtrainer list on Distributed/Outsourced Scrum showed 56
        > experienced Agile developers using Scrum with XP principles
        > distributed across the U.S., Canada, and Russia was just about as
        > productive as your Java Scrum of a few people in one location in the
        > User Stories book. Some of their practices are counterintuitive to
        > what we teach in the standard CSM course. These new findings need to
        > be addressed with experienced ScrumMasters. I think they go well in a
        > Type B course.
        > Jeff Sutherland
        > jeffsutherland.com/scrum
        > --- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@> wrote:
        > >
        > > Jeff--
        > > I'm struggling to understand the differences among all these new
        > > types of Scrum so I appreciate you taking the time clarify these
        for us.
        > >
        > > Type A is what Ken has written about and the Product Backlog Items
        > > (PBIs) are fixed for the duration of the sprint.
        > > Type B allows PBIs to be swapped in and out.
        > >
        > > Type B then takes the Extreme Programming approach to change.
        > >
        > > If this is the case then I think Type B loses one of the key
        > > of "classic Scrum" (or Type A as you're calling it). I have found it
        > > very beneficial for teams to know that what is selected for the
        > > sprint is what they are committed to. They can tear the system apart
        > > for 19 days as long as they put it back together on the 20th (of a
        > > four-week sprint). They can work without fear that the business will
        > > redirect them daily, thereby creating waste. Similarly, the business
        > > is trained to have to put serious thought into priorities because
        > > they will stay fixed for a short period of time. I've always found
        > > these to be huge advantages over the XP approach of "as long as we
        > > haven't started on a feature, we'll swap a new one in for an old
        > > one." Do you not find some drawbacks in these regards in Type B?
        > >
        > > (Caveat: Depending on how well the developers and product owners are
        > > working together the strictness of saying no to a change can be
        > > reduced even in classic Scrum even as I advocate it. However, the
        > > intent and goal is that we find a high priority set of features and
        > > build them. Some refinement of our understanding is natural because
        > > of the way PBIs are intentionally not fully defined by the start
        of a
        > > sprint.)
        > >
        > > As for complexity metric: Are you really saying that a 3-person team
        > > who puts out a website every two weeks /needs/ Type B? As in, they
        > > cannot succeed with classic Scrum as defined in Ken's books? That
        > > doesn't seem realistic at all and there are many companies doing
        > > without Type B.
        > >
        > > Thanks,
        > > Mike Cohn
        > > Author:
        > > Agile Estimating and Planning
        > > User Stories Applied
        > > www.mountaingoatsoftware.com
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > Scrum
        > ---------------------------------
        > Visit your group "scrumdevelopment" on the web.
        > To unsubscribe from this group, send an email to:
        > scrumdevelopment-unsubscribe@yahoogroups.com
        > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
        > ---------------------------------
      Your message has been successfully submitted and would be delivered to recipients shortly.