benjiPosted under ContinuousDelivery, XP.

There was a recent discussion on the Extreme Programming mailing list kicked off by Ron Jeffries saying he wants his XP back.

The implication being that Extreme Programming is no longer practised, and that most “Agile” organisations are actually practising Flaccid Scrum – some agile process but little of the technical practices from Extreme Programming.

Update: Ron clarifies in the comments that we agree that extreme programming is still practised, but it would be good if it were practised by more teams.

I disagree with this premise. Extreme Programming is alive and well, at least here in London. We have XProlo, eXtreme Tuesday Club, XPDay and many other communities dedicated to XP practices under other names like Continuous Delivery and Software Craftsmanship. There are enough organisations practising Extreme Programming for us to organise regular developer exchanges to cross-pollenate ideas. Extreme programming skills such as Test-driven development and continuous-integration are highly in demand skills in Job Descriptions, even if there is much confusion about what these things actually entail.

When I say that Extreme Programming is alive and well, I do not mean we are working in exactly the same way as described in Kent Beck’s Extreme Programming Explained book. Rather, we still have the same values, and have continued to evolve our technical and team practices. Kent Beck says

“my goal in laying out the project style was to take everything I know to be valuable about software engineering and turn the dials to 10.”

Well now we have turned the dials up to eleven. What does modern Extreme Programming look like?

Turning the dials up to 11

Here are some of the ways we are now more extreme than outlined in Extreme Programming explained.

Pair Programming becomes Mob Programming

Update: Apparently XP Teams are so aligned that Rachel has written a similar blog post, covering this in more detail.

XP Explained says “Write all production programs with two people sitting at one machine”. We’ve turned this to eleven by choosing how many people are appropriate for a task. We treat a pair as a minimum for production code, but often choose to work with the whole team around a single workstation.

Mobbing is great when the whole team needs to know how something will work, when you need to brainstorm and clarify ideas and refinements as you build. It also reduces the impact of interruptions as team-members can peel in and out of the mob as they like with minimal disruption, while a pair might be completely derailed by an interruption.

When pair programming it’s encouraged to rotate partners regularly to ensure knowledge gets shared around the team and keep things fresh. Mobbing obviates the need to rotate for knowledge sharing , and takes away the problem of fragmented knowledge that is sometimes a result of pair rotation.

Continuous Integration becomes Continuous Deployment

In Extreme Programming explained Kent Beck explains that “XP shortens the release cycle”, but still talks about planning “releases once a Quarter”. It suggests we should have a ten-minute build, integrate with the rest of the team after no more than a couple of hours, and do Daily Deployments.

We can take these practises to more of an extreme.

Deploy to production after no more than a couple of hours
Not just build but deploy to production in under ten minutes
Allow the business to choose to release whenever they wish because we decouple deployment from release

Each of these vertical blue lines is our team deploying a service to production during an afternoon.

I think of Continuous Deployment as full Continuous Integration. Not only are we integrating our changes with the rest of the team, but the rest of the world in our production environment. We reduce the release deployment pain to zero because we’re doing it all the time, and we get feedback from our production monitoring, our customers and our users.

David Farley recently said “Reduce cycle time and the rest falls out” at Pipeline 2015. When turning up the dial on release frequency we find we need to turn other dials too.

Collective Code-Ownership becomes Collective Product-Ownership

XP Explained suggests that “Anyone on the team can improve any part of the system at any time” but mostly discusses the idea of shared code – anyone is free to modify any part of the codebase that team owns. However, it also suggests that we need real customer involvement in the team.

We wish to move fast for two reasons.

  1. To generate value as rapidly as possible
  2. To get feedback as frequently as possible to ensure the above

Continuous Deployment helps us move fast and get valuable feedback frequently, but the freedom to deploy-continually is only practicable if our teams also have a collective responsibility for maintaining our systems in production. To make sensible decisions about what to build and release we need to also have the responsibility of being woken up when it goes wrong at 2am.

Continuous deployment and collective ownership of infrastructure operations means we can move fast, but then the bottleneck becomes the customer. We can learn whether our changes are having the desired effect rapidly, but the value of the feedback is not fully realised if we cannot act upon the feedback to change direction until a scheduled customer interaction such as a prioritisation meeting.

Hence we extend collective ownership to all aspects of product development.

  1. Product planning
  2. Coding
  3. Keeping it running in production

Everyone on the team should be not only be free, but encouraged to

  • Change any part of the codebase
  • Change any part of our production infrastructure
  • Discuss product direction with business decision makers.

Products not Projects

Collective product ownership implies some more things. Instead of giving teams a project to build a product or some major set of features over a time period, the team is given ownership of one or more Products and tasked with adding value to that product. This approach allows for full collective product ownership, close collaboration with customers, and fully embracing change as we learn which features turn out to be valuable and which do not.

This approach is more similar to the military idea of Commander’s Intent. The team is aware of the high level business goals, but it is up to the team, with embedded customer to develop their own plans to transform that thought into action.

Hypotheses as well as Stories

User stories are placeholders for conversation and delivery of small units of customer-visible functionality. These are useful, but often we make decisions about which features to prioritise based on many assumptions. If we can identify these assumptions we can construct tests to confirm whether they are accurate and reduce the risk of spending time implementing the feature.

When working in close collaboration with customers to test assumptions and collectively decide what to do there’s also less need for estimation of the cost of stories, and there’s certainly less need to maintain long backlogs of stories that we plan to do in the future. We can focus on what we need to learn and build in the immediate future.

Test-First Programming becomes Monitoring-First Programming

Or TDD becomes MDD. When we collectively own the whole product lifecycle we can write our automated production monitoring checks first, and see them fail before we start implementing our features.

This forces us to make sure that features can be easily monitored, and helps us avoid scope creep, just like TDD, while ensuring we have good production monitoring coverage.

It also helps us have trust in our production systems and the courage to make frequent changes to our production system.s

Just like with TDD, MDD gives us feedback about the design of our systems, which we can use to improve our designs. It also gives us a rhythm for doing so.

Continuous Learning

Nearly all of the above are designed to maximise learning, whether it is from our peers during development, our production environment when we integrate our changes, our users when we release changes, or our customers when we test hypotheses.

But it’s also important to have space for individual learning, it helps retain people and benefits the team.

Extreme Programming practices have changed in the last 15 years because we are continually learning. Some of the ways to provide space for learning include

  • Gold cards/20% time – provide dedicated and regular time for individuals in the team to do work of their own choosing. Providing opportunity for bottom-up innovation.
  • Dev-exchanges – regularly swap developers with other organisations to allow for sharing of ideas between organisations
    Meetups and Conferences – Encouraging each other to attend and speak at conferences and local meetups helps accelerate learning from other organisations.
  • Team-Rotations – Regularly swapping people between teams inside the organisation helps spread internal ideas around.

7 Responses to “Modern Extreme Programming”

  1. Rajesh Vaya

    I had only heard very little about Extreme programming and after reading your article I am so clear about the benefits of it. Really nice article, I am looking forward to learn more about XP.

    Do you have any suggestions/tip for a programmer (me) who wants to get into details of XP and what could help me getting ready for XP (I live in Dubai an it is not tech oriented as I wish it would and people don’t know the concept of TDD here and they practice stone-age project management with deadlines and 9-5 jobs etc.)

    Any advice would be helpful

    Thanks :)

  2. Ron Jeffries


    It sounds as if your team, and other teams you know of, are doing great stuff in the XP “tradition”.

    I’m a bit concerned that you think we are in disagreement. You misstate my premise and then disagree with it, which isn’t as fair as it might be. :)

    My premise is not that XP is never practiced: so long as one team somewhere does XP, XP is being practiced.

    My premise, is, however, that most so-called “Agile” teams are doing nothing like XP, and nothing like you’re doing. That’s quite consistent with the second part of what you suppose my premise to be. No to the first part, yes to the second.

    With my premise stated correctly, are you sure that you disagree? Do you disagree that few teams are doing XP type things and getting the joy and benefits that you are seeing?

    Would you agree that few teams in the world are doing as you do and getting the benefits that you get? Would you agree that it would be good if more of them did?

    Then perhaps we agree rather than disagree. If so, I wish your lovely article expressed that agreement. Thanks!

  3. Ayan

    Nice summary of many great new trends, many of which I haven’t heard of. More of your posts are now on my to read list.

  4. Colin Humphreys

    Hi Benji,
    Great article, thanks for sharing this.

    I’m in furious agreement with all your points bar one: “Collective Code-Ownership becomes Collective Product-Ownership”. We’ve always kept technical and product decision-making separate. From ‘Planning Extreme Programming’ – “Create a simple set of rules that tend to cause the technical people to make the technical decisions and the business people to make the business decisions.”.

    The justification is usually that technical staff don’t prioritise by user value (preferring to play with cool toys) and business people can’t estimate (often failing to understand the implications of their decisions) thus the planning process is used to generate consensus across the team on forward progress.

    I think this justification might be invalid in the BizDevOps utopia we’re now supposedly inhabiting – so I’d love to hear your thoughts on how collective product ownership is going at Unruly.


  5. Nafees

    That’s an excellent write-up and i nodded at every single paragraph that you have written above. The practices you have mentioned above are indeed driving the technical excellence in the modern product development world. However, the ‘rest of us’ out there category is falling in the trap that Ron mentioned.

    The way i see it, the community is thriving. But the spread of Agile is so wide, that there are lot of Agile/Scrum initiatives do not get to benefit from it (for one reason or another). My take? Continue doing/spreading the good work. Your article and Ron’s worries, both, are flip side of the same coin.


  6. Phillip Kemp

    I like the spin off from the traditional XP. We have done alot of the modern XP as you described but there is alot that just answered alot of questions that we had. This can push us to the next level. Will love to connect with you or like minded companies that will be open to tech-tourism or as you say tech-exchange but definately knowledge share. If you or you know of other companies that are open to this we will love to be a part of the culture of pushing the limits! Once again, great article!

Leave a Reply

  • (will not be published)