Summary of the First eWorkshop on
Agile Methods
April 8, 2002
Part 1
Definition
Early in the meeting, there was some discussion about the
definition of agile software development.
§
Ken_Schwaber suggested the following definition: An agile
method is iterative, incremental, self-organizing, and emergence. It
must include all of these attributes; otherwise it is a “lightened defined
process”.
§
Barry Boehm suggested using the 4 values and 12 principles
described in the Agile Manifesto (http://www.agilemanifesto.org/) for the
eWorkshop. Almost everyone – 15 participants – agreed to go along with this
definition for the eWorkshop.
Despite this agreement, later in the eWorkshop there was
more discussion about the definition. Marv Zelkowitz questioned whether there is
any common definition or is it’s just a new buzzword. In response to his
question, Ken Schwaber said: “Yes
... it is based on empirical methods rather than defined methods. Defined
methods are when you plan what you want and then enforce it. Agile, you lightly
plan what you want and then adapt to what you get. Self-organization,
emergence.”
Size of projects using Agile Methods
The first topic of the eWorkshop was the size of projects
that are better suited for agile methods.
What size teams people have seen?
In answering the question: “What size projects have you
successfully worked with? References?” The participants responded with the
following examples:
§
Alistair Cockburn: 6, 18, 45 and 90 people. These are
referenced in his book (“Agile Software Development”)
§
Tim Mackinnon: 3, 6, 12 people using XP and 8 and 25 (with
sub-teams) using Agile.
§
Ken Auer: 12 using pure XP and several smaller, 150+ with a
12 person subgroup using XP.
§
Ken Schwaber: OOPSLA workshop: unable to rule out any types
of projects (small to large and all types of projects) and 800 person team at
IDX (teams coordinated around product lines all using agile - scrum). There was
a project plan used to guide all teams. Teams are decomposed into small-sized teams.
They coordinate using scrums of scrums or have teams with individuals from
multiple product lines. Teams are small for self-organizing purposes, but teams
of teams can be formed to scale up.
§
Don Wells: 150 (mixed methods)
§
Scott Ambler: 4-8, 25-30, several hundred people (but only
one subgroup was “reasonably agile”)
§
Frank Maurer: In a university setting, small teams work
effectively.
Strategies for scaling up to use these methods with larger
teams
Randy Miller raised the point that size is not an issue
specific agile development. It’s a best practice for any type of development to
break into smaller teams.
Alistair Cockburn said size is an issue. As size grows,
coordinating interfaces becomes a dominant issue. Agile with face-to-face breaks
down (becomes more difficult/complex) past 20-40 people (interface becomes an
issue). Most people agreed (12 participants), but think that this statement is
true for any development process.
Following this discussion on size of projects, the
participants discussed the interface issues of using teams of teams.
§
In Ken Schwaber’s 800-person team they handled the
interfaces using “scrums of scrums” where the senior people on the teams met or
teams with members from multiple product lines. Part of this project is
documented in Jim Highsmith’s book (Agile Software Development Ecosystems: Problems, Practices,
and Principles, Addison-Wesley, 2002)
§
Scott Ambler mentioned that a core team
responsible for the glue is necessary. These people work actively with the
subteams, but also work on core architecture/standards.
§
Tim Mackinnon said that at OTI
they relied on yearly conferences to align interfaces, 3-month internships
(rotation of teams) – more to build trust in each other; Interfaced with emails,
conference calls, and test case results.
§
Alistair Cockburn said that Ron
Crocker's "Grizzly" method from two large Motorola projects is an example –
large teams have to do agile differently to make it work. The only example of a
"large" international project run with agile that he has is Ron Crocker's. The
mechanisms he (Ron’s) used were fundamentally different than his (Alistair)
face-to-face ones, but otherwise fit all the principles. It was as agile as he
(Alistair) could imagine for that group (more, in fact). Crocker’s large project used simulators and stubs, three cross-project
subteams with international representation – these teams met to keep in sync.
The book is still in progress, but XP
2001 in Sardinia and JAOO 2001 in Denmark have papers and slides.
§
Gary
Pollice concluded that projects of projects are treated like modules that have
interfaces to the others.
Ken Auer mentioned that having subgroups of larger projects doing “agile” improves coordination effort for others. He was part of a 150+ person project which was chaos except the 12 person sub-group he led which was certainly "agile" and made real progress and started making coordination efforts with others happen.
Suggested reference: Scott Ambler suggested his Agile Architecture essay as good reference for this topic.
[Main Page] [Part 2] [Part 3] [Part 4]