Scrum + Craftsmanship != XP

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 Software Craftsmanship movement, which aims at raising the bar for code engineering practices. It also stresses out that a code must make those practices his own responsibilities.

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. 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 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 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 int 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 ?

That’s impressive

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.


5 thoughts on “Scrum + Craftsmanship != XP

  1. “Sustainable pace: not explicitly supported by Scrum, but promoted by Craftsmen”.

    Mos def…How do you want to keep sustainable pace if you “Sprint” all day long? 😉


  2. “That being said; I think I made my point clear.”
    well, to me, it’s not that clear :
    Pair programing (not only for teaching), TDD, collective ownership(and coding standard), emergent design, constant refactoring are promoted by most software craftsmen I know.

    I use them (and others) because I think they are the best tools I currently know to deliver software of high quality (both inside and outside), but I’ll be happy to use other tools to achieve same goal if we find such one day.

    Because Software Crafstmanship, it’s not about tools, methods, technics. It’s about delivering software of high quality, in a professional way. Softwares that will enjoy our clients/customers/users and that futur developpers won’t fear to change/adapt/evolve to match futur needs of the application.


  3. I understand (and fully agree) that a fair share of craftsmen uses/promotes most of those practices. But I also had long argument regarding the value of TDD with people that I still consider as craftsmen. Ultimately, craftmanship is a mindset and a set of values before any practices!

    As an attempt to clarify furthermore: applying Scrum by the book with no regard to technical aspects is a recipe to disaster. Trying to compensate by adding craftsmen to the mix will only partially help, unless/until those craftsmen have a significant voice during sprint planning and other conversations and can put quality at the center, and not as a development activity!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s