European Lean IT Summit 2011 – Wrap-Up

The First European Lean IT Summit was held on 13th and 14th October in the glorious premises of Centre National des Armées in Paris.

A great opportunity to see and meet Lean IT worldwide experts in Paris. Many speakers, great keynotes, good arguments, bold positions and many workshops to foster lean thinking in an IT environment. And a superb organisation by Operae Partners.

International superstars such as Tom & Mary Poppendieck, Steve Bell, Daniel Jones, Michael Ballé, Jean Cunningham and our local experts Pierre Pezziardi, Yves Caseau or Regis Medina all did pretty well in explaining the main challenges of Lean approach in the IT industry.

I’m still not sure how many principles there are in Lean (5, 7 or 14 as in The Toyota Way) so #hypertextual decided to align with the 7 principles approach as described in Implementing Lean Software Management by the Poppendieck‘s : a 7 points wrap-up just one click away …

1. Standards

This has been the subject of a great argument between Michael Ballé (a fantastic speaker and an interesting talk on waste introduced at Design Work stage) and Mary Poppendieck. Michael reckons that teams should follow standards regardless of the costs which Mary strongly disapproved.

My take : M. Ballé sees standards from a Lean perspective : based on field observation and refined through continuous improvement as Catherine Chabiron explained. While the standards in the IT industry most of the times come in a top down way from vendors, hence a rather defiant view by the software community towards these standards.

(A point clearly explained by Craig Larman in the strongly recommended Lean Primer paper : “Standardized work does not mean conforming to centralized standards”  also known as PDCA doesn’t mean Please Don’t Change Anything).

2. Measures

If there is only one take-away from this conference it has to be Tom Poppendieck’s :

The way you measure is a great mean of governance, it’s the way you shape the work. Ensure you measure the right thing otherwise you might encourage sub-optimization.

That also was Jean Cunningham (another great speaker) keynote’s very subject. Depending on the numbers you’re looking at you can have a completely different understanding of the same situation. In Lean Thinking, it is critical to take into account data that provides you information at system level. Yves Caseau’s book (Processus & Entreprise 2.0 – FR only) has a very usable section on how to select the appropriate KPI.

3. Lean Vs Agile

Is it just me or is there some tensions between the Lean and Agile communities ? M. Ballé have been quite direct and said he wasn’t convinced by these Agile methodologies which raised some voices from Scrum practitioners.

(In all fairness, Mr Ballé sounded in a belligerent mood as he also attacked Enterprise 2.0 when saying : “I see how Enterprise 2.0 streamlines collaboration but I don’t see how it fosters deep thinking.” – something that would spark a hot debate with my friend Jon Husband, I’m sure)

One may feel some complacency in this bold statement.  Lean has a fantastic record in Manufacturing and operation but is still pretty young in Software Development industry where it surely does not have the track record of Agile there. As Tom Poppendieck said, Lean Manufacturing aims for mass production while Lean Software development is completely different.

Mary Poppendieck reckons that Lean is a great approach for IT Operations (a view shared by Mike Orzen in his workshop), but for Development you need Agile methodologies with a Lean Mindset (i.e. with a strong focus on value creation).

Regis Medina also shared a similar approach in his talk as he reckons that Agile centric teams tend to put too much focus on on technology or delivering story point as opposed to really focusing on being lean and delivering value that is free of waste.

It’s interesting to see how the Agile community has adopted Lean Kanban in the portfolio of Agile methodologies while the Lean community see more Lean IT as a Lean ecosystem component. Another example of this rather competitive view can be seen in the conclusion of the insightful paper by PeterMiddleton and David Joyce on BBC Worldwide case study (missed the sold out keynote so used the paper as a fallback plan).

Regardless of the fact that some picky professionals could discuss the relevancy of that case study (a team of 9 people), Kanban is there compared to Agile Methodologies as a much better alternative. An approach to be compared with the much more consensual “Kanban Vs Scrum : How to make the most of both” e-book by über-educationalist Henrik Kniberg.

4. Learning System Thinking

Lean is all about learning how to improve on a continuous basis. Both Steve Bell and Yves Caseau quoted Peter Senge’s The Fifth Discipline, the bible of the learning organization theory. “I learn to analyze (root analysis, deep thinking) my own work in detail to better understand the waste I generate” (Ballé). System Thinking is a key of Lean. People endlessly learn from this System Thinking and from the Plan Do Check Act loop.

Mary Poppendieck makes it clear how critical the ability for an organization to learn is today : “Software design/development is a constant learning process. You learn with small learning cycles (iteration) (…) In any industry nowadays, the fastest learner wins. if your competitor are faster learners then you’re in trouble”

5. Tests

Tests embody one of the principles of the list of 7 : Build Quality-In. As David Joyce wrote in his inspiring analysis of Deming 14 points “Routine inspection is the same as planning for defects” : defects have to be found at the earliest stage of the process.

Doing Test Driven Development you write tests before the code. This ensures you don’t write a/needless code and b/code without tests which is, according to Mary Poppendieck, Legacy code and Technical Debt. Harnessing code with test is the best way to ensure your code can be changed. Again this is critical as code WILL change.

So the best thing is to set up a Testing Culture. Google’s Mark Striebeck made a workshop on the topic. Unlucky him : he was sick on the 13th when his workshop was initially planned and eventually made it on the 14th at 8 Am (the reason why I missed it). So how did Google succeeded ? They didn’t censured themselves and had Testing evangelisation flyers even on their toilet doors ! Presentation online (on Google Doc of course).

6. Complexity

Both Lean and Enterprise 2.0 addresses what Yves Caseau has introduced as the main issue of 21^st century organizations : complexity. Taiichi Ohno belief was that that Just-In-Time was a great way to limit complexity and to streamline organisation activity. He showed how relevant this approach is with the Toyota Production System.

According to both Yves and Steve Bell speaks, 21st century complexity is so overwhelming that collaboration is the only way to address it. M. Bell’s keynote has probably been the most inspiring of the whole summit. Drawing on Ben Zimmerman and Sholom Glouberman study on complicated and complex systems Mr Bell insisted on the relative importance of Behavioural Sciences versus Technology to solve complex problems.

In that respect, he is aligned with M. Caseau’s statement that in interconnected organization, Enterprise Social Networks are a great tool to collaborate and tackle complexity. Which bring us back to Enterprise 2.0 Conference in Boston 2011 Edition where Jamie Pappas reminded us that business today is a subtle science that is more about soft skills than about tech skills.

Another way to remove complexity is not to let it in the first place : challenge every new feature. Adding features grows the code base and, subsequently the complexity and the cost of complexity is exponential (M. Poppendieck). As Mary said, you want your company to grow an immune system against complexity.

7. Problems

Lean has a very straightforward definition of a problem : a problem is a deviation from standard (C. Chabiron). Deming (to whom TPS quite often refers to) says the best way to improve is to focus on variability instead of mean to rate our quality.

Making problems visible makes user happy (C. Chabiron) but as Pierre Pezziardi explained, it may prove to be quite challenging in an environment where mentioning a problem can be perceived as a personal attack. In that case, the biggest challenge as Pierre said was to let people knows that it’s ok to talk about problem, and it’s kind of a mandatory thing to do if you want to fix them afterwards.

Daniel Jones framed it into the very first keynote : “What is the problem we are trying to solve? Not just to improve the efficiency of IT but to harness IT to enable value creation”.

See you next year

A great conference with many enlightening thoughts and ideas exchanged. Surely some exciting times lie ahead on our way to make the IT industry Leaner and more Agile.