{"id":850,"date":"2015-04-17T12:58:09","date_gmt":"2015-04-17T11:58:09","guid":{"rendered":"http:\/\/benjiweber.co.uk\/blog\/?p=850"},"modified":"2015-04-29T14:43:35","modified_gmt":"2015-04-29T13:43:35","slug":"modern-extreme-programming","status":"publish","type":"post","link":"https:\/\/benjiweber.co.uk\/blog\/2015\/04\/17\/modern-extreme-programming\/","title":{"rendered":"Modern Extreme Programming"},"content":{"rendered":"

There was a recent discussion on the Extreme Programming mailing list kicked off by Ron Jeffries saying he wants his XP back<\/a>. <\/p>\n

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

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. <\/em><\/p>\n

I disagree with this premise.<\/del> Extreme Programming is alive and well, at least here in London. We have XProlo<\/a>, eXtreme Tuesday Club, XPDay<\/a> and many other communities dedicated to XP practices under other names like Continuous Delivery<\/a> and Software Craftsmanship<\/a>. 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<\/a>, even if there is much confusion about what these things actually entail.<\/p>\n

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\u2019s Extreme Programming Explained<\/a> book. Rather, we still have the same values, and have continued to evolve our technical and team practices. Kent Beck says <\/p>\n

“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.”<\/em><\/p>\n

Well now we have turned the dials up to eleven.<\/a> What does modern Extreme Programming look like?<\/p>\n

Turning the dials up to 11<\/h2>\n

Here are some of the ways we are now more extreme than outlined in Extreme Programming explained.<\/p>\n

<\/p>\n

Pair Programming becomes Mob Programming<\/h3>\n

Update: Apparently XP Teams are so aligned that Rachel has written a similar blog post<\/a>, covering this in more detail.<\/a><\/em><\/p>\n

XP Explained says “Write all production programs with two people sitting at one machine”. We\u2019ve 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.<\/a><\/p>\n

<\/p>\n

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.<\/p>\n

When pair programming it\u2019s 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.<\/p>\n

Continuous Integration becomes Continuous Deployment<\/h3>\n

In Extreme Programming explained Kent Beck explains that “XP shortens the release cycle”<\/em>, but still talks about planning “releases once a Quarter”<\/em>. 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.<\/p>\n

We can take these practises to more of an extreme. <\/p>\n

Deploy to production after no more than a couple of hours
\nNot just build but deploy to production in under ten minutes
\nAllow the business to choose to release whenever they wish because we decouple deployment from release<\/p>\n

Each of these vertical blue lines is our team deploying a service to production during an afternoon.<\/p>\n

<\/p>\n

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.<\/p>\n

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

Collective Code-Ownership becomes Collective Product-Ownership<\/h3>\n

XP Explained suggests that “Anyone on the team can improve any part of the system at any time”<\/em> 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. <\/p>\n

We wish to move fast for two reasons.<\/p>\n

    \n
  1. To generate value as rapidly as possible<\/li>\n
  2. To get feedback as frequently as possible to ensure the above<\/li>\n<\/ol>\n

    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.<\/p>\n

    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.<\/p>\n

    Hence we extend collective ownership to all aspects of product development. <\/p>\n

      \n
    1. Product planning<\/li>\n
    2. Coding<\/li>\n
    3. Keeping it running in production<\/li>\n<\/ol>\n

      Everyone on the team should be not only be free, but encouraged to <\/p>\n