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  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.
Continue reading “Scrum + Craftsmanship != XP”


Agile carpaccio

I had the opportunity to beta test an agile carpaccio workshop. For those who may never have heard about this, carpaccio approach insists that user stories drive your deliverable, up to a point where you are able to deliver on a per user story.
The analogy to carpaccio relates to the fact that one is supposed to work through a user story end to end and deliver it, so implementing the solution slice-by-slice.

Here is how the exercise was done:

User story: compute a total price with an item unit price, a quantity, a (US) state to identify tax rate and a discount policy based on total price.

Constraints: 8 minutes iterations, including a working demo to the customer.

Initiation: blank project, environment of your choice.

I was pairing with Thomas Pierrain (@tpierrain), so we chose a console application in C# as our delivery package, TDD as our approach.

Iteration #1:

created the appropriate project, paired the MBA with an IPhone, used Nuget to retrieve nUnit and nFluent
Added a banner to the app, build it.
Started the first test.


Iteration #2:

Demoed the app, customer is pleased: we are capable developers
Finished first test, which test tax computation. We hard the tax rate to the Utah value, as the customer states that most of his business is done there.
In a true red green re-factor approach, we hard code the expected result
Our console app now outputs a sample results, with unit price quantity and taxes.


Iteration #3:

Demoed the app, customer is happy, he can confirm it matches his expectations.
Add message and input capture for price, including an input sanity check.
Copy paste the code for quantity.


Iteration #4:

Demoed the app, but it is not working, the computed result is zero. We did demonstrate some progress, but also suffered regression.
This is due to the absence of unit tests for input.
After the demo, the culprit is quickly identified: copy-paste-incomplete modify.
We start working on support for variable states.


End of the exercise.

We have a working deliverable, and it passes the acceptance test, which was to compute a cost for a Utah based delivery. We were probably at 50% of the target, but with only 4 iterations it was not so bad. Most of other teams had implemented more features, but all of them failed to have an actual deliverable, they were still at the prototype stage.


  • It was immensely fun to do fast paced development.
  • It demonstrated clearly the value of having a workable product as soon as the first iteration as a communication media.
  • It also demonstrated it is feasible, whatever your iteration/sprint length.

As a summary, a highly recommended exercise, whatever your expertise level is, as it helps us refocus on what matters to the customer.

Link to Alistair Cockburn original exercise: