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.
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.
Teams work together on every part of the project, from gathering requirements to implementing code, and participate 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.
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.
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. There’s no reason to fear because no one ever works alone.
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.
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 exhaustive or overly technical—they only need to provide enough detail to help the team determine how long it’ll take 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.
At this stage, the project manager will set the team up to succeed in this methodology. Everyone needs to work collaboratively and effectively communicate to avoid any slipups. 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
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.
Then the time finally comes to implement code. 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.
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, extreme programming 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 not only ensures a health product release but has also unintentionally improved productivity for development teams everywhere.
If you decide to use XP, try documenting your user stories, release schedules, CRC cards, and system documentation visually in Lucidchart. Sign up for your free account today.