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.
- Planning game: explicitly listed by Scrum, no discussion there
- 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.
- Small releases: not stated as an objective, but is a side benefit of short iterations
- Sustainable pace: not explicitly supported by Scrum, but promoted by Craftsmen
The following practices are engineering practices and as such, absent from Scrum.
- Pair programming: supported by Craftsmen, but more as a learning/teaching technique.
- Collective code ownership: this is more of a team practice than anything else.
- Continuous integration: quasi mainstream nowadays.
- Coding standard: quasi mainstream nowadays.
- System metaphor: equivalent to DDD’s ubiquitous language.
- Simple design: a fundamentally pragmatic practice aiming at keeping the software design simple by providing what is required and nothing more.
- Test Driven Development: promoted by the Craftsmanship movement.
- 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.
6 thoughts on “Scrum + Craftsmanship != XP”
“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? 😉
“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.
Thanks for your feedback Avernois! Just to be explicit, my critics are aimed at scrum, not at software craftmanship.
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!
Cool post. I like that you’ve identified XP’s lightweight management process (LWP) from its agile engineering practices (AEP), and that XP’s AEP is strongly dependent upon XP’s LWP.
So substituting Scrum as a LWP in place of XP’s LWP will work against (or even thwart!) XP’s AEP.
(That’s a lot of TLA!)
Scrum Masters of the Universe – that’s funny! Dev•Man says, “By the power of Schwaber and Sutherland!”
I’ve used Scrum at three companies, to various degrees of success at each. All of which fell somewhere within the bounds of Martin Fowler’s FlaccidScrum (or what I call “Scrum without the agile”). Yet we still shipped product.
We had little to no AEP, because management wasn’t interested in it, and cut it off at the knees. sigh. I hope the Craftsmanship movement gets traction in Scrumlandia.
Schwaber and Sutherland would have chastised us severely by saying “You’re doing it wrong,” and slapped down their “The Scrum Guide”, and highlight the Dev Team is responsible for AEP (even though specific AEPs are not prescribed by Scrum itself). Robert Martin would have slapped down his “Clean Code” book. Mike Cohn would have slapped down his “Succeeding With Agile” book. I’ve read all of those. They’re all excellent, imo.
But there seems to be a vast schism between theory and practice, in the places I’ve worked at.
Scrum by the book with no regard to technical aspects is a recipe to disaster. (OH DRAT, you beat me to the punch!)
I’ve never used XP. Almost got to once, read Kent Beck’s XP book, the team was ramping up to do it… but the dot-com bubble burst and half the company got laid off. /sadpanda