Content uploaded by Jutta Eckstein
Author content
All content in this area was uploaded by Jutta Eckstein
Content may be subject to copyright.
Panel
Xtreme Programming and Agile Coaching
Steven Fraser (Impresario)
Independent Consultant
Rachel Reinitz (Chair)
IBM
Jutta Eckstein
Independent Consultant
Joshua Kerievsky
Industrial Logic
Rob Mee
Pivotal Computer Systems
Mary Poppendieck
Agile Alliance
ABSTRACT
This panel brings together coaches to discuss all aspects of the prac-
tice – how to become a coach, choosing a coach, and describing
what is to be an (in) effective coach. A coach watches, provides
feedback, and suggests subtle direction. The coach may be more –
for example – an architect or team lead. The panelists will describe
their positions and offer feedback. Panelists were asked to offer
responses to three questions:
• How did YOU become a coach?
• What’s the toughest thing you’ve had to do as a coach?
• What’s your advice for teams looking for a coach?
Categories & Subject Descriptors:
D.2.1 [Software Engineering]: Requirements/Specifications:
Elicitation methods
K.6.1 Project and People Management: Management techniques
K.7.1 [The Computing Profession]: Occupations
General Terms: Design, Human Factors, Management
Keywords: Coaching, Team Building, Mentoring
1. Steven Fraser, sdfraser@acm.org
Steve Fraser (panel impresario) is an independent consultant in
Santa Clara California. Until 2002, Steve served fifteen years in a
variety of cool software technology program management roles at
Nortel Networks including: Process Architect, Senior Manager (Dis-
ruptive Technology), Process Engineering Advisor, and Software
Reuse Evangelist. In 1994 he served a year as a Visiting Scientist at
the Software Engineering Institute (SEI) collaborating with the Ap-
plication of Software Models project on the development of team-
based domain analysis techniques. Steve is an avid operatunist and
videographer.
Coaching is about teamwork, motivation, communication, skills and
strategy. Coaches help team members become a cohesive unit, un-
derstand the “rules-of-the-game”, facilitate interaction, optimize
skills, and build motivation towards common goals. Depending on
the team and their role, coaches develop and execute tactics and
strategy in much the same fashion as sport team coaches. Interest-
ingly two distinct coaching roles have emerged – the manager as
coach, and the consultant as coach.
2. Rachel Reinitz, rreinitz@us.ibm.com
Rachel Reinitz (chair) is a Senior Consultant with IBM Web Sphere
Services focusing on Web Services. She is also an experienced eX-
treme Programming coach who has used XP practices for four years.
Rachel advises customers on incorporating web services into their
applications and on incorporating Agile/XP practices and tools into
their development processes. Rachel spent a year as technical lead
for supplier integration at the B2B marketplace builder, Ventro
(Chemdex) and two years as an XP independent consultant.
3. Jutta Eckstein, www.jeckstein.com
Jutta Eckstein is an independent consultant, XP coach and trainer
from Munich, Germany. Jutta’s experience with agile processes
developed over ten years developing object-oriented applications.
Jutta has worked with teams of different sizes mainly in the finance
industry to help them use agile processes. Besides engineering soft-
ware she has designed and taught OT industry courses. Jutta trained
as a teacher and experienced leading many train-the-trainer pro-
grams in industry. She focuses on techniques which help teach OT
and is a main lead in the pedagogical patterns project. She is cur-
rently writing a book on Scaling Agile Processes, which will be
published in 2003. She is a member of the Agile Alliance and a
supporter of the Manifesto of Agile Software Development
(http://www.agilealliance.org). Jutta uses the team’s best practices as
a starting line. Interviews are an excellent technique for mining the
team’s best practices. Alternatively one can use a specific agile
process, such as XP as a starting line allowing for deviations where
necessary. Although as a coach you might have experienced XP as
the ideal process for a specific team, it might not work for a different
team. Be flexible in the process as long as it supports the overall
goal since working software providing the highest business value to
the customer.
Every team and every team member buries a wide range of good and
bad practices also concerning software development processes. As a
coach it is very important to mine this knowledge and use it for
defining the team’s own process. Thus it is much more important to
respect the experiences of the team than the experiences of some
process methodologist. Of course the knowledge of colleagues and
other process methodologists is a great source for filling the gaps in
the team’s own process and for improving it. Regular project retro-
spectives after really short iterations help to find these gaps and the
necessary improvements. As soon as the team trusts in the process
and knows how to make any necessary changes the coach needs to
step out – since the team can only organize itself when it really gets
the responsibility for doing so. The coach has to ensure to lead the
team towards self-organization by leaving the team alone as early as
possible. The customer is the key person for making the team suc-
cessful. Thus the customer needs additional support from the coach
for mastering this burden.
I became a coach after several years as an on-site/off-site developer.
When I first started with ParcPlace, I was a “fire-fighter” for cus-
tomers. After a time, some of these customers decided to call me
before their fires started!
Copyright is held by the author(s)/owner(s).
OOPSLA’03, October 26-30, 2003, Anaheim, California, USA.
ACM 1-58113-751-6/03/0010.
265
My toughest challenge was a decision on whether to coach a project
with about 200 people. I finally decided to do it. At the time, I was
absolutely convinced that success comes only with small teams.
However, now I’ve had good experiences with teams of 50 - these
teams still seem small. The 200 person project will be a win-win
situation - if the project succeeds, it will be through my coaching
skills, while if it fails – I’ve validated my prediction.
If you seek a coach, I absolutely recommend one with strong social
skills rather than simply technical skills. I have never seen a project
fail because of technical reasons. The coach has to be a catalyst, a
facilitator, an ombudsman, a team player, and someone able to make
hard decisions.
4. Joshua Kerievsky, www.industriallogic.com
Joshua Kerievsky has been programming professionally since 1987
and is the founder of Industrial Logic, a company specializing in
Extreme Programming (XP). Since 1999, Joshua has been coaching
and programming on small, large and distributed XP projects and
teaching XP to people throughout the world. He is the author of
numerous XP and patterns-based articles, simulations and games,
including the forthcoming book, “Refactoring to Patterns.”
To be a great XP coach, you must be fearless. Fearlessness comes
from knowing your stuff, walking the walk, telling it like it is, taking
risks, embracing change, learning from failure and loving what you
do. Fearless XP coaches don’t ignore critical problems, such as
personality conflicts, poor design decisions, insufficient customer
support or uncomfortable work environments: they courageously
help programmers, customers and managers apply XP’s values and
practices to solve problems and iterate to success.
5. Rob Mee, robmee@ieee.org
Rob Mee is a consultant, XP coach, and programmer from San
Francisco. He recently coached with Jutta Eckstein and Kent Beck a
very successful XP project in Munich, Germany. In December 2002
he was an invited speaker at the first XP Brazil conference, where he
talked about patterns of XP coaching and fought Kent Beck to a
draw in a hotly contested battle of the coaches.
I’ve heard speculation about the suitability of XP for teams around
the world. Some people reason that XP cannot work in this or that
country due to perceived cultural incompatibilities with its values or
practices. But the more I coach, the more I come to the conclusion
that teams, regardless of their cultural makeup or location, have
more similarities with each other than differences. And more inter-
esting than the differences between teams is the variety to be found
within a team.
In the past, I have found some of this variety frustrating. Now, how-
ever, it is becoming clear to me that creatively tackling in-
compatibilities within a team can lead to substantial benefits. For
example, there is an enormous divide between those programmers
who are “born refactorers”, and those who don’t notice rampant
code duplication until their own programs are printed out and the
full weight of them dropped on their heads. One might be tempted,
in an XP team, to recruit only the refactorers. I think that would be a
mistake. In my experience, programmers who care deeply about
code cleanliness tend to focus excessively on technical details. On
the other side of the coin, sloppy coders often have a closer identifi-
cation with business processes, and a strong desire to crank out
features. Bringing these two sides closer together in their practices
and philosophy helps in the evolution of a productive team and a
code base with a high resistance to entropy.
XP practices such as pair programming and collective code own-
ership enable not just the dissemination of technical knowledge, but
also the productive merging of widely differing personal styles and
approaches to software development. Extreme programming pro-
vides a vehicle, absent in the isolated programmer islands of teams
past, for coaches to immerse themselves daily in the complexity and
variety of their teams. As XP becomes more widely practiced and
better understood, it is my position that finding ways to maximize
benefit from the diversity of a software team will increasingly be-
come the mark of an effective coach.
6. Mary Poppendieck, www.poppendieck.com
Mary Poppendieck has over thirty years of experience as an engi-
neer, IT manager, program manager and product development man-
ager. A twenty year veteran of 3M, she is an expert in process con-
trol, lean manufacturing systems, and commercialization of hard-
ware and software products. She is the president of Poppendieck.
LLC as well as Treasurer and Managing Director of the AgileAlli-
ance. She is the author of numerous articles, including “Lean Pro-
gramming” and “Wicked Problems” in the Software Development
Magazine. Her book Lean Software Development; A Agile Toolkit
was published by Addison Wesley in May, 2003.
When I think of the word coach, I think of my children’s swim team.
Their coach was at every practice and every meet. He gave the
swimmers exercises during practices, taught them good eating hab-
its, and made sure no one even thought about smoking. He made
sure the kids were properly registered at meets and assigned the
relay teams. He discussed strategy with each swimmer before each
race, he timed their splits and shouted encouragement during the
races. When it was over he congratulated those who did well and
discussed how to do better the next time.
A swim team is never without a coach, not for practice or at a meet.
The head coach might delegate some responsibilities to an assistant
who is learning how to be a coach, but the team always had a coach.
The coach isn’t there to swim for the swimmers, or even to teach
them how to swim. The coach’s job is to field a winning team and to
make sure each swimmer is trained and motivated to do well. Be-
hind every really good sports team you will find a really good coach.
Software development is a team sport, and team sports do well to
have a coach-on-site. I’m not talking about a trainer who shows up
occasionally and gives some pointers; I’m talking about a full-time
leader. I’m not talking about someone who tells the team what to do
or tries to play the game for the team; I’m talking about a coach who
helps team members develop their own skills and strategies. Behind
every really good software development team, you will find a really
good coach.
How I became a coach. I was lucky enough to work for Roger Ap-
peldorn, the inventor of the Fresnel lens for overhead projectors
who led the team that made this one of 3M’s more successful prod-
uct lines. He went on to develop many businesses using structured
surfaces on clear plastic: from very bright traffic signs to the lens
that limits the spray of light from your laptop. Under his guidance, I
became a coach for a team developing a lighting system with ultra
pure plastics. I’ll never forget the lessons I learned on how to recruit
the team, how to motivate members, and how to get support from
senior management.
What is the toughest thing I had to do as coach? I had to shut
down a new product development program when the product line
was dropped. The team was devastated, so we held a funeral in the
basement of a very nice restaurant. The marketing guy acted as MC
and came loaded with jokes and memories of good times. We
266
shared our disappointment and found that it was then a lot easier to
move on, but the members of this team stayed in touch with each
other for years.
What advice would I give to a team looking for a coach? Look for
a coach who knows the basics, the blocking and tackling of software
development, and can teach these to a team. Look for a coach who
knows how to get the right people in the right positions and every-
one headed in the right direction. Look for a coach who will run
interference with management and provide the resources and cus-
tomer involvement necessary to get the job done right. Finally, look
for a coach knows how to bring out the best in a team and can in-
spire great performance.
267
