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”

Advertisements

Quality is too serious to be left in the Craftsmen’s hands!

First contact

I must confess I have something of an ambivalent relationship with the ‘Software Craftsmanship‘ movement. My first contact with it was the discovery of some post about ‘developer’s pride’. personally, I am more a ‘developer’s humility’ kind of guy! Boasting pride sound stupid and short-sighted to me. Reading the manifesto and other articles somewhat moderated my initial reaction: striving for continuous self-improvement, promoting test driven practices are objectives I deeply believe in. Then my next realisation was that Software Craftmanship was basically promoting XP practices. But, instead of making them core to a team based effort, the craftsmanship movement promotes the idea that those must be a personal initiative.

Kinda cute but…

It looks fairly naive to me. Don’t get me wrong, it is important to embrace a quality driven approach, but if you believe you can transform such a large industry by the sheer goodwill of some engineers, I am sorry to say you are gonna be very disappointed. Furthermore, I think this may even be counterproductive as it will eventually create a split between craftsmen and your average developers, the formers being more consistent in their delivery than the seconds, but being significantly more expensive too.

By the way, lets speak it out in the open: quality has a cost, period. And let’s go to the core of the argument: Quality is too serious to be left in the Craftsmen’s hands.

Of course

Yes, it is often a smart investment, but it has an upfront cost. Therefore, it must not be hidden to the customer/product owner/sponsor. Most IT projects main deliverable is a code base and processes that transform this code base to a working software. And this code base is more often than not expected to be extendable, at least decently maintainable. That implies that automated tests are part of that deliverable, and one that significantly enhance the maintainability of it.

The question is then: what is the business value of tests?

Every other industry that I am aware of have a decent appreciation of the value of tests.

At the lower end you will find cheap plastic contraptions made by some sub par eastern factory: we don’t need test to understand we sell crap and replacing is cheaper than fixing.

At the higher end you will find the aeronautic industries where extensive testing is the norm: whenever someone fails, the whole industry is at risk.

Both of those testing strategies are relevant to the business model of the respective industry.

USE THE SAME APPROACH FOR YOUR PROJECTS!

negotiate with your customer/product owner the investment on tests. You have metrics to prove the effort:

– coverage (line or branch)

– mutant testing (demonstrate effectiveness)

Of course, regulatory constraint may as well drive the expected level of quality and testing.

So what about Craftmanship?

If you wanna engage on the Craftmanship journey, you have my full support. But understand that you have to adapt your testing practices to the wishes of your customer.

 

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.

Dong

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.

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 variable 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 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: http://alistair.cockburn.us/Elephant+Carpaccio+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 not locusts. 

In any case, I do not buy into these; I am not saying they are false either, but they are missing the forest for the trees! In an era of continuous improvement, most organizations are able to address those issues. 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 road-map 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 de 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.