Antoine Contal and Régis Medina presented a Lean coaching case study
at the Geneva Agile Tour 2009.
I had the opportunity to discuss with both presenters prior their presentation.
When asked “Can you explain to me Lean ?”, the answer is hesitant.
Régis tells me that despite the quantity of books he has read on the subject, conferences he has attended and his practice, he admits beginning to grasp its essence only very recently.
Antoine adds that the basics are obvious to most of us, but that we very rarely put these into practice.
Wow, I shouldn’t expect enlightment in a one hour presentation.
But as you’ll see, this presentation really convinced me of studying Lean….
Antoine is responsible for a software team at Orange, in charge of projects related to WebTV.
Situation was not that bad with a development succesfully delivered under a strict deadline.
But the marketing department was not fully satisfied with the frequency this team could
deliver new features.
Régis was then called to help boost this team.
Some key Lean concepts were introduced thanks to this real coaching experience (3 monthes long).
Antoine and Régis had chosen the form of a dialog for their presentation.
Régis asks questions about how things are done, and based on Antoine answers, makes suggestions.
Plan / Do / Check / Adjust
This practice sounds straightforward. But :
- Régis insisted on having something to measure.
What’s the point of having identified a problem, planned an action if we do
not have a simple indicator of progression to use ?
- The plan contains in itself the criteria of success
(the Check phase is “designed” in advance)
As interesting as this seems, do we apply this practice in our daily projects ?
Take care ! It’s the contrary of external standards being imposed.
It’s also the contrary of creativity killer.
My translation to this would be a piton for climbing.
You want to secure your progression. No place for occasional luck.
You want that the next person to follow this track will find a rock solid solution to ease his/her climbing.
You’ve found a solution to difficult recurring problem ?
Make the solution repeatable.
Turn it into a habit, almost invisible : a standard.
I liked the illustration given from Toyota Production System.
Under some machines, they have painted the floor in white.
Each oil leakage is immediatly detected.
Here, it translated into displaying metrics directly related to the problem expressed by the client.
The classic burndown chart is cool, but other kind of graphs were built to better match with their
Hands on code !
Régis asked then Antoine, if he had dug in the source code of their apps.
Antoine had to confess that he was too busy with plenty of other things.
Once he allocated the time to study the code, he quickly discovered, hum, that its quality was not up to XP standards.
Pair programming sessions were organized to raise the quality of the code.
This practice of emphasizing the skills of persons on the production line (developpers) is
just the opposite of what we witness in Europe :
to progress in his/her career, a software developper must leave coding for management
The tools needed ?
Eyes + Brain : anyone’s fully equipped ?
Observation and decision are not done by complex tools yet !
The interesting part comes from the conclusion.
Clear and dry. No fluff, just honesty.
No revolution in the team performance. (Note also that no degradation was observed)
Antoine even said that this experience fully convinced him of going on the Lean way.
He summarized (and here I might distort a litte bit)
SCRUM is for teams that want to adapt and follow their client.
LEAN is for teams that want to tear competition into pieces (“déchirer en français dans le texte ;-)”)
But it takes time.
Lean and XP
I couldn’t help myself from thinking that Lean principles helped design some XP practices.
Some naive examples that come to my mind:
- Planning Game
P choose User Stories
C Acceptance Tests
- TDD is amusing because it would translates into CDPA, and into embedded standards (in a sense automatic process). Other comparisons to Lean practices could be found for TDD, I’m pretty sure.
- Visual Management
Continous Integration that “shouts” each time the build is broken.
Red/Green in Unit testing.
A funny conclusion came with a question from the audience
“So, when can we expect results ?”
Régis quickly replied
“I don’t know, 20 years ? Who cares, as long as you continously improve ?”