Summary of the First eWorkshop on
Agile Methods
April 8, 2002
Part 2
Managing Agile Development
Success Factors
The variables that affect agile development and what are
the success factors for agile development were another topic of discussion.
These are some of the comments from the participants:
Culture
§
Scott Ambler: The factors that affect agile development are
different depending upon the agile method chosen. The corporate culture, working
together and trust play an important role.
§
Ken Auer: Agile
is about taking control of your own destiny to the point that you can. Saying,
"If you work in a bog bureaucratic organization, agile is inappropriate" is a
cop-out. If someone is more interested in keeping their job than doing the right
thing, methods/approach is irrelevant.
People
§
Alistair Cockburn: Good people are key to success with big
teams
Communication
§
Scott Ambler: Process and organization – need to have a
communication vehicle (such as co-located teams – Ken Schwaber) in place.
In general, the group agreed that the following are the
success factors for agile development:
§
Negotiation: If people are willing to keep talking and
learning, you are, almost by definition, agile.
§
Ability to continuously learn
§
Responsibly responding to change.
§
Environment where rapid communication is enabled.
§
Team reasonably in charge of its own destiny (being allowed
to succeed).
§
People are valued over other factors
§
The team needs to be more than just able, it needs to
actually succeed. There needs to be a support network for each individual in the
team to make a contribution however small.
Alistair Cockburn made the following comment regarding the
success factors: There's a cost element to this. I used agile techniques on my
last book - the book came out sooner, but production cost more. Predictable
situation + low cost as driver -> less appropriate for agile. That's the only
one I can think of.
When is Agile appropriate or not appropriate?
There was also some discussion about when agile is and is
not appropriate. The comments of the participants were:
§
Scott Ambler: When the culture is not there. When the
development team is not in control of its own destiny.
§
Bil Kleb: In life critical systems (but found testing in XP
to be helpful for these types of systems).
§ Hakan Erdogmus and Joel Martin: We
believe that some agile methods are always appropriate. If safety is critical
and documentation is paramount (customer wants it), they just become added
tasks. The more emergent and rapidly changing the requirements, the more
appropriate agile methods are. However, that doesn't imply that agile methods
are not appropriate for more stable environments. Plus, there is always
technical uncertainty that you cannot eliminate.
Marv Zelkowitz observed that project time and schedule
don’t seem to be defining attributes for
when agile methods are appropriate and asked what are the defining attributes.
Scott Ambler and Gary Pollice agreed with him. Gary Pollice added that he believes that there
are many factors and the dependencies between the different
factors will be very complicated. In response to this discussion:
§
Randy
Miller suggested minimizing pain/risk.
§
Frank
Maurer: the ability to get fast feedback from the customer (which may be tricky
for embedded systems)
§
Kent
Beck said: Negotiation. If people are willing to keep talking and learning, you
are, almost by definition, agile. Scott Ambler and Ken Auer agreed.
§
Randy
Miller raised the issue that a case could be made that BDUF is talking and
learning.
§ Bil
Kleb added that "continued learning" is one of the fundamental differences
between "agile" and "others".
What are indicators of problems with Agile projects
The group also discussed indicators of problems with agile
projects so that management can make decisions on time in order to
minimize/mitigate risks. The group agreed upon the following indicators:
§
Ken Schwaber: During the daily meetings
§
Alistair Cockburn: When software is not being produced,
morale is down
§
Randy Miller: When we stop focusing on what is supposed to
be delivered
§
Gary Pollice, Scott Ambler: Activities that don't provide positive value
to the overall effort
§
Gary Pollice, Scott Ambler: when useless documentation is
being produced
§
Ken Schwaber: When the customer refuses to fund another
iteration
§
Peter Hantos: When you are getting behind on planned
iterations
People
Type of personnel needed for Agile projects
The type of personnel needed for Agile projects and their
role in the success of the agile development was another topic discussed during
the meeting. The comments were:
§
Ken Auer: We need high quality people. Doesn’t mean
necessarily experienced skilled people, but honest, collaborative people.
§
Scott Ambler: People must be responsible, ready to learn
and work with others.
§
Randy Miller: Experience helps too!
§
Gary Pollice and Randy Miller: Mentors and coaches come in
to help deliver the project (with inexperienced people)
§
Barry Boehm thinks that
the criterion is that for any success-critical issue, at least one person who is
listened to that has the time and expertise to resolve the issue.
§
Peter Hantos: team lead needs to be trained (at least),
external experts are useless in highly agile, tactical environments
Percentage of experienced people needed to bring the
project along
Participants agreed that a certain percentage of
experienced people are needed to bring the project along, however they were
uncomfortable with putting an exact number on the total number of competent and
experienced people needed for effective development. 25% was suggested as first,
but several of the participants felt that a range would be better.
§
Hakan Erdogmus and Joel Martin agreed with 25%, but would
reduce to 10% if rotating pairs, needs to be one person that everybody listens
to
§
Tim Mackinnon believed 33% expert developers are needed
§
Hakan Erdogmus and Joel Martin, Tim Mackinnon and Scott
Ambler agreed there must be 10 - 30% competent and experienced people on the
project for effective development
Definition of Competent
Scott Ambler raised the point that we need to define
competent. In response to his question:
§
Randy Miller: I
think if you know the most about something that makes you the expert on the
project
§
Ken
Auer: On most projects, the most “expert” depends on the task at hand.
§
Scott Ambler: Competent to me means that they have real-world experience
in the technologies, have built similar systems in the past, have good people
skills, good communication skills, ...
Training
The discussion on competence led to a discussion on
training. How much training is necessary?
Vic Basili raised the question whether agile methods require less formal training than traditional methods. Most participants (13) agreed that agile methods do require less formal training.
Hakan Erdogmus and Joel Martin and Bil Kleb think that
agile require less formal training for XP because of pair programming. Peter
Hantos mentioned that it is not training that is needed but a , a
fair and open, but "professionally" guided discussion. Gary Pollice thinks it's
probably less formal training, but more mentoring type training ... exploiting
tacit knowledge transfer that is needed. Alistair Cockburn
added that we should think of skills development instead of training. The mentor
helps individuals grow professionally, in techniques, insights, and method. Don
Wells pointed out that perhaps there is a difference between training and
re-training. The entire team can train it self by it self. But train it must.
Ken Auer observed that if you have honest/collaborative people, training is
relatively simple. Tim Mackinnon pointed out that training people to be
honest and collaborative is not so simple.
Hakan Erdogmus and Joel Martin mentioned that a participant in one of their XP course that had taken RUP training before found the XP one to be easier. Randy Miller mentioned that he has seen groups that have trained themselves on XP, but he has also seen it with non-agile methods like RUP. He believes there are enough materials for groups to train themselves on Crystal, SCRUM and FDD too. Scott Ambler has also seen groups being able to train themselves.
[Main Page] [Part 1] [Part 3] [Part 4]