Does Scrum promote craftsmanship?

Tom Breur

10 May 2015

Software craftsmanship is one of those relatively new, “trending” topics in the Agile community. I say “new” kind of tongue-in-cheek as in: the last 10 years or so. There is even an Agile lookalike manifesto.

My guess is that this movement was driven by (growing…) frustration about Agile being confused with “quick and dirty” (I wrote about this phallacy last year). People use (abuse!) a reference to “Agile” as an excuse for not documenting, deferring refactoring, and generally sloppy coding. There has to be a better way, and there is. But how does this fit in with Scrum?

I have always felt that XP focused way more on (software) craftsmanship. It is also more or less built into the process. Building the simplest possible solution that might work, and iterating from there. Emphasis on pair-programming also leads to sharing of expertise, and crafting (!) readable and understandable code.

Needless to say writing quality code will pay back in spades when the time has come to change, redesign, or expand it. Since more effort goes into maintaining code than writing it, it seems such an obvious notion. But the seduction of “delivering value early” can lead us astray…

In Scrum, relying on “craftsmanship” is implied. By this I mean that the adagio “delivering value early and often” (emphasis added), and delivering value in a “sustainable pace”, both suggest you cannot allow technical deb to accrue to the point where it would slow down future development. Still, this relies on discipline and standing up against the pressure to deliver quickly. The temptation might be to cut corners, in order to get Stories done. If your team chooses to make this explicit, you can do so by making it a part of your definition of done. Or else leave it to chance. What do you prefer?