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

Multi-Team Scrums as Multi-Agent Systems (was Re: Type A clarification)

Expand Messages
  • Jeff Sutherland
    Simplicity is good. As Einstein said, concepts should be as simple as possible and no simpler. He had to wade through a lot of complexity to get to e=mc^2
    Message 1 of 34 , Apr 1, 2006
    • 0 Attachment
      Simplicity is good. As Einstein said, concepts should be as simple as
      possible and no simpler. He had to wade through a lot of complexity to
      get to e=mc^2 though. I'm thinking about how to get rid of the A, B,
      Cs in the next revision of the Distributed Scrum paper.

      To get to Scrum initially, we reviewed over thirty years of software
      development research and tried to abstract best patterns from projects
      that worked exceptionally well in order to produce a hyperproductive
      development pattern. This was not a simple task. Research papers must
      say something new and they are always a little complex in the
      beginning. If a paper doesn't produce new thinking that has not been
      thought before, it will be rejected by any IEEE conference. Through
      feedback and discussion of a series of such research papers, the
      essence of new insight is simplified over time.

      In any event, I'd like to thank Brad Appleton for pointing out that
      agent theory may have something to say about why the SirsiDynix
      project was so successful and this provides a whole area of study for
      preparing papers for HICSS in January 2007 in Hawaii where Mary
      Poppendieck, Jean Tabaka, and I are leading a track on Agile
      development (please send papers and join us on the beach) or for Agile

      For example see Brad's first link below and you will find (among many
      papers) an analysis which likely explains why and how a Scrum of
      Scrums works well when it is structured properly. Minimizing
      communication overhead is at the core of Agile success. It was at the
      core of the Coplien's Borland Quattro paper which was the direct cause
      of the first Scrum daily meeting. Proving why certain communication
      patterns work is mathematically complicated but might be useful. For

      Minimizing Communication Cost in a Distributed Bayesian
      Network Using a Decentralized MDP

      In complex distributed applications, such as distributed
      interpretation, a problem is often decomposed into a set of
      subproblems and each subproblem is distributed to an agent
      who will be responsible for solving it. The existence of interactions
      between subproblems means that the agents cannot
      simply solve the subproblems individually and then combine
      local solutions together. In such systems, the amount of
      communication among agents required to guarantee global
      optimality or global consistency may be very significant.
      Thus, "satisficing" approaches have been developed that
      trade off optimality for reduced communication [4]. One
      approach is for agents to generate local solutions based on
      their own data and then transmit these high level solutions
      to other agents. Based on consistency and credibility of
      these local solutions, new local solutions may be generated
      or more detailed data sent until a sufficient level of consistency
      and credibility has been achieved among the agents.
      An important characterization of such distributed protocols
      is how much communication is required and the likelihood
      that the solution will be the same as what would be generated
      by an optimal centralized algorithm which uses all
      available information.

      This satisficing approach described by Agent research, which (in the
      Scrum world) may force Scrums to keep coming up with better solutions
      until they are credible at a Scrum of Scrums level, could be the basis
      of self-organization of a hierarchy of Scrum teams.

      In any event, researchers are interested in these things, whereas
      practitioners often don't want to hear about them as it interferes
      with the simplicity needed in practice. The dynamic interaction
      between both points of view helps facilitate Takeuchi and Nonaka's
      "knowledge creation by synthesis of contradictions."

      Jeff Sutherland

      --- In scrumdevelopment@yahoogroups.com, Brad Appleton
      <Brad.Appleton@...> wrote:
      > Jeff Sutherland wrote:
      > > Type A Distributed Scrum - teams run independently offshore
      > > Type B Distributed Scrum - teams are linked by Scrum of Scrums
      > > Type C Distributed Scrum - all teams have team members onshore and
      > > offshore and are linked by the daily Scrum meetings
      > I cant help but notice what seems (to me at least) to be a resemblance
      > to multi-agent systems. If we view each "team" as an "agent", then each
      > one of the above is a different type of cooperation & coordination
      > strategy for a set of distributed autonomous agents.
      > Perhaps the different types of "multi-team" Scrums could borrow some of
      > these strategy names rather than using 'A', 'B', 'C', etc.
      > See the following for some possibilities:
      > * http://dis.cs.umass.edu/
      > * http://en.wikipedia.org/wiki/Software_agents
      > * http://en.wikipedia.org/wiki/Multi-agent_system
      > --
      > Brad Appleton <brad {AT} bradapp.net>
      > Agile CM Environments (http://blog.bradapp.net/)
      > & Software CM Patterns (www.scmpatterns.com)
      > "And miles to go before I sleep" -- Robert Frost
    • 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.