Xtreme Programming and Agile Coaching

Panel

Xtreme Programming and Agile Coaching Steven Fraser (Impresario)

Rachel Reinitz (Chair)

Jutta Eckstein

Independent Consultant

IBM

Independent Consultant

Joshua Kerievsky

Rob Mee

Mary Poppendieck

Industrial Logic

Pivotal Computer Systems

Agile Alliance

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.

ABSTRACT This panel brings together coaches to discuss all aspects of the practice – 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?

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 software she has designed and taught OT industry courses. Jutta trained as a teacher and experienced leading many train-the-trainer programs in industry. She focuses on techniques which help teach OT and is a main lead in the pedagogical patterns project. She is currently 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.

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, [email protected] 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 (Disruptive 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 Application of Software Models project on the development of teambased domain analysis techniques. Steve is an avid operatunist and videographer.

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 retrospectives 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 successful. Thus the customer needs additional support from the coach for mastering this burden.

Coaching is about teamwork, motivation, communication, skills and strategy. Coaches help team members become a cohesive unit, understand 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. Interestingly two distinct coaching roles have emerged – the manager as coach, and the consultant as coach.

2. Rachel Reinitz, [email protected] Rachel Reinitz (chair) is a Senior Consultant with IBM Web Sphere Services focusing on Web Services. She is also an experienced eXtreme Programming coach who has used XP practices for four years.

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 customers. 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

XP practices such as pair programming and collective code ownership 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 provides 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 become the mark of an effective coach.

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.

6. Mary Poppendieck, www.poppendieck.com Mary Poppendieck has over thirty years of experience as an engineer, IT manager, program manager and product development manager. A twenty year veteran of 3M, she is an expert in process control, lean manufacturing systems, and commercialization of hardware and software products. She is the president of Poppendieck. LLC as well as Treasurer and Managing Director of the AgileAlliance. She is the author of numerous articles, including “Lean Programming” and “Wicked Problems” in the Software Development Magazine. Her book Lean Software Development; A Agile Toolkit was published by Addison Wesley in May, 2003.

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.

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 habits, 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.

5. Rob Mee, [email protected]

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. Behind every really good sports team you will find a really good coach.

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 interesting than the differences between teams is the variety to be found within a team.

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.

In the past, I have found some of this variety frustrating. Now, however, it is becoming clear to me that creatively tackling incompatibilities 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 identification 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.

How I became a coach. I was lucky enough to work for Roger Appeldorn, the inventor of the Fresnel lens for overhead projectors who led the team that made this one of 3M’s more successful product 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

one headed in the right direction. Look for a coach who will run interference with management and provide the resources and customer 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 inspire great performance.

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-

267