Review of the Lean IT Summit 2014 – Paris

I attended the Lean IT Summit in Paris on the 16th and 17th of October 2014. This is my take on this conference, but, of course, I cannot profess to cover the whole conference as some sessions were programed at the same time. For example, I missed Spotify’s presentation on Leadership, by Kristian Lindwall, which, I have heard, was really good. I will then focus on the keynotes and on the various aspects that retained my attention.


This conference was indeed very interesting and confirmed my opinion that Lean is by essence a continuum, a mindset, a culture of leadership. I felt inspired and, at the same time, pretty small in front of the mountain that is in front of me… But, like Creighton Abrams mentioned, « When eating an elephant take one bite at a time. » 

So, in the coming months, my next bites will be:

  • Influence to start a strategic project using Lean UX & Lean Startup -> DONE!
  • Convince my (future) company to create an Obeya at the enterprise level
  • Apply the Impact-driven development process
  • Animate some improvement Kata
  • Take more (a lot of) time to align people
  • Visit companies that are successfully lean
  • Measure, measure, measure

But, having in mind that…

Taiichi Ohno

Amazing speakers!

First of all, congratulations to the organization team, as the presentations were of high quality, the logistics were excellent and, of course, the food was awesome. Moreover, the quality of the speakers was just amazing! Think about it : Mary Poppendieck, Daniel Jones, Jeff Sutherland, Jeff Gothelf! My only regret is that Michael Ballé or Steve Bell did not speak during this edition. Way too bad.

The presentations were all in english, and so is this post, apologies to my french followers. English language because more than half of the participants were foreigners, mostly from northern european countries. Not surprising as 1/ they are more proactive in deploying avant-gardist methodologies and 2/ Lean has such a bad reputation in France… Of course, it is too bad as everybody could benefit from this methodology, I mean, from this shift of leadership mindset.

Anyway, let’s start!

« What’s the point of hiring smart people if you don’t empower them to fix what’s broken? »

What better way to start a conference by quoting Ed Catmull, Pixar Cofounder, in his wonderful book Creativity Inc. ? Probably, the best management book I have ever read; talent, respect, autonomy, art of feedback, clarity of goals, customer focus, intense collaboration, short experiments, continuous improvements, learning from failures… Well, in short, lean principles and common sense in action! But, let’s keep that for an other post.

Deference to expertise

In his talk « What can Lean contribute to the Digital Age: Beyond Lean Startups », Dan Jones, one of the leaders of the Lean community and co-author of Lean Thinking, presents six shifts that are necessary to change the culture of our organizations: from lean to learn, from projects to streams, from craftsmen to sensei, from experts to users, from control to value and from systems to networks.
In this context, the managers are at the center of the epicenter. They need to become humble and stop behaving as if they have all the answers or if they have to command and control everything… Let the experts, the workers, execute because, most of the time, they know exactly what to do. The managers need to focus on creating a culture of learning, mentoring, engagement, feedback, problem solving, continuous improvement, challenge & respect, customer focus and of course humility. Well said!

From Craftsmen to Sensei

Toyota in action… in IT

Pierre Masai, VP Information Systems Toyota Motor Europe, presented « The quest of one piece flow in IT ». Toyota implements one piece flow through four main steps :
1 – Unbreakening the chain of value towards the customers
2 – Measuring and proving that each investment is worth it
3 – Avoiding any unnecessary batching of activities
4 – Delivering functions in small and even pieces
This adresses not only the software development cycle, but more likely the entire business process improvement cycle. Toyota is enabling this approach by using tools & methods (continuous delivery tools, virtual Obeya, Agile/SCRUM, DevOps, cloud operations, systems as code…) and by connecting Build and Run cycles.

connecting Build and Run cycles

What seems to me very impressive is the fact that Toyota not only masters a discipline of measurements, but is also able to link projects and investments to the Enterprise strategy. In my humble experience, this is really difficult to do at such a level of complexity.

Back to Toyota house

Pierre also explained the process used by Toyota to carefully understand and study a problem when it occurs; and then, to find the actions avoiding the same problem to appear again. I particularly like the motivational guidelines that set the tone!

Problem solving

Although they are lucid enough to know that it is virtually impossible to attain zero problems, they are still trying to reach this target by addressing the problem solving activities at three levels.

Problem solving levelsIn my opinion, the unfortunate part of the presentation is that it was laking of real examples to see how it works in real life… Pierre, could I come visit you to see that? I am really interested! For real.

Lean is more a journey than a finish line

Fred Mathijssen, European Technology Senior Director of Nike, presented « From visual management to strategic engagement, the evolvement of an Obeya ». He started by explaining how Nike launched its Lean journey with a little anecdote:
« To start aligning everybody on the same culture, we gave the book (Lean IT by Steve Bell) to each person with a basket of food, and we asked them to go home and read the book! »  
So, what is an Obeya? An Obeya is a big room, a war room, a project room, where each wall presents information radiators: Strategic, Improvement & goals metrics, Vision, Run the business.

Nike's Obeya It is used for many meetings, from steering committees to operational meetings.
Fred provided some keys to start creating an Obeya:

  • Access to coaching to start and fuel the Lean dynamic
  • Standards have to be flexible
  • Focus on the culture, people, leverage tools, leadership, PDCA, share success

He stressed that creating an Obeya is not as simple as it seems. It takes time and energy… But the results are worth it! Since the creation of the Obeya, Nike was able to reduce the telco costs by 60%. Moreover, before the Obeya, IT was not considered as a real business partner; the Obeya helped to build the bridges within the organization and to create more value.

Of course, I have seen before some Obeyas dedicated to projects, but I have never seen one at the entreprise level like this one. It was, for me, an eye opener. It makes so much sense! I just hope to be able to influence my company to do that.

JIDOKA = Situational awareness

Mary Poppendieck, the female pope of Lean IT, presented « The aware organization – Jidoka », with a ton of energy! (Mary, where does that come from??)
As we know, more and more teams are using continuous delivery approach and Agile to deliver more and more often. But, what does it mean for large companies where the systems are becoming larger and more complex.

« The more code, the worst! The more features, the worst! Don’t measure using these indicators… » 

Mary argued that Jidoka could be helpful! Well, but what is Jidoka? She proposed the following definition: Jidoka is the situational awareness or the mindfulness of an organization to understand the goal so the flow goes smoothly from products to customers.

She discussed the qualities that these organizations must then developed:

  • Preoccupation with failure: removing bottlenecks, continuously delivering code in production, challenging value of features.
  • Reluctance to simplify: delivering value as a shared responsibility.
  • Sensitivity to operations: next generation software development process includes continuous delivery, no branches, cross functional teams, automated tests, tight collaboration.
  • Commitment to resilience: developing a culture of learning.
  • Deference to expertise: respecting the experts that are on the field. She referred to Tom Gilb’s work (see slide below).

Tom Gilb's work

« If you need a report, go see for yourself the visual boards of the team, for God’s sake! Don’t waste time! »  M. Poppendieck 

Mary concluded by presenting the Impact-driven development, based on Simon Sinek’s Why, Tom Gilb’s work and Eric Ries’ Lean startup approach:

Impact-driven development

Clear and concise enough to be printed and hung on the walls of each managers.

The roots of Scrum

Jeff Sutherland, creator of Scrum and author of his new book Scrum: The Art of Doing Twice the Work in Half the Time, shared his story and explained how he, slowly, piece by piece, built what is Scrum today and its underlying principles. Very interesting to see the puzzle being assembled in front of your eyes!

Scrum: The art of doing twice the work in half the time by Jeff Sutherland - Lean IT Summit 2014

He explained that he started working for a bank where the traditional method was not working…

Death march at the bank

« It is because the projects are going wrong that the managers are starting to treat people as slaves… » 

He also shared some valuable lessons, by quoting Eisenhower: « Plans are worthless, planning is everything! » 
And, by the way, Jeff recognized that the right size for a team is 5! Not 9… I was sure about it!
But, my favorite anecdote concerned the creation of the Agile Manifesto. Jeff remembered that after several days of discussions, debates and disagreements, Martin Fowler said something like «Hey guys, we need to agree on something before we leave! » They went on a board and started to write what they agreed the most on: « Individuals and interactions over processes and tools ». Great. They continued. And it took only 15 minutes to write the rest of the Manifesto! Funny how sometimes, you just need to start with a small action to make it happen!

Don’t say « we know », say « we believe » and then try, test & validate!

Jeff Gothelf, author of Lean UX, presented his methodology, Lean UX, which is very connected to Lean Startup, in a very inspiring talk. Jeff started to explain that people develop too many features! Example of the remote control:

Remote control

On top of that, software is continuous, so why don’t we adjust our processes?

software is continuous

Jeff asked key questions :

  • How long do we wait before launch?
  • How do we define the right requirements for our products?
  • What signals are we looking for from the market?

These questions are at the center of Lean UX.

Lean UX

Let’s start by challenging the features, meaning the requirements. Requirements, are in fact, assumptions. So, let’s stop saying « we know », let’s start saying « we believe ». And then, let’s try, test first and then validate our assumptions. We need then to prioritize learning over growth by declaring our assumptions, all of them, and turn them into hypothesis. Jeff gave an example of such:

360 Assumptions 15.2

Jeff proposes that we turn assumptions into hypotheses following this pattern:
We believe that [building these features] [for these people] 
     will achieve [this outcome]. 
We will know we are successful 
     when we see [this signal from the market]    

By doing so, the focus of a team changes from the output (the features) to the outcome (a measurable change in customer behavior attributable to specific output). The whole team will then feel responsible for delivering features that are useful and used, or, even better, awesome products! Of course, this a huge shift that needs to be done within our companies, where each department is focused on its own deliveries/outputs…
And of course, he urges us to make decisions based on objective observations (mainly measurements) and not just gut feeling and internal key indicators…

Jeff presented several cases, which were very valuable to understand his approach.

He tried to reassure us by saying that measuring, talking to customers and pausing/reflecting/learning are the easy parts. The hard part is to take the decision to pivot!

Hard part : pivot

Well, in my humble experience, this is equally as difficult, because the easy parts mean changing the culture of an organization,   (unless it is built-in, like for a start-up, of course): going out of the building, removing the boundaries, being focussed on the customer satisfaction, measuring the right thing, taking time to pause/think/learn (right!!!). No really, not so easy, unfortunately… But that gives work to consultants 😉

In conclusion, Jeff gave us sound advice: « Do not outsource research and learning. The report will be bias and the team will loose contact with their customer. »

Use cloud computing to speed up your ideas

Carlos Condé, Chief Technology Evangelist at Amazon Web Services EME, explained how cloud computing (and AWS services of course) can enable Lean IT teams.
1 – Experiment & innovate. To increase innovation, it is necessary to lower the cost of failure. Fail fast, Fail low-cost! And with cloud computing (and AWS), the cost of an environment is really not an issue anymore (few €/per month)
2 – Measure everything. Again, services like AWS come with integrated tools providing necessary measures.
3 – Embrace failure. Success makes people feel good, but failure makes people better.

Success make people feel good

Amazon has game days to simulate failure. Great idea!  They also uses Chaos Monkey, a software tool developed by Netflix engineers to test the resiliency and recoverability of their Amazon Web Services (AWS), and ensure that individual components work independently, by randomly killing instances and services within AWS infrastructure. This is a very good way to validate your architecture and be sure that your procedures are well-known!

4 – Iterate and move fast. Well, here fits all the well-known best practices of Agile software development.
But, of course, the most impressive is the part on continuous deployment. Carlos explained that we should be able to push an update in production whenever we need it, because we want to push to our customer as fast and often as possible, to learn quickly.
As an example of excellence, Carlos shared the deployments stats at amazon:

Deployments at Amazon

So, Amazon changes a (small) piece of code in production every 11.2 seconds! Impressive, but I suspect that they have quite a lot of developers 😉

5 – Focus on your business. Finally, Carlos explained that, with cloud computing (and AWS), the developers focus more time on developing the business than managing the heavy stuff (infrastructure).

Oh my God, I get it!!

I participated in a Kata workshop with Catherine Chabiron on « How to develop improvement routines ».
This workshop is based on Mike Rother’s work, detailed in his book Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results.
The goal was to recreate the context of a traditional IT project (meaning, not a Lean one). Things were designed so that it was a bit chaotic, lots of noise, perturbations, no clear vision, no clear instructions… The results of the first iterations were catastrophic. Then, by applying Lean principles, making one improvement at a time, doing PDCA, measuring, involving each person of the team, going and seeing (Gemba), managing visually, we dramatically improved the results.

Kata workshop with Catherine ChabironWell, not surprising, you will argue. Yep, right. But, what surprised me the most was my own feelings. Let me explain. During the first iterations, where everything was still chaotic, I surprised myself being focused only on my own tasks or the tasks of my team. I had no clue what was the ultimate goal and I did not even want to see what was going wrong in the global process. I was just satisfied that our team was doing a good job. Frightening! This is when it hit me! « God, this is exactly what is happening when a project is split in so many teams! Each of them has a myopic vision of the project and nobody cares of the overall goal! » Food for thought: avoid having so many boundaries and take A LOT OF time to align people.

Here is the process we followed :

Coaching Kata (1)Coaching Kata (2)

Lots of shared experiences

They were also some very interesting returns on experience during these two days.

In a very inspiring story, presented with humor and humility, Benoit Charles-Lavauzelle explained « How I tripled the turnover of my web and mobile development start-up with Lean management ». Theodo, his growing software company, uses Lean, Agile, visual management and common sense to solve problems and improve the processes.  Theodo started by following traditional methodology to realize projects for its clients. They realized that it was not working as expected: the clients were not so happy by the results, and Theodo, either. They proposed a different approach using Agile. The potential clients did not necessarily agree on that, thinking they were taking all the risks. Theodo decided to take the risk to be honest rather than being depressed. And it worked as the revenues were multiplied by four, in two years! The next bottleneck was the recruitment process. Benoit realized that the recruits turned down the offers more easily if presented by phone. He decided to offer the job in person. Bingo! That improved the recruitment process from 50% to 90%. Benoit leaves us with an advice: ask your own employees « What is your job? », and you will start your Lean journey!

Jannes Smit & David Bogaerts explained how they transformed ING Bank NL. Really impressive achievements, but these guys are so humble that they will tell you that they are just at the beginning of the journey. Probably the right attitude towards long term changes and excellence.
« IT is the Bank. Let’s start internalizing dev again and have a real engineering culture. » « The team was good and we were still having problems. So we realised the problem was us, the management team! » 

Ismael Hery, Head of software development at, explained how to get fast by maximizing learning on all aspects of new software product development projects. « Start by knowing what you know and what you don’t known. » « When facing a choice in product development, choose the path of maximized learning. »

Sari Torkkola, CIO of Patria, explained how she became a Lean CIO.  « Lean helped to reduce sick leaves and burnouts, and improved globally the efficiency. » French HR should be attentive to this kind of feedback!

The organization team hung on the wall of the cafeteria two questionnaires, asking participants for their input. The first one was to identify the expected benefits for using Lean:

What benefits do you expect from Lean?

Lean is not seen as a methodology to start or create a business but more to improve a process, the quality and to change the culture of an organization. I guess, this is where Lean Startup is trying to fill the gap.
And then, another questionnaire to identify what are the obstacles to deploying lean:

what are the obstacles to deploying lean?

Well, I guess, this one is quite clear; we know who is guilty! 😉

PS: thank you to Thomas Lissajoux and my wife for reviewing this post.