Beyond Sprints: How XP Can Work for Modern Teams


Beyond Sprints: How XP Can Work for Modern Teams


Man Programming on Computer

Search “agile scrum” in the books section of Amazon, and you’re likely to find around 835 results. Search “agile extreme programming” and you’ll get just around 120 results back.

While this exercise might not be a scientific measure, it does reflect the dominant mindshare of agile discourse that Scrum has grown to achieve over the years. Indeed, just one look at the website of Scrum Alliance, and you’ll find six certifications specifically for Scrum, hundreds of Scrum training courses held around the world, corporate sponsorships, and essentially an entire commercial ecosystem ‒ none of which exist for Extreme Programming.

I have nothing against Scrum ‒ I went through Certified Scrum Product Owner training and found it immensely helpful. However, I don’t think Scrum should be where the discussion ends and I think other methodologies are far too often overlooked in agile discussions.

In fact, I’ve found that many of my well-meaning colleagues often start describing agile with terms like “sprints,” “estimates,” and “backlog grooming” ‒ but in reality, they’re usually describing Scrum rather than agile.

While Extreme Programming (XP) might not be for every team, I believe that every team should at least know what it is. Indeed, respected Scrum trainer and Scrum Alliance founding member Mike Cohn even wrote, “My typical advice to teams is ‘start with Scrum and then invent your own version of XP.’”

What is Extreme Programming?

Like all forms of agile, Extreme Programming emphasizes frequent releases and short development cycles to adapt to changing requirements and improve productivity. However, XP does not prescribe strict sprints, estimates, nor Scrum Masters.

In true agile fashion, XP posits that changes are natural, unavoidable and even desired when developing a software product.

Unlike Scrum, XP extends agile by emphasizing four key programming activities.

The first of these engineering practices emphasized is coding. Emphasis of coding is a stipulation that code is the most important aspect of software, and without it, no product would exist.

Coding is also seen as a fundamental tool in many working functions, such as using coding to find optimal solutions, and explaining concepts and solutions to others.

Unit tests and acceptance tests (testing), listening to customer needs and seeking frequent customer feedback (listening), and designing logic into the system to prevent an overabundance of dependencies and logic issues (designing) round out the other three programming activities that XP emphasizes.

Similar to Scrum, XP also has its own set of values: communication, simplicity, feedback, courage and respect. These values all reflect core values of the Agile Manifesto, emphasizing the people and interactions needed to get working software built, as well as maintaining constant customer collaboration and responding to change.

What Are the Advantages of Extreme Programming?

In my own personal opinion, I find XP to be less prescriptive in practice than Scrum. I think far too many professionals latch onto a framework like Scrum and begin mandating it in the most rigid way possible, which runs the risk of being contrary to the Agile Manifesto by overemphasizing processes, tools and plans.

While many teams stand to benefit from the more elaborate framework and processes offered by Scrum, more nimble and self-disciplined teams are able to thrive with less procedural overhead.

Indeed, many teams are even reminding us that processes like estimates are not necessarily a must-have, and may even be counterproductive at times. Many people are shocked when I remind them that estimates aren’t actually a universal aspect of agile, nor specifically prescribed in popular methodologies like Kanban or Lean.

In addition to being liberating and removing processes which can slow teams down, I believe that XP is more adaptive to change than Scrum, as it usually allows changes within planned iterations.

I’ve seen far too many Scrum teams get locked into the idea of following two-week cycles as a default, whereas XP seems more compatible with modern practices like shipping code and features multiple times a day.

This isn’t to say that XP is all about throwing all process to the wayside. On the contrary, I believe the emphasis on practical engineering activities like testing and pair programming helps keep teams focused on processes that have a much clearer impact on actual work quality, rather than business planning measures like estimates and sprint velocity, which tend to feel more indirect and distracting from getting the actual work done.

Finally, I personally like the fact that XP emphasizes frequent communication with the customer. By frequently talking to the customer, the team building the software can uncover misunderstandings or changes in requirements and address them more rapidly, rather than adopting the mindset that they’ll wait to present their work to the customer at the end of a sprint.

Can Extreme Programming Really Work?

Extreme Programming isn’t for every team, but it could be. With Continuous Delivery and streamlining of deployment becoming more and more common, I believe that Extreme Programming is a very appealing methodology that emphasizes meeting customer requirements and facilitating development without processes that hinder work.

In my own experience, I found Scrum to be a great introductory framework full of interesting ideas, but over time, I found that the practices and values of XP were more in line with what our team actually needed to function closer to our peak performance capabilities.

In fact, my team never set out to adopt XP and we never talk about it ‒ it just so happens that most of what we decided works well overlaps with XP practices, values and principles.

With this experience in mind, I wasn’t surprised at all to read Mike Cohn write, “The XP practices are wonderful but they work best and teams commit to them the most stridently if they discover them themselves rather than having them mandated.”

Take a look at your own team practices and discussions about what works and what feels like a detractor from effective work. You may be surprised to find yourself closer to the XP side of the spectrum than you may have realized!

What’s your take? Let me know in the comments below.



 

Ken Shen Robinson is a senior product manager at Praetorian Digital, where he leads product management for EdTech products that make our communities smarter and safer.

Learn More
comments powered by Disqus