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

Type A clarification

Expand Messages
  • Jeff Sutherland
    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
    Message 1 of 34 , Mar 25, 2006
    • 0 Attachment
      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 [2] 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 [3]. 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 [4]. This
      is an extreme Type A distribution model."

      Jeff Sutherland
    • Justin T. Sampson
      ... We could probably say the same about most Scrum and XP implementations. ... Nah, it s Chet s fault. ... Yes, I think that s what I was trying to say. XP
      Message 34 of 34 , Apr 10, 2006
      • 0 Attachment
        Ron Jeffries wrote:

        > Justin T. Sampson wrote:
        > > 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 ...

        We could probably say the same about most Scrum and XP

        > > At my current company I spent a year and a half evangelizing
        > > 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 ...

        Nah, it's Chet's fault.

        > > I think that Scrum seems less radical than XP, and therefore
        > > 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.

        Yes, I think that's what I was trying to say. XP gets some people
        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.

      Your message has been successfully submitted and would be delivered to recipients shortly.