Back in the 1990s, the rise of the Internet necessitated a change in software development. If a company’s success depended on the speed at which the company could grow and bring products to market, businesses needed to dramatically reduce the software development life cycle.

It was in this environment that Kent Beck created extreme programming (XP), an agile project management methodology that supports frequent releases in short development cycles to improve software quality and allow developers to respond to changing customer requirements.

Although you may recognize some of these practices and values from other project management methodologies, XP takes these practices to “extreme” levels, as the methodology’s name suggests. In an interview with Informit, Kent explains:

“The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I …  asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.”

If you and your team need to quickly release and respond to customer requests, take a look at the values and rules of extreme programming—it could be a perfect fit.

Values of extreme programming methodology

XP is more than just a series of steps to manage projects—it follows a set of values that will help your team work faster and collaborate more effectively.

Simplicity

Teams accomplish what has been asked for and nothing more. XP breaks down each step of a major process into smaller, achievable goals for team members to accomplish.

Streamlined communication

Teams work together on every part of the project, from gathering requirements to implementing code and participating in daily standup meetings to keep all team members updated. Any concerns or problems are addressed immediately.

Consistent, constructive feedback

In XP, teams adapt their process to the project and customer needs, not the other way around. The team should demonstrate their software early and often so they can gather feedback from the customer and make the necessary changes.

Respect

Extreme programming encourages an “all for one and one for all” mentality. Each person on the team, regardless of hierarchy, is respected for their contributions. The team respects the opinions of the customers and vice versa.

Courage

Team members adapt to changes as they arise and take responsibility for their work. They tell the truth about their progress—there are no “white lies” or excuses for failure to make people feel better. They value teamwork over ego and are always looking out for what's best for the team.

Rules of extreme programming methodology

Don Wells published the first XP rules in 1999 to counter claims that extreme programming doesn’t support activities that are necessary to software development, such as planning, managing, and designing. From planning to testing the software, follow these basic steps for each iteration.

1. Planning

This stage is where the UX magic happens. Rather than a lengthy requirements document, the customer writes user stories, which define the functionality the customer would like to see, along with the business value and priority of each of those features. User stories don’t need to be overly technical as they only need to provide enough detail to help the team determine the timeframe to implement those features.

With Lucidchart, customers can create a basic flowchart and easily record and share the desired functionality.

From there, the team creates a release schedule and divides the project into iterations (one to three weeks long). Project managers might want to create a timeline or a simplified Gantt chart to share the schedule with the team.

2. Managing

At this stage, the project manager will set the team up to succeed. Everyone needs to collaborate and communicate effectively to avoid any blockers. This stage involves:

• Creating an open workspace for your team
• Setting a sustainable pace (i.e. determining the right length for iterations)
• Scheduling a daily standup meeting
• Measuring project velocity (the amount of work getting done on your project)
• Reassigning work to avoid bottlenecks or knowledge loss
• Changing the rules if XP isn’t working perfectly for the team

3. Designing

This rule goes back to the value of simplicity: Start with the simplest design because it will take less time to complete than the complex solution. Don’t add functionality early. Refactor often to keep your code clean and concise. Create spike solutions to explore solutions to potential problems before they put your team behind.

Kent Beck and Ward Cunningham also created class-responsibility-collaboration (CRC) cards to use as part of the XP methodology. These cards allow the entire project team to design the system and see how objects interact. If you’d like to try this brainstorming tool for yourself, get started with our Lucidchart template.

4. Coding

XP practices collective code ownership: Everyone reviews code and any developer can add functionality, fix bugs, or refactor. For collective code ownership to work, the team should:

• Choose a system metaphor (standardized naming scheme).
• Practice pair programming. Team members work in pairs, at a single computer, to create code and send it into production. Only one pair integrates code at a time.
• Integrate and commit code into the repository every few hours.

The customer should be available, preferably on site, during this entire process so they can answer questions and establish requirements.

5. Testing

The team performs unit tests and fixes bugs before the code can be released. They also run acceptance tests frequently.

When to use extreme programming

Still unsure whether XP will fit your team’s needs, even after reading its rules and values? Extreme programming can work well for teams that:

• Expect their system’s functionality to change every few months.
• Experience constantly changing requirements or work with customers who aren’t sure what they want the system to do.
• Want to mitigate project risk, especially around tight deadlines.
• Include a small number of programmers (between 2 and 12 is preferable).
• Are able to work closely with customers.
• Are able to create automated unit and functional tests.

If collaboration and continuous development are priorities for your team, XP might be worth a try. Because this highly adaptable model requires ongoing feedback from customers, anticipates errors along the way, and requires developers to work together, XP ensures a healthy product release but also improved productivity for development teams.

Use XP in Lucidchart to document your user stories, release schedules, CRC cards, and system documentation visually in Lucidchart.