Agile carpaccio

An agile elephant Photo by Kevin Philipson on Unsplash

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.


  • 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.


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.


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 other 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 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:

How to save Agile?

My previous article raised quite a stir

and did get a lot of feedback, so thanks to every one that reacted. Some of those reactions were positive, some were not. But some of those made me realize that my message may not have been clear enough, so I will start by rephrasing it before moving on. When I say that Agile is failing, I mean that the current Agile hype will lead to a great hangover, the kind of hangover that could simply put Agile in the history books as yet another failed attempt to improve projects, next to RUP and others.

The signs are here: a lot of articles attempt to find the cause in non motivated developers, incompetent middle managers, hostile management, consultant selling scrum as the 21st century snake oil, locusts…

I mean, the end is nigh OK, but maybe no locusts yet..

In any case, I do not buy into these; I am not saying they are false either, but they can’t see the forest for  the trees! In an era of continuous improvement, most organisations are able to address this symptoms. That is, assuming they are in a position to identify them. Otherwise, they will just see that Agile fails and be done with it. Alternatively, they will tolerate Agile if the team can establish a roadmap as well as an overall architecture design that can be reviewed and challenged. In the long run, this implies a slow death of Agile, turned into ‘Scrummerfall’.

I know that some of the radical agilists have said: we just need to beat them at their own game and be done with those who can’t adapt. This sounds both  cynical and naive as a vision. Economy does not exactly works this way, Agile methods are tools in the toolbox, nice, flexible and efficient, but they are tools!

So how to survive the fad phase?

By keeping on delivering, which implies fighting off pseudo agile, but also by augmenting agile methods so they can be actionable at a higher level.

With ‘plan based’ project methodologies, the plan is a strong steering tool to ensure the project matches the enterprise strategy, and tracking progress on the plan is sufficient to control that.

But agile methodologies starts with a set of goals and a scope, maybe a bunch of user stories, nothing really tractable at a higher level. And when the project starts, the ad hoc reporting format used is not appropriate for dissemination. At that, at a strategic level, the project is more or less opaque so not really controllable. The main, if not single, link between the project and the strategy is the product owner.

We need to make sure that actionable information can flow from the project to the strategic view. Vice versa, we need also to have a clear view of the enterprise strategy at the project level too, so that the team can position itself into this strategy.

Of course, for small/simple structure, this is probably the de facto situation, but for larger organisations, tools must be identified.

That being said, all contributions are welcomed, and I definitely think Impact Mapping shows us the way.

Why Agile is failing

Now that Agile is mainstream and that most, if not all, organisations are implementing agile methods, I am hearing more and more voices raising concerns and warning about how poorly those organisations perform afterward. Most often cited causes are management obstruction, poor discipline in the development team, local mutations of scrum and so on.

Photo by Sandis Helvigs on Unsplash

They are wrong, they got the root cause wrong plain and simple.

I let that notion sinks in.

Right now you are probably suspicious, maybe a bit angry. But at least I got your attention and I can get to the message:

It is not the organisations that fail Agile, it is Agile that fails organisations. I guess that most agile practitioners are just pissed off now, but please, keep reading. I am a convinced XP practitioner myself, and I feel sorry for the mess I see around me, I am just trying to do my bit. The problem is that Agile is not yet enterprise friendly:

#1 Having happy customers is not the actual goal of any commercial enterprise

Its goal is usually generating value for its shareholders. Of course, having happy customers is the proper approach for that.

#2 Money does not flow directly from the customer to the project team

The typical structure will be that it is some customers’ representative that will pay the project team management, most of the time some manager or some other part of the organisation. That represents a bunch of people that are not involved in the project, and who do not care about agile at all.

#3 Agile methods emphasis local objectives

Due to fast iterations, decisions are taken locally to the project without any interference from top management or other part of the structure.

This makes Agile a sure path to project success, as measured in customer satisfaction. But it also generates stress by keeping the rest of the organisation, especially top management at a safe distance from the project. Therefore, the organisation reacts by trying to control Agile, making sure projects stay aligned with the enterprise strategy; or it remains hostile, or simply fails to provide adequate support. And it just kills any benefits.

The good news is that it can change. Agile can change to register itself in the enterprise strategy. Gojko Adzic‘s Impact Mapping is a promising tool to integrate strategy and increase the relevance of projects by ensuring a shared and clear goal is established early on. On the other side of gap, Jurgen Appelo works on what he calls Management 3.0 aims at bringing Agile in the management world, completely transforming how teams must be managed.

So, please read the work of those great guys, and raise your awareness about enterprise topics if you want to help Agile succeed.

And in the meantime, stay disciplined and keep up the good work.

The danger of microbenchmarking

Performance measurement is a hot topic

in IT, and it has always been so. How fast is the new hardware, which RDBMS has the highest TPS, which implementation has the lowest memory footprint…

Nowadays, pretty much anyone with a decent knowledge of a programming language can write some benchmark and publish his results, so benchmarks flourish everywhere.

Please read them with the colloquial grain of salt: measurement is hard and more often than not, the benchmark may include some bias favoring the author expectations. The bias will probably be accidental and of limited impact, but it will be there nonetheless.

But I wanted to discuss about microbenchmarking, with a focus on concurrency related ones.

Continue reading “The danger of microbenchmarking”

NFluent 0.5 is out

NFluent 0.5 is out

The beta version of nFluent as just been released on nuget by T.Pierrain. For those who may be wondering, nFluent aims at bringing to the C# ecosystem all the benefits provided by the FEST assertions library.

It supports english like test assertions and rely on auto-completion to guide developer into the writing of tests.

Plus it provides explicit error messages, making test driven fast and fun!

PS: for transparency, please note that I contribute to this initiative.