October 6, 2014
Les inscriptions sont toujours ouvertes pour le Lean IT Summit des 16 et 17 octobre. C’est une occasion unique de rencontrer des grands noms du Lean et de l’Agile réunis cette année à Paris :
- Jeff Sutherland, inventeur de SCRUM
- Mary Poppendieck auteure de “Lean Mindset” and “Lean Software Development”
- Jeff Gothelf, auteur de Lean UX
- et Dan Jones, l’inventeur du mot Lean.
August 27, 2014
Lorsque j’ai décidé l’an dernier d’infléchir ma carrière professionnelle pour me diriger vers le conseil, deux chemins se présentaient, tous deux prometteurs : Entreprise 2.0/Social Business d’un côté, Lean de l’autre.
Au terme de longues réflexions, j’ai choisi la seconde option car elle me semblait plus profondément en phase avec les enjeux des entreprises d’aujourd’hui, à savoir la nécessité de naviguer dans les turbulences du monde incertain qui est le nôtre. Ces turbulences et ce monde incertain sont en grande partie liés à la digitalisation de notre quotidien : la transformation digitale (ou numérique) des entreprises semble donc inéluctable.
Le Lean m’apparaît aujourd’hui comme l’évidente stratégie pour mener à bien cette transformation, pour les raisons suivantes :
- la transformation digitale correspond à une radicalisation de l’exploitation de nouvelles opportunités technologiques,
- il s’agit avant tout de principes de management
- un modèle existe, il s’agit des entreprises nées numériques (Google, Amazon, Facebook, Pixar, Twitter etc. …)
- leurs cultures de management sont toutes, explicitement ou implicitement, alignées avec les principes du Lean.
- (oh : et l’Entreprise.fr part avec un handicap culturel dans cette transformation)
(Je vous écris un long billet car je n’ai pas le temps d’en écrire un plus court, paraphraserais-je Pascal : attention, plus de 2000 mots)
I had a second article published today on InfoQ : Seven changes to remove waste from your software process.The first one being quite popular (a few weeks in the site top articles) Ben asked me to write another one, which I gratefully did.
It can be seen as another technical (and, I hope, actionable) article on my journey towards Lean while scaling agility to a full organization.
Thanks to Ben Linders for editing and Ana Maria Ciobatoru for her work in making it look great.
I have been in charge of implementing Lean Software Development in a software vendor house for about 2 years. During this time I have been coaching a large team throughout the development of two successive versions (let’s call them V2 and V3) of our enterprise solution.
We have gradually implemented seven major changes in our organization that have helped our R&D department to remove waste from our software development process with encouraging results. This essay is about implementing these seven changes, the results we obtained and what we have learned during the journey.
Read the article here.
April 7, 2014
One of the misconceptions I’ve made while working with software development teams using agile methodologies is that I initially confused bugs with problems and I tended to believe our agile process was Lean, as it made bugs visible. During the last few months, this idea has cleared up a bit and, in retrospect, I now believe that our agile team producing bugs was not a Lean system producing learning opportunities : it was a team having quality problems, which is something I have seen with many teams.
Back in the days when I was an airline mainframe developer whose career had been violently hit by Spetember 11, I was desperate to switch to Java professional world and was an avid reader of theserverside.com. Floyd Marinescu was its creator. He also later became the author of EJB Design Patterns – one of the first book where I read something linking the way we work with the quality of life (even if one may argue that it might be challenging with EJB, anyway …).
In 2006 he went on to create InfoQ with a strong focus on agile methodologies : it soon became my main source of information of all things agile. Having an article published on this site is probably as great an honor for me as it would be to jam with Johnny Marr.
The article, a rather technical one, is about the path I followed while slowly moving from Agile to Lean as I was getting to understand the key role of problems in continuous improvement. It also somehow is a more detailed follow-up of a previous article on Agile and Lean.
Many thanks to Regis Medina for introducing me to Ben Linders, to the latter for his great editing work and to Ana-Maria Ciobotaru for making it look neat and professional.
March 27, 2014
This is an excerpt from Time article about “How an unlikely group of high-tech wizards revived Obama’s troubles HealthCare.gov website”.
This excerpt focus on the three rules theses wizards apply when rescuing the project a set of IT services companies has lead to disaster. All Agile principles : stand-up meetings, developers get the call, get managers out of the way, solving problems completely, reduce work in progress etc …). An awesome story.
Rule 1: “The war room and the meetings are for solving problems. There are plenty of other venues where people devote their creative energies to shifting blame.”
Rule 2: “The ones who should be doing the talking are the people who know the most about an issue, not the ones with the highest rank. If anyone finds themselves sitting passively while managers and executives talk over them with less accurate information, we have gone off the rails, and I would like to know about it.” (Explained Dickerson later: “If you can get the managers out of the way, the engineers will want to solve things.”)
Rule 3: “We need to stay focused on the most urgent issues, like things that will hurt us in the next 24–48 hours.”
I am fortunate enough to count Antoine Contal and Régis Médina as my colleagues. We have been discussing this extensively, especially following Régis breakthrough on the topic (check his enlightening interview on InfoQ) and the dedicated panel Antoine moderated during the last Lean IT Summit in Paris.
Interestingly enough, we have somehow followed a similar path, though they were ahead of me by a few years. We found with Agile Methodologies a way to solve the same vexing issues while managing software development projects. How to better align software development with business value, how to release on a regular basis, how to build-in quality, how to engage development teams, how to embrace change : agile has helped us a big deal in answering these questions.
But still, we all bumped into some roadblocks that Agile alone can not tackle. We needed to go beyond and extend the reach of our improvement to include management, leaders, operations, marketing, problem solving and make continuous improvement a daily issue. And this is how Lean extends Agile reach in the enterprise …