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

RE: [scrumdevelopment] Re: Several Questions on Scrumming

Expand Messages
  • Mike Cohn
    Yeah--you would wonder that! :) -Mike ... From: Ron Jeffries [mailto:ronjeffries@acm.org] Sent: Thursday, July 24, 2003 11:16 AM To:
    Message 1 of 49 , Jul 24, 2003
      Yeah--you would wonder that! :)

      -Mike

      -----Original Message-----
      From: Ron Jeffries [mailto:ronjeffries@...]
      Sent: Thursday, July 24, 2003 11:16 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Re: Several Questions on Scrumming

      On Thursday, July 24, 2003, at 12:51:52 PM, Mike Cohn wrote:

      > My point was that there is at least some cost to packaging up the product
      > increment. Many of the wonderful XP practices are aimed at lowering that
      > cost. My point was just that it can never go to zero. If my example below
      > (1-day) is too long to illustrate it, just make it "one minute
      iterations."

      Hmm ... I wonder what it would take to make one-minute integrations work
      ...

      Ron Jeffries
      www.XProgramming.com
      Sorry about your cow ... I didn't know she was sacred.



      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Ken Schwaber
      Some comment on team size and management intervention: The optimal size of an agile team is about seven people. With this many people, experts can be combined
      Message 49 of 49 , Jul 29, 2003
        Some comment on team size and management intervention:
        The optimal size of an agile team is about seven people. With this many
        people, experts can be combined with non-experts to foster mentoring. With
        this many people, it’s easier to include all of the skills needed to
        effectively produce a complete increment of code at the end of the
        iteration. One coder, one designer, one tester, one documenter is already
        four people, so the number seven is quickly reached. Fewer people are more
        effective, with some people even advocating team sizes of three. In my
        experience, smaller teams are only effective when the increment purpose is
        restricted. For example, the increment might not include documentation, or
        the design work might be minimal. Or perhaps, the team consists of three
        truly outstanding individuals with all of the skills needed.

        A problem that occurs more frequently is an oversized team. I recently
        worked with teams of seventeen and fourteen people while implementing the
        Scrum agile process. At first, I thought that this might be acceptable; I
        felt that the teams would self-organize to make the size work. They did! The
        teams almost immediately started dividing themselves into smaller teams. In
        effect, the teams said, “You, management, aren’t smart enough to optimize
        our size, so we are going to optimize it ourselves. You gave us full
        authority on how to work within the iteration, and we’re going to do it. We
        see the right thing to do, and we’re going to do it.”

        It’s hard to fight the creativity these teams demonstrated, especially when
        they were right. The teams demonstrated the beauty of self-organization and
        emergence. They determined a flaw in the iteration setup and corrected it
        themselves.

        But, what was wrong with an oversized team? When I work with a team of seven
        people, I can see them bend forward to start sharing ideas. I see them
        exchange thoughts, work through problems, and learn from each other. When I
        observed these oversized teams, such an easy interchange wasn’t possible.
        For starters, the room had to be oversized to hold all the people. When
        someone at the far end of the room would say something, people at the far
        end of the room had trouble hearing them. Because the number was so great,
        side conversations tended to spring up; this added to the difficulty of
        hearing what was being said. So much was being said and so many ideas were
        presented that it was impossible for the various team members to keep track
        of everything that was going on.

        A solution to keeping track of everything could have been documentation. We
        could have required agenda, time slots for presenting ideas, taking meeting
        minutes, and providing meeting reports that everyone on the team could read.
        But that would undercut the value of face-to-face communications and the
        immediacy of intimate interaction. It would also have imposed an overhead on
        the entire process, exactly the opposite of what agile promotes.

        The larger, seventeen-person team spotted this problem itself and divided
        itself into four sub teams. These sub teams worked on parts of the
        functionality that were as orthogonal as possible; normally parsing
        requirements this way is a ScrumMaster and Product Owner responsibility, but
        the team proved itself equal to the task. Because a perfect orthogonal
        solution, with perfect cohesion and no coupling, was impossible, the team –
        on its own – devised a solution to keep their work synchronized while
        minimizing collisions. Each team had its own status meeting, called a Daily
        Scrum in the Scrum process, where the team spends fifteen minutes daily
        synchronizing work among team members. The team then held a “Daily Scrum of
        Scrums.” Representatives of each team met daily after the individual team
        Daily Scrums to synchronize work between them. They self organized into
        self-coordination.

        The teams presented this approach to its management and me; not for our
        approval - since they were using Scrum and were fully authorized to devise
        their own solutions - but for our information. I was amazed at their
        creativity. Not only had the team devised a workable solution, but also it
        was the same solution formally documented in the Scrum methodology for
        scaling development projects from the small to the large. Except, the team
        had never seen the Scrum methodology. Working on its own, the team had
        reached the same optimized solution within three days.

        -----Original Message-----
        From: dgery2000 [mailto:gery.derbier@...]
        Sent: Tuesday, July 29, 2003 7:59 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Re: Several Questions on Scrumming


        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
        <ronjeffries@a...> wrote:


        > I wouldn't hesitate to go well above 7, but 23 is probably too large
        for
        > coordination.
        > [...]
        > > They should talk more, share more. I agree. It is a struggle I
        have
        > > to figure out how to address. The multiple scrum teams, again
        goes
        > > back to Sprint goals/Release goals and the optimal number of
        members
        > > in a scrum team.
        >
        > Yes. But you are seeing the effect of the split. It puts a TERRIBLE
        crimp
        > in sharing. I would be quite willing to suffer the inefficiencies of
        a
        > larger team to get the better communication, in many cases.
        >

        In a experience report I made at the Agile Development Conference in
        June, I reported on the similar choices I made.

        The team is 22 people (3 domain experts / PM, 2 full-time testers, 2
        RDB progammer / DBA, 15 C++ developpers) and we used a methodology
        rooted in Crystal and Scrum (Alistair Cockburn actually came in for 2
        days shortly after the start of the project). We hold a scrum meeting
        every other day with the full team, about 30mn duration. I resisted
        splitting the meeting a couple of times during the project, favoring
        team interaction in order to get a *integrated system* and not a
        collection of different applications as the output of the project.
        Though it is tough, I found it is still manageable to hold such
        meetings and I am convinced of the strong benefit.

        Géry.





        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...

        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      Your message has been successfully submitted and would be delivered to recipients shortly.