Day 74, 2015. The month of March Madness – time of the annual NCAA college basketball tournament. For those, who do not know much about ‘March Madness’, the NCAA tournaments are an American tradition that sends millions of fans into a synchronized frenzy each year. It’s this chaos that gives the tournament its March Madness nickname. March Madness is the concentrated hype of 68 teams vying for college basketball’s biggest prize. It’s the last-second, buzzer-beating baskets, the euphoria of winning to play another day and the agony of losing and going home. For more details please visit NCAA official website

And today is the Selection Sunday! Good luck to all the teams and players out there 🙂

Talking about selection, if I ask you to select one of the two, Scrum or XP, which one will you chose to implement in your organization? I know its a tough choice, may be you would want to weigh-in on the pros and cons for each of these and then make your choice. Allow me to help you make an educated decision. 😉

What is XP?

eXtreme Programming (XP) is a discipline of software development which is intended to improve software quality and responsiveness to changing customer requirements. Just like any other agile software development philosophy, XP also advocates product releases in short development cycles – intended to improve productivity and add flexibility to adopt changes.

It is based on values of simplicity, communication, feedback, courage, and respect and it works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

XP works better with small teams of developers who need to develop software quickly in an environment of rapidly-changing requirements. The teams design software for specific functionalities without adding any additional functionalities that are not specifically requested by the customer as it may slow down the process. It prescribes to keep the development course simple through systematic and regular testing and design improvements.

Why “Extreme”? The word “Extreme” here signifies that the traditional software development “best practices” get “turned up” to much higher “volume”.

History of XP

The first Extreme Programming project was started on March 6, 1996 by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. Beck was the C3 project leader and began to refine the development methodology used in the project and wrote a book on the methodology – Extreme Programming Explained published in October 1999. Chrysler eventually cancelled the C3 project in February 2000, when the company was acquired by Daimler-Benz.

Although extreme programming itself is relatively new, however, many of its practices such as test driven development, test-first and short development cycles, had been employed by NASA in as early as late 1960s.

Scrum & XP: some subtle differences

Scrum and Extreme Programming are so different that they are not really comparable. They share the same underlying values described in the agile manifesto, and the same underlying principles that characterize ‘agile’. They overlap in areas, but fundamentally, they address completely different aspects of agile software development. The differences are often quite subtle, but can have a profound impact on the teams. Below are a few of the main differences between Scrum and XP:

• Cycle Duration: The development cycles in Scrum are called “Sprints” and are usually two weeks to one month long. XP teams typically work in “Iterations” that are one or two weeks long.
• Flexible Commitments: Once the scrum teams commit to a sprint in a sprint planning session, they do not allow changes into their sprints. XP teams are much more amenable to change within their iterations. As long as the team hasn’t started work on a particular feature, a new feature of equivalent size can be swapped into the XP team’s iteration in exchange for the unstarted feature.
• Priority Order: Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items (most of the times, scrum teams pick work items in order of priority, however, they are not bound to do so). On the other hand, Extreme Programming teams work in a strict priority order. Features to be developed are prioritized by the customer (Scrum’s Product Owner) and the team is required to work on them in that order.
• Prescriptive Vs. Adaptive: On a scale of prescriptive vs. adoptive, XP is definitely more prescriptive than Scrum. Scrum doesn’t prescribe any engineering practices, whereas, XP does. XP engineering practices are great help for any software development team, particularly things like test-driven development, the focus on automated testing, pair programming, simple design, pair-programming, continuous integration, re-factoring, and so on. However, it is not fair to tell the team “you’re self-organizing, we trust you, but you must do these specific engineering practices….” This sends a mixed message to the team that causes confusion. We all love the XP practices but should we mandate them? I suggest we let the teams discover the value of these practices on their own (via the retrospective sessions as improvement areas).

Scrum, XP or Both?

Scrum is more like a agile management methodology. It talks more about the process that will take us from the inception of a vision to the final product, however, it does not address the practices required to create the “product” itself. Scrum process shows us what the quality is, however, it doesn’t tell us how to create quality. It shows us where the problems are, and challenges us to fix them, however, doesn’t provide us with the tools to fix the problems. And this is where, Extreme Programming comes in play!

Extreme programming is an agile engineering methodology. It provides us with all the necessary engineering tools to create software in an agile and productive way. It lays more emphasis on better engineering practices required to deliver quality software, such as, Simple Design, Test-Driven Development, Pair Programming, Design Improvement, Continuous Integration, Re-factoring, and Collective Code Ownership.

So, for organizations that are trying to go agile and are in a dilemma of which one to adopt – if the motivation for agile adoption is wanting more visibility, better business engagement, team collaboration, a clear process for prioritization – Scrum is a good starting point. And, if the motivation or adoption is driven the engineering departments of an organization – XP is definitely a better starting point.

In both cases any organization will benefit from a more incremental, iterative approach to software development.

I personally suggest the teams/organizations to start with Scrum and then invent their your own version of XP. The XP practices are wonderful but they work best and teams commit to them the most stridently if they discover these themselves rather than having them mandated.

Happy Reading! 🙂

– Nirbhay Gandhi