My previous post, XP revival, dealt with the positive trend around XP as a project methodology. I explicitly stated that adding Craftsmanship practices on top of Scrum does not mean that you’re doing XP. In this post I am going to answer the explicit request to elaborate more on that topic.  It is a well-known fact that Scrum prescribes no engineering practice, leaving teams choosing the ones they see fit. A strategy that led more often than not to what Martin Fowler coined as flaccidscrum, projects which velocity drops to a halt. This situation also contributed to the birth  of the Software Craftsmanship movement, which aims at raising the bar for code engineering practices. It also stresses out that a coder must make those practices his own responsibility.

Those few statements obviously give a very rough and simplistic idea of what Software Craftsmanship and Scrum are. So let’s have a Scrum team of Craftsmen on one side, and an XP team on the other and see what they have in common. Both teams focus on delivering in an iterative way, expressing scope as a backlog of user stories; they keep track of their velocity and they gathered lessons learned along the way. That being said, let’s look at the 12 XP practices.

1. Planning game: explicitly listed by Scrum, no discussion there
2. Whole team: the product owner is listed and have an active role during scrum ceremonies, but he/she cannot be considered as a full-time team member, whereas XP explicitly states that the customer be present and available.
3. Small releases: not stated as an objective, but is a side benefit of short iterations
4. Sustainable pace: not explicitly supported by Scrum, but promoted by Craftsmen

The following practices are engineering practices and as such, absent from Scrum.

1. Pair programming: supported by Craftsmen, but more as a learning/teaching technique.
2. Collective code ownership: this is more of a team practice than anything else.
3. Continuous integration: quasi mainstream nowadays.
4. Coding standard: quasi mainstream nowadays.
5. System metaphor: equivalent to DDD’s ubiquitous language.
6. Simple design: a fundamentally pragmatic practice aiming at keeping the software design simple by providing what is required and nothing more.
7. Test Driven Development: promoted by the Craftsmanship movement.
8. Design improvements: states that the system design requires constant grooming.

So several practices are also listed by Scrum, some of the engineering practices are promoted by the Craftsmanship movement. But roughly half of them are orphans in a Scrum + Craftsman setup. Let’s review the potential impacts:

Coding standards: code base looses readability and accessibility. But I hope everybody has coding standards today.

Pair programming: numerous studies have shown that pair programming comes at a low production cost at worst. You should at the very least enforce pair programming for complex part of the code.

Collective code ownership: every team must strive for it; this practice aims at maximizing security and productivity. It also has a significant side benefit: realigning individual pride on the team goal, and not on some specific component(s).

Design improvements: refactoring has nothing do to with the backlog. Maintaining a healthy design is a continuous activity.

Test Driven Development: there have been a strong debate around the actual benefits of TDD as a design activity. Whatever you opt for, the team needs a disciplined design practice. You also need a trustworthy automated test base. I would also recommend you to look into implementing mutant testing in your continuous integration chain.

That being said; I think I made my point clear:

Adding Craftsmanship practices to Scrum does not lead to a ‘XP Like’ setup.

then, what about XP + Scrum ?

For me, this equation does not make sense at all: it is asking about piling up agile methodologies.

The core fact is: XP is a whole project method that gets its strengths from the high coupling that is created within the project team, sponsor/customer/product owner included. And we do not know how to scale this.

If you add Scrum on top of this, you are basically removing the customer from the team, impeding the sharing of information, therefore weakening TDD, which in turns may impair confidence in delivery, which adds the need for QA phases…

As a conclusion:

XP is a strong methodology, and probably the most agile you can get.  But, we still do not know how to scale it. A few years ago, I was convinced that XP could not scale, but I am not so sure anymore.

The fact is that for the past ten years, Scrum has captured everybody’s attention. This includes experts in management, leadership, organization, project management, in a word: scaling experts. I think they are the one who could help there.