Featured White Papers

• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Extreme programming: Process vs. culture

Team communication tools for XP adoption

By Ryan P. Ripley, JavaWorld.com, 08/15/03

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.