Type A clarification
- Last year I use Type A, B, C in my Agile 2005 paper to describe the
amount of overlap in Scrum interations. For example, PatientKeeper
multithreads multiple Sprints through the same teams to ship 45 new
software releases a year.
This year, at risk of further confusing the uninitiated, I use Type A,
B, C to identify different types of distributed Scrum in my proposed
Agile 2006 paper which is currently in the review process.
Type A Distributed Scrum - teams run independently offshore
Type B Distributed Scrum - teams are linked by Scrum of Scrums offshore
Type C Distributed Scrum - all teams have team members onshore and
offshore and are linked by the daily Scrum meetings
Different results are achieved by these different types of
distribution. The Agile 2006 paper provides detailed data on the
highest performance large Java project ever recorded which was run
using a Type C distribution model and where XP experts applied XP
engineering practices under the Scrum team management process. So it
is a good paper for both Scrum and XP practitioners to read.
As to the quote referred to in a previous posting, it was taken
totally out of context and has nothing at all to do with Scrum. It has
to do with Type A distribution of teams that are not Scrum teams at all.
"The latest thinking in the Project Management Institute Guide to the
Project Management Body of Knowledge (PMBOK) models  is a spiral
waterfall methodology which layers the Unified Modeling Language (UML)
and the Rational Unified Process (RUP) onto teams which are not
cross-functional . This partitions work across teams, creates teams
with silos of expertise, and incorporates a phased approach laden with
artifacts that violates the principles of lean development . This
is an extreme Type A distribution model."
- Ron Jeffries wrote:
> Justin T. Sampson wrote:We could probably say the same about most Scrum and XP
> > I find it interesting and relevant that the CMM puts
> > engineering practices at Level 3, but planning and tracking
> > and such at Level 2. The intuition is that the planning
> > practices provide some amount of stability within which the
> > engineering practices can be effective.
> I wouldn't presume to guess what the SEI had in mind about
> putting those things at that level. Certainly in practice L2
> doesn't bring about the transformations that we like to think
> Agile does ...
> > At my current company I spent a year and a half evangelizingNah, it's Chet's fault.
> > XP to no avail, advocating the same approach -- to start by
> > introducing iterations and the planning game, and gradually
> > add the rest. But when I recently started talking about Scrum,
> > I sensed much more excitement, gears turning, pistons firing,
> > like maybe something will actually happen. But I'm still
> > advocating the *same* approach, starting with Scrum and then
> > continuing improvement within that framework; perhaps it just
> > seems safer to people to commit to Scrum first without
> > committing to all of XP.
> I wonder why that happens. Probably something about the way XP
> was presented, and the fascinating ill-informed backlash it
> received from people who hadn't a clue what it was about.
> My fault, I guess ...
> > I think that Scrum seems less radical than XP, and thereforeYes, I think that's what I was trying to say. XP gets some people
> > less threatening. But Ken's training was actually just the
> > kick in the pants I needed to realize that Scrum is every bit
> > as radical as XP -- if not moreso, because it cuts right to
> > the root of lean/agile development, a message that is
> > essential to XP but is often lost among the dozens of
> > practices: FIRST enable SELF-managing, CROSS-functional teams
> > delivering incrementally, and then all else will follow.
> I'm not here to argue Scrum vs XP ... I think all the Agile
> methods /in action/ are really the same thing expressed in
> different words.
> I am of the opinion that a Scrum team that is really successful,
> shipping running code every Sprint, will be found to be doing
> technical practices that go far beyond showing up every morning
> and answering the Questions Three. And those practices will have
> a lot of similarity across teams.
excited about Agile, and Scrum gets some other people excited
about Agile, but it's the same Agile either way. And in neither
case is Agile just a handful of (or 12 or 13 or 25) practices; it
is a commitment to fostering self-managing teams to creatively
solve the business's particular problems.
I'm hopeful that focusing on Scrum will help ease the transition
to Agile. And I'm worried that selling Scrum as easier than XP
will backfire because it isn't.