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.


Video et slides de la présentation faite à l’USI 2014

J’ai eu le privilège de présenter mon retour d’expérience sur la transformation agile que nous avons réalisé depuis début 2012 chez France Télévisions Editions Numériques.

Voici la video :

Voici les slides :

J’ai ajouté pour l’occasion une section assez importante sur le « pourquoi » d’une transformation. J’ai suivi les conseils de Kotter qui nous conseille de faire un constat du besoin à faire une transformation. Il appelle cela « Créer le sentiment d’urgence« .

Précaution : lorsque je parle du sentiment d’urgence qui était le notre à mon arrivée chez FTVEN, je précise évidement que les équipes précédentes avaient fait du mieux qu’elles avaient pu avec les moyens qu’elles avaient à l’époque. Que personne ne se sente offensé par mes propos, please!

Un fois le sentiment d’urgence énoncé (haut et fort), il est important de proposer des changements de paradigme pour accompagner la transformation. Dans notre contexte, j’ai proposé les changements de paradigme suivants :


Ceci fait, il faut maintenant se retrousser les manches et y aller 😉

Les 7 cartes présentées sont autant de stratégies qui ont permis de répondre aux questions suivantes : Comment introduire l’Agile ? Pourquoi passer du projet au produit ? Comment bien démarrer un projet ? Quelles exigences vis-à-vis de la qualité ? Comment gérer l’urgence et l’importance ? Comment partager l’information efficacement ? Comment protéger l’équipe et garder l’esprit agile ?

Ceci a permis de nous emmener sur la route du succès de cette transformation. Est-ce que j’ai des preuves du succès de cette transformation? Evidemment!

  1. Les résultats -> en constante hausse
  2. Le feedback de mon sponsor -> très satisfait!
  3. Le regard de nos concurrents -> nous sommes maintenant étudiés, observés
  4. L’intérêt des talents -> des leaders de communauté nous ont rejoint

Si vous voulez me contacter pour en savoir plus :

Et enfin, comme il n’y a pas de mal à ce faire plaisir, quelques retours sympathiques sur Twitter suite à la présentation (Thank you Paul, you made my day!):

Mes livres de référence

Il m’arrive souvent que des personnes me demandent qu’elles ont été mes sources d’inspirations, mes influences. Je vais y répondre en partageant la liste des livres qui ont eu un impact sur moi. Il n’y a pas de notation particulière, pas de position préférentielle dans cette liste, si ce n’est que j’ai essayé de la rendre digeste en créant des catégories. Cette liste est relativement longue et pourtant je suis certain qu’il manque quelques pépites, alors n’hésitez pas à me les proposer 😉


Leadership & Management

Change & Culture

Business / Innovation

Product development / Digital

Méthodologies Agile / Lean


Efficacité personnelle

Personal branding



Le point après 6 ans de pratique du OneOnOne : une habitude managériale bien ancrée!

Il y a quelques années, lorsque j’étais chez OCTO, j’ai décidé de tester le OneOnOne. Je cherchais alors à me renforcer avec des pratiques de management et je suis tombé sur le site de ManagerTools (rendons à César…) qui a popularisé, outre-manche, cette pratique. Il se trouve qu’elle était aussi présenté dans Behind Closed Doors de Johanna Rothman et Esther Derby. Après en avoir validé le concept et les bénéfices, j’ai fait un retour d’expérience lors de l’USI 2009. Il se trouve que certaines personnes m’ont contacté récemment pour me demander si je pouvais leur donner des informations parce que la présentation n’est effectivement pas auto-portante, c’est le problème avec les prez zen ;-), et que la video n’était plus en ligne.

Je commence donc par une bonne nouvelle : grâce à l’aide d’OCTO, et de deux personnes (Charlotte et Cool Hervé) que je remercie infiniment, je peux vous proposer ici la video de la présentation:

En revoyant cette présentation, je me dis que j’avais dit l’essentiel, que je peux résumer ainsi :

  • Le OneOnOne est un moment de 30 minutes que je passe avec chacune des personnes que je manage.
  • Il a lieu toutes les semaines à la même heure.
  • Il permet de faire du feed-back, de la délégation et du coaching managérial (avec un process simple et hérité du PDCA).
  • Il me donne l’occasion de prendre fréquemment la température et d’imaginer la suite avec mon collaborateur.

L’O3, une simple pratique? Plus que ça, il est devenu une habitude !

Je me rends compte que 6 ans ont passé (déjà!) et que j’ai conservé cette pratique, qui est donc devenue une habitude de management. Ca, c’est déjà une bonne nouvelle!
Surtout, je m’aperçois qu’au fil du temps mon style a évolué; il y a des choses que je fais plus naturellement et je reste moins attaché à la méthode. C’est probablement mieux ainsi puisque cela rend l’échange plus fluide, moins « mécanique ».

Ne pas parler d’opérationnel? Et bien si, si cela lui fait du bien!

Dans la théorie, le OneOnOne est une demi-heure dédiée à son collaborateur pour échanger sur ce qui est important pour lui. Et pas nécessairement pour faire le point sur des sujets opérationnels. Même si je commence les O3 toujours de la même manière (« Qu’est ce qui est important et que tu veux partager avec moi? » que je raccourcis parfois en « Vas-y, je t’écoute »), je me suis aperçu que certains de mes collaborateurs ont besoin de me voir pour échanger sur ce qu’ils font, me demander mon avis, obtenir des validations, ou tout simplement me mettre au courant. J’essaie d’ailleurs d’attendre que la demande soit formulée clairement avant « d’infliger » mon aide. Il arrive donc que l’O3 ne soit orienté uniquement que sur des points opérationnels. Et cela me convient parfaitement puisque je me dis que c’est ça qui est important à ce moment là pour lui ou elle.

Le feed-back, ça marche? Oui, et surtout le feed-back positif.

Bien évidement que faire du feed-back, c’est important. Qui n’a pas envie d’en recevoir? Pas moi en tout cas. J’en ai besoin, cela me rassure, me motive. Il en est forcément de même de mes collaborateurs. Mon défaut, et je m’en suis aperçu au fil du temps, est d’être trop exigeant, et donc de faire beaucoup de feed-backs d’ajustement et pas assez de feed-back positif. Donnez des 20/20! Je l’avais dit et je ne le faisais pas assez. Merci Léo (il se reconnaitra) pour ce feed-back! Je fais donc attention et j’essaie fréquemment d’exprimer ma satisfaction, lorsqu’elle est bien sûr réelle, ce qui est souvent le cas.

La délégation? Probablement le plus difficile!

Oui, je l’avoue, je me suis pris les pieds dans le tapis… Parfois, j’ai cru déléguer des tâches, et je n’ai pas eu les résultats que j’espérais. Parfois, j’ai cru être clair, et je ne l’étais sûrement pas assez. Parfois, j’ai cru que mon collaborateur avait compris ce qu’il fallait faire, et ce n’était pas le cas. Parfois, je pensais que ce que j’attendais était clair, toujours pas. Bref, s’il y a un point que je retiens maintenant c’est de passer suffisamment de temps à expliquer ce que j’attends et surtout j’explique comment cela « passera le test » : « je considèrerai que la tâche est atteinte si… ». J’essaie donc d’être le plus explicite possible.

Une prise de notes systématique? Pas vraiment…

Sur les conseils de ManagerTools, j’avais conçu une fiche pour prendre mes notes. Elle contenait 3 parties bien distinctes qui respectaient les 3 temps de l’O3. Je m’en suis énormément servi au début. J’avoue, je ne l’utilise plus. En fait, je me suis aperçu que je ne relisais que rarement mes notes. La plupart du temps, je me rappelle sans trop de soucis nos échanges précédents. Surtout, je trouve que la prise de notes trop importantes de ma part à tendance à casser la discussion que nous sommes en train d’avoir. Je préfère avoir une écoute active et être concentré sur notre échange. Ceci dit, prendre des notes synthétiques est très probablement une bonne chose, je ne dis pas le contraire. Il faut dire que nous avons fait une tentative d’utiliser un kanban simple (via Trello) pour y inscrire et observer l’avancée des tâches importantes. Cette initiative est en cours, donc difficile d’en tirer à ce stade des conclusions si ce n’est que je me m’aperçois que certains en ont besoin et continuent à l’utiliser. D’autres préfèrent utiliser leurs propres systèmes. Cela me convient aussi.

Une prise de température hebdomadaire? Non, plutôt mensuelle.

La chose pour laquelle je reste très vigilant est de prendre fréquemment la température : « Comment ça va en ce moment? Est-ce qu’il y a des choses qui t’ennuient? Comment vois tu la suite? Comment puis-je t’aider? »
Cette prise de recul est nécessaire et souvent très bien acceptée, du moment qu’elle n’est pas trop fréquente. Dans la théorie, il est proposé d’en parler toutes les semaines à la fin de l’O3. Honnêtement, je ne crois pas que cela soit bénéfique car il faut avoir de la matière, avoir laisser un certain temps pour pouvoir vraiment avoir quelque chose à se dire. Sinon, vous risquez d’obtenir l’effet inverse et votre collaborateur risque de se sentir oppressé. C’est d’autant plus vrai pour quelqu’un qui serait en situation difficile…
Personnellement, j’essaie d’évaluer le bon moment, mais pour faire simple, je fais ce point mensuellement.

Chaque O3 a lieu toutes les semaines à la même heure? OUI et autant que possible!

De manière générale, je n’ai pas trop de problème. 95% des O3 ont lieu au jour J et à l’heure dite. J’essaie de sécuriser ces créneaux. Or, dans mon organisation, tout le monde n’a pas positionné les points au même moment. D’ailleurs, tous ne font pas nécessairement des O3. Il peut y avoir des réunions « importantes » qui impliquent un nombre important d’employés et pour lesquelles je peux difficilement ne pas y aller. Donc, mon agenda est parfois chamboulé. Ce que j’observe, c’est que si un O3 est déplacé, il a 50% de chances d’être repositionné, de commencer en retard ou pire d’être annulé. De plus, j’ai positionné les O3 le mardi matin et le vendredi matin. Je m’aperçois avec du recul que le vendredi matin n’est pas un moment idéal car il y a souvent des ponts, des congés… Bref, les lundis et mardis matin me semblent finalement être de bons candidats.

L’O3 ne dure que 30 minutes? En fait plutôt 45!

J’ai longtemps maintenu des créneaux de 30 minutes, et malheureusement cela n’est pas suffisant. En planifiant des créneaux de 45 minutes, au pire, cela dure 45 minutes. Si cela dure moins, ce n’est pas grave, cela me donne un peu de temps entre deux O3.

Adoptez les O3!

Vous l’aurez compris, je suis un pro-O3. J’en suis satisfait d’abord parce que cela satisfait mes collaborateurs, sans exception. Aussi, parce que cela constitue les fondations de mon management et me permet d’adopter la posture de serviteur (Servant leadership) que j’ai toujours voulu adopter.


Le dessous des cartes agiles de la transformation numérique de France Télévisions Editions Numeriques

Voici la présentation que j’ai eu le plaisir de partager lors du ScrumDay 2014.

Comment introduire l’Agile ? Pourquoi passer du projet au produit ? Comment bien démarrer un projet ? Quelles exigences vis-à-vis de la qualité ? Comment gérer l’urgence et l’importance ? Comment partager l’information efficacement ? Comment protéger l’équipe et garder l’esprit agile ? Autant de questions que je me suis posées lorsque je suis arrivé dans mon nouveau poste à la direction technique de FTV Éditions Numeriques. Au travers de 7 « cartes Agiles », je reviendrai sur les différentes étapes de cette transformation, ce qui a marché (#success), ou pas (#fail) …

Précaution : cette présentation n’a pas pour vocation à présenter des modèles « théoriques » mais bien mon retour d’expérience d’une transformation agile dans le contexte particulier et singulier du Numériques chez FTV. Le but est de présenter ce qui a été fait chez FTVEN depuis 2 ans. c’est ce que j’appelle la transformation Agile dans un contexte Numériques, avec des équipes produits.

Lien vers le film (slide10) :

Il n’y a pas d’ingrédient secret!

Mais un bon leader peut en créer l’illusion!

« There is no secret ingredient. To make something special, you just have to believe it’s special! », 
Non, cette phrase n’est pas de Eckart Tolle ou du Dalaï Lama mais de Kung Fu Panda, ou pour être plus précis du père de Kung Fu Panda (enfin, c’est pas vraiment son père mais ca, Kung Fu Panda ne le sais pas, chut!!), le cuisinier qui fait une soupe tellement appréciée que tout le monde pense qu’il utilise un ingrédient secret.

Lorsque j’ai revu Kung Fu Panda pendant les fêtes de fin d’année, tout de suite, cette phrase m’a fait penser à ce que j’ai pu observer en accompagnent des équipes sur des projets IT. Et aussi, au rôle particulier qu’un leader pouvait jouer auprès de ces équipes. Bien sur, comparaison n’est pas raison, et la mienne de comparaison n’est peut-être pas fabuleuse mais je m’explique quand même (et après tout, je fais ce que je veux, non?).

En réalité, il arrive fréquemment que les équipes se focalisent sur les freins d’un projet. N’avez vous jamais entendu : « Mon dieu, on ne va jamais y arriver! », « On n’aura jamais le temps! », « On manque de ressource! », «  Le projet est trop gros! », « Le sujet n’est pas clair! » ( choisissez ou ajoutez votre « excuse! » )

Cette peur peut paralyser une équipe entière

Comment l’éviter?
Beaucoup de méthodes proposent de détailler le projet, voire de le détailler encore plus, de découper en tâches plus fines, de planifier, planifier, planifier… Ca peut aider.

Personnellement, j’ai trop observé de temps perdu à vouloir trop détailler en amont, demander à des gens qui ne savent pas (objectivement) décrire des « spécifications détaillées », de planifier pour rien… Je préfère une approche beaucoup plus pragmatique, initialisée par un cadrage minimal (tout du moins time boxé), suivi d’une mise en action immédiate et d’un process d’amélioration continue permettant l’ajustement. Ca donne donc:

On priorise -> On choisit -> On fait -> On livre -> On analyse -> On ajuste -> On recommence

Bref, si vous n’avez toujours pas compris de quoi je parle, c’est bien des méthodes agiles.

Mais, cela n’est parfois pas suffisant. Le process, la méthode sont importants mais si on y injecte l’ingrédient secret, c’est encore mieux. Et cet ingrédient secret, pour une équipe, c’est avoir la certitude qu’elle peut s’appuyer sur un manageur agile, un leader, capable de la soutenir dans les moments importants.

Ce leader doit être capable de
– Ecouter de manière active (vraiment!) les remontées de l’équipe
– Rassurer quand l’équipe se pose des questions
– Protéger l’équipe de tout le bruit et les perturbations qui l’entourent afin qu’elle se focalise sur ce qu’elle a de plus important à faire

En gros, être la courroie de transmission avec le top management, en mettant ce dernier devant ses propres responsabilités lorsque cela est nécessaire («  vous demandez le beurre et l’argent du beurre! Choisissez ce qui est le plus important pour vous! »).

Aux yeux de l’équipe, ce leader devient l’ingrédient secret

Fort de ce soutien, et une fois la mise en marche enclenchée, l’équipe va prendre confiance en elle et éviter de perdre du temps sur des sujets sur lesquels elle n’a pas de prise.