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

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

Expand Messages
  • Brad Appleton
    ... Thanks Jeff! I remember reviewing some of the early SCRUM patterns papers in the late 90 s here in Chicago-land with Mike Beedle. And Mike was often
    Message 1 of 34 , Apr 2, 2006
    • 0 Attachment
      Jeff Sutherland wrote:
      > 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
      > 2007.

      Thanks Jeff! I remember reviewing some of the early SCRUM patterns
      papers in the late 90's here in Chicago-land with Mike Beedle. And Mike
      was often expounding upon how various ideas and principles from Complex
      Adaptive Systems theory and Multi-Agent Systems supported the various
      patterns systems of hyperproductive development he was working on.

      > 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
      > example:

      This sounds similar to the work Ron Crocker has done with his "Grizzly"
      method for Large-scale agile development. Basically, loosely coupled,
      but highly cohesive teams, with well defined protocols/interfaces, but
      allowing for separate "implementation" (the details of their development
      process could vary so each could self-organize without having to cowtow
      to a corporate "common process", just common interfaces and
      expectations), and minimizing noise/disruption between stations on the
      various communication channels.

      Sounds a lot like good O-O design applied to organazition of teams in a
      large project. Also sounds a lot distributed autonomous agents in a
      system needing clear agendas and "Simple Rules" (as Dee Hock uses the
      term) to produce intelligent emergent behavior with multi-scale effects
      (which is a phrase MikeB would use a lot back in those days :-).


      > 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
      > offshore
      > > > 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
      > >
      >
      >
      >
      >
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      >
      >
      > ------------------------------------------------------------------------
      > YAHOO! GROUPS LINKS
      >
      > * Visit your group "scrumdevelopment
      > <http://groups.yahoo.com/group/scrumdevelopment>" on the web.
      >
      > * To unsubscribe from this group, send an email to:
      > scrumdevelopment-unsubscribe@yahoogroups.com
      > <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>
      >
      > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
      > Service <http://docs.yahoo.com/info/terms/>.
      >
      >
      > ------------------------------------------------------------------------
      >

      --
      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
        implementations.

        > > 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.

        http://www.stsc.hill.af.mil/CrossTalk/2003/07/sheard.html

        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.

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