April 9, 2014
I was doing an Enterprise 2.0 Masterclass to a group of technical national directors at INSEP (French national institute of sports) and one of the attendee asked me this question : “How can I quickly assess my organization culture ?”
It has just occurred to me that this can be carried out very easily, asking just one question, so I asked them :
April 8, 2014
Un petit retour sur une conférence Lean Summit 2014 qui s’est déroulée à la cité internationale de Lyon les 2 et 3 Avril. Plutôt passionné par les technologies et tendances du numérique, il s’agissait d’uns conférence de laquelle j’attendais peu. La surprise ne fût que plus belle, avec un évènement qui s’est avéré être un des plus marquants auxquels j’ai assisté, et pas seulement en raison de la fontaine de chocolat.
La raison en est toute simple : il ne s’agit pas d’une autoroute pour consultants, experts ou éditeurs mais d’un espace dans lequel des dirigeants racontent leur histoire, celle de leur entreprise et expliquent comment le lean leur a permis non seulement de survivre mais d’obtenir des résultats exceptionnels tout en impliquant leurs équipes.
A une époque où, à grands renforts de propagande, le Lean est dépeint comme un outil d’assujetissement à la productivité et où le Made in France évoque plutôt une résignation désuète ou un pleurnichage institutionnel, cette conférence rafraîchissante et tonique a clairement rappelé qu’il s’agissait surtout d’une alternative crédible pour continuer à créer de la richesse de façon soutenable dans notre beau pays …
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.
April 6, 2014
In the fall of 2009, at the time I started digging deeper into Enterprise 2.0 and the management principles this organization approach implied, I set up a list of 10 management principles and how it differentiates with management as we know it.
About 12 months later in November 2010, Jim Womack, co-author of The Machine that Changed the World or System Lean, wrote a piece called Lean Management Vs Modern Management where the author applies a similar approach and compare 10 key Lean Management principles with the corresponding approach in Modern Management. Read the rest of this entry »
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.”