AW: AW: Ideal Cycle Time (was RE: [scrumdevelopment] Digest Number 1348)
- 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.JosefOn Saturday, March 18, 2006, at 8:18:01 AM, Scherer, Josef wrote:
Von: email@example.com [mailto:firstname.lastname@example.org] Im Auftrag von Ron Jeffries
Gesendet: Samstag, 18. März 2006 14:41
Betreff: Re: AW: Ideal Cycle Time (was RE: [scrumdevelopment] Digest Number 1348)
> "No one is allowed to change the Product Backlog (sic!)during the Sprint. The Product Backlog
> is frozen until the end of theSprint"
The /Sprint/ Backlog is frozen. I don't think the /Product/ Backlog
Wisdom begins when we discover the difference between
"That makes no sense" and "I don't understand". --Mary Doria Russell
- 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. :-)
--- In email@example.com, Tobias Mayer <tobyanon@...>
>Enterprise Scrum, to be very confusing. It implies that Scrum in it's
> I find all this discussion on type-A/B/C Scrum, Advanced Scrum,
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.
> Jeff Sutherland <jeff.sutherland@...> wrote:
> 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
> --- In firstname.lastname@example.org, 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
> > 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 itof a
> > 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
> > sprint.)this
> > 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.scrumdevelopment-unsubscribe@...
> > 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:
> SPONSORED LINKS
> YAHOO! GROUPS LINKS
> Visit your group "scrumdevelopment" on the web.
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of