Extreme programming: Process vs. culture

Team communication tools for XP adoption

Extreme programming (XP) is a software development methodology that makes coding the primary activity. By promoting values such as simplicity and feedback, XP allows Java programmers to incrementally develop and test applications, thus allowing for rapid application development.

Adopting extreme programming (XP) is a difficult undertaking. If you are on a team that is midproject with an existing codebase, the difficulty and risks are even higher. The current project baggage, such as maintaining the current codebase, delivering the software on time, and team dynamics, along with the challenge of adopting XP, such as learning a new skill set, confronting current fears and issues, and internalizing the process, is not something to enter into lightly. In addition to the fact that introducing changes into processes is risky, teaching people new practices and approaches slows them down. How do we mitigate this risk?

Use XP to adopt XP

In the groundbreaking work, Extreme Programming Explained, author Kent Beck offers the following advice:

Pick your worst problem. Solve it the XP way. When it is no longer your worst problem, repeat.

If an XP guru suddenly appeared and said, "Please state the nature of the development emergency," identifying the worst problem would be easy. So how do we, being new to XP, figure out what our worst problem is? We cannot assume that reading a book on XP alone will help us identify our problems.

Programming is a team effort. The customer defines the requirements, the project manager manages the client relationship, and the programmers (hopefully) deliver the product the customer wants. Learning a new methodology, and learning how development can be achieved is a team effort as well.

One-way of getting the team together to begin working on these complex problems is to conduct retrospectives. Retrospectives have been around for quite some time now; however, they are surprisingly rare on most project managers' to-do lists. Retrospectives give the team an opportunity to sit down and examine the last iteration and figure out what did and did not go well, and what can be done better next time. In our case, adopting XP will be Iteration #0. At this point, the discussion is based on how the team has performed in the past, pre-XP.

Many red flags pop up when a retrospective is suggested. In general, people fear retrospectives. They fear being attacked, being perceived as incompetent, of getting negative remarks, or they fear hurting the feelings of others in the group and do not speak out.

In Project Retrospectives: A Handbook for Team Reviews, Norm Kerth establishes an important ground rule for team retrospectives:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Once the ground rules for the retrospective are in place, the team needs a leader. In the XP context, this is usually the role of coach. This person can be an outside consultant, someone on the team that has previous XP experience, or someone that, at the very least, has taken the time and initiative to learn as much as they can about XP.

The team member that fills this role must be passionate about the material. He must be well prepared to keep the team focused on the goal of learning and internalizing XP. Most importantly, he must be willing and empowered to keep the ground rules in place. He must clarify that discussions are not meant to be won, but grown. A shortcoming in any of these areas can quickly lead to the team retrospective deteriorating.

Study groups are another common occurrence that typically takes place outside work. Nearly every programming language and software product has a user group. At these meetings, people of varying skill levels come together to help one another better understand the various aspects of the groups' topic. While it may prove burdensome to undertake a long technical manual alone, it can be less of a task as a group effort. Clarification can be reached on difficult sections, and greater understanding of the material is easier to achieve.

The combination of retrospectives and study groups can make for a powerful tool when trying to migrate to XP. With the ground rules in place and the role of the leader identified, let's take a look at how all this could possibly work.

Retrospective and study group combined in action

As the team assembles, the XP coach writes the introspection ground rules on the whiteboard. For example, each speaker may have a time limit of two minutes. He then opens the floor for discussion. At this point, the team may be wary of the topic. Thus, it is important that the coach leads into the discussion with a direct question: for example, "What is the overall impression of the last few projects we have done." That question or a similar one will get the team talking.

As the team members begin to open up and explain their various viewpoints, the coach captures the feedback on the whiteboard. When the discussion runs astray, the coach must rein it back in. At this stage, it's important to capture as much relevant information as possible. By the end of the discussion, the team should have identified a list of issues. At this point, the team may want to categorize or solve them. It is important to hold off on that, as there is still no XP context to the discussion.

At the end of this first meeting, the coach should pass out an agenda for the next week's meeting, with a reading assignment. While there are many books on XP, I suggest Extreme Programming Explained. Using this book, Section 1 would be an adequate reading assignment. Another suggestion to the coach: have each team member present to the group a different chapter within the section. The next week, each team member is responsible for discussing his or her chapter and leading a discussion on how the chapter relates to the issues on the whiteboard.

For the next meeting, the entire team has read the first section and is prepared to discuss the material. The team member assigned to present Chapter 1 joins the coach at the front of the room and presents the chapter along with her thoughts on the material. The coach then opens the floor to discussion, keeping the dialogue relevant and continuous until it's time to move on to the next presenter.

After the last presentation, the coach summarizes what was learned in the presentations and, in the conversations that follow, leads the team in identifying possible actions that the team can take to correct the relevant issues on the whiteboard.

At the meeting's end, the coach hands out an agenda for the next set of presentations, and the process repeats itself until the material is finished and fully understood.

Throughout the meetings, the coach decides how to proceed. If it becomes apparent that a different approach is needed, he should discuss it with the team and make the change decided by the team. The group environment must be nurtured and grown to be successful.

This approach allows XP concepts to be taken internally by the team. It also gives the team members time to reflect on the discussions and realize how the topics fit into their current practices and culture. The team must decide together what the current problems are and which XP solutions could be used to fix them. Whether or not the team members are XP experts doesn't matter. The team is learning as one and acting as one, which is probably one of the hardest things to get a development team to do.

Hopefully, as the team gets towards the end of the material, XP solutions have already begun to appear in the team's daily development practices. If the team decided that customer communication was its biggest problem, the Planning Game, an XP solution that addresses iteration-planning with the client, can be adopted.

Once the material is finished, it is important to keep retrospectives in place. XP adoption requires constant tuning. One of XP's key values is feedback, which must be encouraged. The team should continue to meet regularly and discuss how the solutions to the problems identified in Iteration #0 are working out, where there are new problems, and how they can be fixed. If the team decides that the biggest problem has been fixed, the coach should steer the group towards the next biggest problem, relate back to what the team has learned, and adopt the XP practice(s) that aim at solving the problem.

Decrease the XP learning curve

Retrospectives combined with study groups can be powerful tools for development teams to use for identifying issues and how to solve them. Retrospectives require a safe, open environment and a leader that can keep the team on task. Study groups help the team address the issues raised by retrospectives, and also allows for the constant learning and sharing of expertise throughout the team. At the end of the day, if the team is discussing and acting as one, there is a greater likelihood that the culture will be sound for XP adoption.

Ryan Ripley is a Java programmer in the Midwest who has been using XP for the last two years within various industries, ranging from promotional products to healthcare. He has been programming in Java for the last five years and actively participates in many open source projects.

Learn more about this topic

Join the discussion
Be the first to comment on this article. Our Commenting Policies