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, its 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, arent 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 were going to do it. We
see the right thing to do, and were going to do it.
Its 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
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 wasnt 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
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.
From: dgery2000 [mailto:gery.derbier@...
Sent: Tuesday, July 29, 2003 7:59 AM
Subject: [scrumdevelopment] Re: Several Questions on Scrumming
--- In firstname.lastname@example.org
, Ron Jeffries
> I wouldn't hesitate to go well above 7, but 23 is probably too large
> > They should talk more, share more. I agree. It is a struggle I
> > to figure out how to address. The multiple scrum teams, again
> > back to Sprint goals/Release goals and the optimal number of
> > in a scrum team.
> Yes. But you are seeing the effect of the split. It puts a TERRIBLE
> in sharing. I would be quite willing to suffer the inefficiencies of
> 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.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/