I had the opportunity to beta test an agile carpaccio workshop.

For those who never have heard about this, the carpaccio approach insists that user stories drive your deliverable, up to a point where you are able to deliver on a per user story basis.
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 potentially forcing you to slice your user story in smaller increments that can be delivered within a single sprint. This is typically done by reducing the scope of use cases (see below for an example).

Here is the minutes of this dojo:

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

Constraints:

• 8 minutes iterations
• perform a working demo to the customer at the end
• demo time is part of the iteration

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.

The end of iteration will be signalled by a ‘Dong’.

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 working on the first test.

Dong

Iteration #2:

• Demoed the app, customer is pleased: we are capable developers!
• Finished first test, which test tax computation.
• We hard coded 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 coded the expected result.
• Our console app now outputs a sample results, with unit price quantity and taxes.

Dong

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.

Dong

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 other states.

Dong

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.

Conclusions

• It was immensely fun to do fast paced development.
• It clearly demonstrated the value of having a workable product as soon as the first iteration as a communication media.
• It also demonstrated it is doable, 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: http://alistair.cockburn.us/Elephant+Carpaccio+exercise