Thinking for a Change

We’ve launched the Call for Sessions for XP Day Benelux 2007.

Why not send in a session yourself, even if you’ve never written a session proposal before? In the spirit of agile and cooperation, session presenters work together to improve their proposals. After all sessions have been submitted, we have two months to improve the sessions and their descriptions.

After that the program committee creates the program, taking into account the quality of the proposals, while trying to offer a good mix of session subjects for participants with different levels of experience with agile methods.

Session deadline is June 30th

The conference will be held on November 15th and 16th 2007 in Mechelen, Belgium.

Read more…

The afternoon of the second day

Ignace and Yves Hanoulle were busy the whole day with the “Leadership Game” and “Help! My Team is at War!” sessions that were fully booked. I saw people sprinting to the session to be amongst the lucky few who could attend these size-limited sessions. From the pictures you can see that these sessions were again very succesful.

My project faces a crisis! Yippie!

My favourite session of the conference was Antoine Contal and Regis Medina’s “Débloquer un project avec XP“, where they told (and acted) the story of a struggling project and how they used XP techniques to get the project back on the rails. The slides were very “Zen“, the opening picture of a fireman putting out a fire from a comfy chair set the stage. Hey, if your job is putting out fires all day, you might as well get comfy! The delivery of the material was very funny, especially in the beginning where they acted the way people reacted to the situation and the changes.

A project in trouble can be your greatest nightmare. It can also be your greatest opportunity. All too many projects are unhappily limping along. The situation isn’t great, but with a few band-aids here and there, the cracks can be hidden. Often it’s only when there’s a real crisis and short-term tricks don’t help anymore, that you can get real change going. It’s either that or crashing. Many tales of agile, lean or Theory of Constraints change start with words like “The company faced bankruptcy…” or “The project was going to be canceled…”.

People have a way of rationalizing away problems, forgetting the pain. They don’t believe there’s any solution. If there was one, they would have found it by now. The salesman/change agent’s job is to make the pain felt again and then to give the hope that the situation can be improved a bit. Not too much, otherwise they might not believe you. As Gerald Weinberg says in “The Secrets of Consulting“: never promise more than a 10% improvement. Promise more and your customer won’t believe that it’s possible; deliver more and you make your customer look stupid.

Antoine and Regis identified four axes in which they intervened: planning, design, code, people. Generally I start with planning too: define a release schedule, decide what’s put in the first release (not too much!) and get the team to release something quickly. That way the team builds confidence, we get visible progress, we have some idea of team velocity and we have a basis on which to improve with retrospectives. When you’ve got that going, the team will sort out most of the design and code issues themselves. Team issues will become clearer to all, ready to be solved.

Debate: where are we with the software development profession?

Laurent Bossavit moderated a debate about the state of software development. Software development was compared with either craftsmanship or manufacturing, taking into account the positive and negative aspects of both models. I see the Toyota Way (and the way it is used for product development) as a way to combine the advantages of both models.

During the debate two thoughts struck me:

• we waste a lot of time with “technology churn”, seemingly totally new ideas that to me seem to be no more than shiny repackaging of old ideas. As someone jokingly said “web applications are just minicomputer applications with terminals. Except that this time round we can use colors”.
• we waste a lot of knowledge by discarding people. While the old fogies who programmed these minicomputer applications were put out to pasture, a new generation spent years reinventing the same application models.

Farewell drink

Just enough time for one drink and get an update on what some people are working on. And then back home.

Me and my binôme

The first session of the day was “Un clavier pour deux“, presented by Jacques Couvreur and Nicolas Charpentier, about the theory and practice of pair programming (“binômage”). Nothing very new for me, but this was a clear and solid introduction. I thought the presentation would have been better with a more “Zen” presentation and with fewer slides, as Jacques and Nicolas had to skip some slides due to lack of time.

Les chiffres pour convaincre

Olivier Lafontan gave a presentation with “lots of numbers to convince managers of the value of agile“. Olivier used a spreadsheet to contrast different project approaches and see which one delivered the most value, which one broke even first, which one required the least amount of capital investment…

The worst strategy was the one where the application is released (and stops costing money and starts earning money) at the end of development. Duh! A lot better is an strategy where the application is deployed incrementally, with the assumption that each increment has the same value (4 increments deliver 25% each of the value). That’s not necessarily a good assumption: if we can schedule high value stories early in the project, the project becomes even more profitable. We can do even better than that: if the last remaining stories have a poor value/cost ratio, why not drop them altogether? In this case we only deploy 3 (or even 2) of the 4 planned increments.

Olivier then used the same technique to show what the effects are on programme management. Here the results are even more dramatical. If we use the last strategy (implement stories by value, drop low value stories) we can start more projects and start them sooner to get more benefit.

We had some discussion about estimating techniques, the organisational maturity required to implement these techniques and ways to incorporate the maintenance cost in the simulation. I believe that if we include maintenance costs, we can also show the value of delivering high quality, tested, refactored code.

A great session. To make it perfect, Olivier should include graphs of the spreadsheets in the presentation. Loads of numbers in small font are hard to read and interpret. A few graphs (which alternative gets to break even first, which alternative has the highest value after 2 years…) would make the conclusions really clear.

If you don’t do this already, start asking your customer to estimate the value of user stories. Estimating value is quite easy if you do it the ‘XP Game way‘: sort the stories from high to low value, compare with previous stories to have consistent estimates, group and assign relative business value if you have no previous stories. Economics for beginners:

• Money today is worth more than money tomorrow
• Look at value/cost when buying stuff
• The cheapest story is the one not implemented
• Money costs money. Reduce your investment by incremental funding and rapid payback.

And remember kids: if your customer says they can’t put a value on a story, assume that the story is worthless.

Maybe your CIO or IT manager won’t understand this. Talk to your CFO and CEO, they will understand the value of agile.

More about XP Day France next post