Taking it to extremes with XP

Extreme positions are not succeeded by moderate ones, but by contrary extreme positions.
Friedrich Nietzsche

I worked with a sharp developer years ago named Matt. He had at the time some interesting ideas. He spoke of Test-Driven Development and other tenets of Extreme Programming long before many people practiced it. The organization didn’t embrace his ideas and he eventually moved on. As the industry moved it appeared Matt was ahead of the curve.


Extreme Programming is an agile management methodology the focuses on frequent releases and shorter development cycles. With these changes, they aim to improve the quality of the software produced and help teams respond to change quicker.


It all started when Kent Beck began working with Don Wells on Chrysler Comprehensive Compensation (C3) project during the mid-90s. The work on the project was serious trouble. As they state on the Extreme Programming website they decided to start over. The many practices they began to use formed what is now called Extreme Programming.


Extreme Programming focuses on communication and feedback to the whole team. A shared understanding of goals can lead to achieving team goals. Simple solutions are favored too. “Extreme Programming encourages starting with the simplest solution and refactoring to better ones.” As Select Business Solutions shared. Teams should have the respect of each other by not breaking build compilation or unit-test that would slow their work. XP also values courage to design for today and be willing to throw away code that doesn’t serve the team.


The key activities that enable Extreme Programming are first Planning. “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.” LucidChart shares this and describes the importance of brevity. Managing a team to a sustainable pace is another key point. Too many teams try to burn out everyone.

Kent Beck also emphasized designing with simplicity in mind. We can often make our work too complex. Coding is done collectively. No one person owns the code. Anyone can review, fix bugs, or refactor it. Pair programming was at first considered strange but, now is embraced by many organizations. Testing is to be automated with Unit Tests running after a code check-in and integration tests too. Catch the bugs early.


Extreme Programming can be helpful in a prototype or a situation where requirements change rapidly. It can also be applied to a research project that is intended to test out new technology that may not be used. If you have a small project that doesn’t need formal processes XP can work for that as well too.


There are some key differences between Scrum and XP. As Mike Cohn points out in this article. Let’s review a few of his key points. This article points out that Scrum teams have Sprints that can be longer than XP teams. This has changed since this article was written. Mike points out that Scrum teams don’t allow changes during the sprint where XP teams are more amenable to this. Scrum doesn’t prescribe engineering practices where XP does. Although many Scrum teams do a lot of the XP practices.

Overall XP has some Scrum features. They are cousins if you will. Each methodology borrows from the other. Any Scrum team would benefit from reviewing the differences and seeing where they could gain from adding one or two. It is important to know there is more to agile than just Scrum.

Originally posted on MyITCareerCoach.com