Lean software: ne vous trompez pas de cible

Au détour de mes lectures sur divers blogs et des échanges avec mes pairs au sujet du Lean Software Development, je trouve qu'il se répand une idée reçue assez dangereuse: faire du Lean signifie éliminer les gaspillages. Dans les faits cela se traduit souvent par une chasse aveugle et impitoyable au moindre gaspillage. Les résultats vont parfois du désastre à souvent une amélioration molle et peu durable. Pourquoi ?

A tous ceux qui pensent que Lean signifie supprimer les gaspillages, je souhaite suggérer un retour aux fondamentaux, c'est à dire au monde de l'automobile d'où nous vient le Lean. Certes, dans un précédent post je me gaussais des parallèles périlleux entre domaines d'ingénierie, mais je ne suis plus à une contradiction près. Et puis comme le souligne le commentaire de PIF, il faut savoir cross-fertiliser, si je peux me permettre le néologisme.

Mura, muri, muda
Fondamentalement donc, la "pensée lean" consiste à éliminer 3 facteurs d'inéficience: le mura (surcharge), le muri (variabilité), le muda (gaspillage volontaire). Dans une lettre datée du 6 Juillet 2006 (traduite en français), Jim Womack nous éclaire sur la façon d'aborder ces facteurs. NB: Jim Womack fait partie des 3 rédacteurs du livre fondateur du Lean The Machine That Changed the World. Jim nous suggère d'adresser d'abord la variabilité et la surcharge, et ensuite le gaspillage volontaire. Il confesse lui-même avoir initialement abordé ces facteurs à l'envers. Son constat est sans appel, si vous commencez par supprimer les gaspillages, vous allez générer de la variabilité et de la surcharge de manière incontrôlée et par conséquent ré-introduire d'autres gaspillages ailleurs dans votre système par effet de compensation. C'est un cercle vicieux. Le message est donc clair: maîtrisez la variabilité et la surcharge dans votre processus, ensuite diminuez ces facteurs à mesure que vous éliminez les gaspillage. C'est la meilleure façon d'implémenter des améliorations durables.

Qu'est-ce que la variabilité dans l'ingénierie logiciel ? Les livraisons sans cesse décalées, des petites livraisons suivies de très grosses releases suivies de petits patchs, etc.

Qu'est-ce que la surcharge ? Des équipes qui travaillent 12h par jour, les week-end d'astreintes, des serveurs de dev en permanence au taquet, etc.

Agilité, agilité, agilité

Je ne vois qu'un moyen simple d'éliminer ces 2 facteurs variabilité et surcharge: passer à l'agilité. Que vous soyez Scrum, XP, Kanban, ou autre, vous livrerez des petits lots de tailles similaires avec des échéances fixes, cela adresse pour partie le problème de variabilité. La surcharge est adressée par les valeurs de ces différentes méthodes, il faut évidemment une certaine discipline pour éviter le surengagement, mais la diminution de la variabilité permettra de réduire l'effet de "bourre" avant des grosses livraisons.

Un conseil en forme de conclusion: ne faites pas de Lean Software Development sans passer par l'agilité, les résultats risquent d'aller à l'encontre de vos objectifs. Et vous, quel est votre expérience du Lean Software ?

Bent Jensen presented Lean to Valtech consultants

Yesterday evening we had a presentation of Lean Software Development by Bent Jensen at our Valtech premises in Paris. Bent is helping Elisabeth, a colleague from Valtech, in a mission where our client wants to apply Lean techniques to reduce the cost of their product. Bent has spent a couple of days in Paris and we took this occasion to organize this presentation in the context of our weekly evening training agenda.

Bent made a clear and concise presentation of what Lean is and where does it come from, as well as he explained what Lean actually means in the software development field. After the presentation, Elisabeth talked about their ongoing mission and what they achieved so far, illustrating her explanations with pictures from battlefield.

I really appreciated to hear and discuss application of Lean in software development field. After reading the reference book The Machine That Changed The World, that gave me much more concrete examples and analogies in our field. The point of the presentation that I especially recall is when Bent talked about so-called exploration phase (first iterations) and construction phase (after some iterations) in the lean development process he sketched on one of his slide. He pointed out that this is the way Toyota does in their product development process. Lots of talks are going on in the Agile world whether running an "iteration 0" to settle down some architectural components or frameworks. I think he had an interesting point for this debate. To some extent, what Bent presented recalls a bit the RUP (Rational Unified Process) with its elaboration and construction phases (but no idea here of inception and transition).

Bent's company has a blog where he posts news. I found there some of the stories he told during his talk, like the Lego bug tracking system or his trip to Japan.

(Feed)Back from XP Day France 2008

I attended the XP Day France 2008 last week, and also gave a talk on the second day. The conference was a success as they recorded more participants than last year. From my point of view I participated in sessions much more interesting than I expected, and especially enjoyed some enriching workshops.

In the morning of day 1, I attended the workshop on Lean System. That was a role-playing game in which a team had to build 10 paper-shadocks in an assembly line-like mode during rounds of 10 mins. After each round the customer (the workshop leader) would accept or reject the finished units depending on what she found acceptable. The project manager would then calculate the financial results based on the sells (accepted shadocks), consumed commodity (paper sheets), team-member wages, facility (tables), etc. I played the shareholder, not a very demanding role as I just had to sit and wait for the financial results, then look very disappointed as the results were quite bad until the last rounds. Before beginning a new round, the team could only take 1 action to improve the output and increase the overall results. Beside being fun, the workshop actually tought some interesting lessons while it was not really focused on software development:

• first of all, I realized that Lean System is not mainly about removing waste, it is firstly about removing variability among instances of the same steps. This point, though, might not make much sense in software development and this is probably why we talk much more about removing waste in lean software development,
• applying lean system may drive to reduce human resources while increasing productivity and quality. I thought only productivity and quality was the focus while keeping stable resources. The workshop leader therefore stressed that initiating a lean system within an organisation might fail badly if it does not happen in an economically favorable context, because employees will not contribute to a system that might lead to removing their job.

In the afternoon of day 1, I attended the Lightning Talks led by my colleague Yannick. I also made a try at the XP laboratory but soon left the session as it turned too technical to me. What I experienced there was indeed very weird: at the beginning of the session, the organizers explained briefly what was realized thus far and what was the stories they proposed to make in the first iteration of the session. They then asked whether the participants were comitted to delivering these stories by the end of the 10 mins iteration. And guess what, nobody said no ! None of us had a clear idea of the existing design, code quality, or past problems, but we all comitted to deliver the stories. Even more striking is the fact that everyone but me then rushed to the available laptop PC to dig in the code and start programming. Well, I left the session soon after as I'm quite unable to undertsand or program a line of JAVA. I did not feel like that was a great XP application. I however had the occasion to discuss this brief experience with the workshop oragnizers, François Beauregard and Eric Mignot from Pyxis, and it confirmed what I felt: the organizers let the team made some mistakes so that they could learn the XP values. They also were very surprised that no one, whatever the sessions, refused the comittment on the proposed stories having no idea of the design and problems. This is even more striking knowing that this laboratory did not have any financial stakes and that most of the participants are not beginners in the Agile world. That makes me think the way is still long until we master the Agile values and apply them naturally.

Day 1 ended up with a good dinner. I had the occasion to discuss extensively with an employee of Parkeon, especially on their use of FitNesse. I now have better examples to share if I encounter again the objection that FitNesse and TDR techniques are not suited to embeded software (objections that I often hear when I'm teaching the TDR course).

On day 2 I opened the day with my talk on Test-driven Requirements, while 2 of my colleagues also made a presentation (Romain on continuous integration and Nathalie on contracts for agile projects).

I then attended a very enriching workshop about Leadership. The principle was simple, the participants had to build structures with Lego blocks. We run three such sessions, each with a different type of leadership. The first session was driven by 2 leaders with a commanding type of management, the second had no leader and the team built a church in a self-organizing fashion, and the third had 2 coaching leaders (I was one). A global restrospective at the end gave us the opportunity to discuss the characteristics of a good leader and what they missed to do in the exercise. Beyond the lessons that this workshop was supposed to bring about, I realized something more after the retrospective: when there is a leader, everyone holds him responsible for the failure or success of the exercise, on the other hand, when there is no leader, everyone tries to identify what was good and bad with herself or himself. In brief, we are naturally feeling responsible when there is no designated leader while we naturally shift all the responsibility on the leader's shoulders when there is one. What this workshop tells to me is: if you're a leader, expectations will be high on you whatever the type of management you're applying, so you'd better succeed :)

Finally I attended a presentation on practicing the conflict. The presenters made their talk dressed in kimonos and played small funny scenes to illustrate their points. Briefly speaking it was about using an aikido-based technique to master a conflict and not to avoid it. Beyond these techniques, they stated that conflict is a mandatory step towards successful teams, argueing that conflicts can bring about better solutions. Although I understand and share some of their points, I still cannot consider that the conflict is a must have for successful teams. I rather think that confrontation is a must. Sometimes confrontations turn into conflict so we indeed need techniques to master conflicts but I don't see them as a healthy step toward sucess.

Before leaving, I spent some time discussing with the Pyxis guys and getting a demo of Greenpepper (great tool!).

That was my experience of the XP Day 2008 !

The (Toyota) way to go

Toyota has become the biggest car producer in 2007 overtaking General Motors who had been holding this position for 80 years. This is quite a big news! Toyota has been paving the way to efficient production management for decades, inventing lean and other manufacturing management concepts. Lean can be applied everywere and be transposed to many other businesses. Lots of companies look in this field to improve their process throughput while keeping stable resources.

In software development field, the definitive reference for lean thinking is the work of the Poppendiecks, which is gathered on their website. Many agile development models and practices are either inspired by lean thinking or verify lean principles:

• TDD implements a perfect "pull" organisation of the code and unit tests tasks
• eXtreme Programming has many practices verifying lean principles (Jacques Couvreur wrote a good article on how XP relates to the Toyota way),
• Continuous Integration and software factories are a way to make jidoka happen in the software development process
• Test-Driven Requirements (TDR) is an extension of TDD, applying lean principles to the other steps of the software development process (I made a presentation, in French, on this topic during the Valtech Days 2007)
• and so on...

Although it seems Agile Values were not directly inspired by Lean Thinking by the time of the Agile Manifesto, there are so many connections today in the software development field that it is difficult to differentiate either one. However, I think that Lean covers a broader area of interest. Software development organisations that seek to be "agile" today will probably seek to be "lean" in the coming years.