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) :

Atelier Vision et Enjeux

L’objectif est de définir la vision et de questionner la stratégie, la raison d’être du projet et les mesures du succès.

Préambule : cet article s’inscrit dans la suite de celui sur le cadrage. Je vais décrire ce qui me parait important dans cet atelier et les « outils » que j’ai déjà utilisés. Par contre, je ne vais pas décrire comment animer cet atelier. Pour cela, je vous laisse le soin de contacter Jean-Claude Grosjean (@jcQualitystreet) et Guillaume Duquesnay (@duquesnay) pour plus de détails sur les techniques de facilitation.

 Faire émerger la vision 

VisionCommençons par la vision, puisque un des buts de cet atelier est justement de faire partager la vision du produit ou du projet que vous souhaitez réaliser. Ah? Produit ou Projet?

Vision Produit vs Vision Projet

Alors, Produit ou Projet? Ma définition est finalement assez simple : un projet est un ensemble d’activités qui permettent d’aboutir à un livrable. Ce livrable peut donc être soit un produit dans sa globalité, soit, plus vraisemblablement, une version (release) de ce produit. Le produit va donc avoir une temporalité plus large que celle du projet. Alors, pourquoi parler de projet? Personnellement, je préférai parler de version du produit. Cependant, dans les grandes entreprises, il est plus commun de parler de projets, d’autant que les budgets sont souvent articulés autour de cette notion. Le soucis que j’observe fréquemment est que ces budgets concernent quasi-exclusivement la première version d’un projet; du coup, cela peut donner lieu à une vision court-termiste, et donner l’impression qu’une fois le projet terminé, le produit sera aussi terminé. Or, c’est rarement le cas… Dans cet atelier, je vous conseille de présenter les deux aspects :

  • la vision du produit : l’ambition que vous vous donnez, là où vous voulez aller, ce que ce produit va (possiblement) apporter. Par exemple, « Nous souhaitons ouvrir une plateforme de contenus culturels en présentant des vidéos de spectacles vivants, en direct et en différé. Cette plateforme sera distribuée sur tous les écrans, web, smartphones, tablettes, TVC, box FAI et box OTT ».
  • la vision du projet : pour faire simple, il suffit de positionner le projet dans la vision du produit. Par exemple, « Dans le cadre de ce projet, nous allons d’abord proposer cette plateforme de contenus culturels sur le web, les tablettes et sur un seul constructeur TVC (pas sur les autres écrans) ».

Vision Produit

Puisque la vision du produit enveloppe la vision du projet, nous allons nous focaliser sur les moyens de faire émerger celle-ci. Tous les contextes sont évidemment différents. Si la vision du produit a déjà été définie par ailleurs, il suffit de la partager et de s’assurer qu’elle est claire pour tous. Par contre, si elle n’a pas encore été définie, il convient de se lancer dans un phase d’ouverture, où vous allez « ouvrir vos chacras » et accepter les idées de tous les participants à l’atelier. Le choix de ces derniers devient donc primordial. Attention: dans ce cas, un seul atelier Vision & Enjeux ne sera probablement pas suffisant et vous devrez le renouveler jusqu’à obtenir une vision du produit claire.

Des jeux pour doper l’imagination 

Il existe de nombreux « outils » pour aider à faire émerger la vision du Produit, qui sont d’ailleurs regroupés sous le vocable anglais de « Innovation games ». La plupart de ceux que j’ai utilisés proviennent de Luke Hohmann et de son livre « Innovation Games: Creating Breakthrough Products Through Collaborative Play » (cf référence à la fin de l’article). Cela peut faire un peu peur de se lancer dans ce type de « jeux », mais je vous encourage à être courageux, à sortir de votre zone de confort et de jouer justement le jeu car les résultats sont toujours au rendez-vous. Quelques exemples intéressants:

  • Product box : permet d’identifier les caractéristiques les plus excitantes d’un produit. Demandez à l’équipe de concevoir un boite qui va représenter votre produit comme s’il devait être vendu et apparaitre sur les rayonnages d’un magasin. Ils vont pouvoir habiller la boite avec des slogans, des coupures de magazines, des prix… Une fois réalisée, demandez à un membre de l’équipe de la présenter, de la vendre.
  • Speed boat : permet d’identifier ce que les utilisateurs n’aiment pas dans votre produit. Vous dessinez un bateau, un bateau que vous souhaitez voir avancer tres rapidement. Malheureusement, celui-ci est retenu par des ancres qui le ralentissent… Evidemment, le bateau représente votre produit et les ancres les fonctionnalités que vos utilisateurs n’aiment pas. Les ancres sont placées plus ou moins bas dans la mer, et au plus c’est bas au plus c’est un frein pour le produit. Ce qui est intéressant c’est la discussion qui s’installe entre les participants à cet exercice pour déterminer le niveau où on va situer l’ancre. Cet exercice est aussi utile pour discuter d’une organisation.
  • Remember the future : là, c’est très simple, il suffit de s’imaginer ce qu’il s’est passé dans le futur si tout c’est bien passé et que le produit a été un succès. Cela permet d’identifier les critères de succès, souvent vus des clients, des utilisateurs finaux.

La vision en une phrase

Pour terminer, essayez de résumer la vision du produit en une phrase. Cela ressemble un peu au concept des 30 secondes pour convaincre le PDG dans l’ascenseur, le fameux « Elevator Pitch ». C’est un exercice assez difficile à réaliser, mais il me semble important car les acteurs du projet vont pouvoir se l’approprier et j’ai souvent observé qu’ils réutilisaient cette phrase quasiment mot pour mot pour expliquer le produit à des collègues.

Le sponsor, pas toujours le génie que l’on croit…

Pour réaliser ce travail sur la vision du produit, il est donc primordial de bénéficier de la présence active du sponsor puisqu’il va pouvoir exprimer ses souhaits, l’ambition du produit, les grandes orientations… A ce stade, je voudrais démystifier un petit peu ce sponsor, que l’on prend parfois pour un génie. Bien sur, on a tous en tête les Steve Jobs, Bill Gates, et autres Zuckerberg ou Dorsey… Mais, car il y a un mais, dans les grandes entreprises, le sponsor est rarement un génie, qui a la vision infuse… Désolé, mais cela arrive rarement. D’ailleurs, une raison valable et validante est que si c’était le cas, il irait surement créer sa propre boite 😉

Donc, dans les grandes entreprises, il est fréquent que le sponsor possède un des profils suivants :

  • le sponsor « idéal » : rare mais cela existe quand même. Il est capable de définir la vision, les enjeux, le périmètre du produit de manière claire et synthétique. Et en plus, il est disponible. Si cela vous arrive, vous pouvez considérer que vous avez gagné au loto! Bon, honnêtement, je n’ai rencontré ce type de sponsor que dans des contextes de startups, la startup du sponsor. CQFD.
  • le sponsor « exécutif » : il sait définir la vision mais il n’a pas le temps… Du coup, tout au long du cadrage (puis du projet), on va se demander « comment IL aurait fait, ce qu’IL a en tête… » Invariablement, ce que l’on aura prévu ne LUI conviendra pas, et il faudra défaire et refaire… Plusieurs fois… Frustrant et démotivant pour les équipes… Mais, avec le temps, on y arrive quand même et c’est déjà très bien.
  • le sponsor « impliqué » : celui qui est finalement le relais du sponsor « exécutif ». Si tout se passe bien, il va tout de même pouvoir prendre des positions et des décisions dans bon nombre de situations. Sa relation avec le sponsor « exécutif » est primordiale. Surtout, il va s’appuyer sur tous les acteurs du projet, ce qui au final peut donner lieu à un vrai travail d’équipe.
  • le sponsor « quicroitquilsaittout » : ca, c’est le cas le plus pénible… Il a les barrettes, le mandat mais n’a pas la vision… Surtout, il n’aura pas de relation de confiance avec le sponsor « exécutif » et il ne va pas s’appuyer sur l’équipe parce qu’il pense détenir LA responsabilité et LE pouvoir de tout décider. L’équipe va passer de l’enthousiasme à la déception très rapidement. Il est fort possible que le projet tombe a l’eau…
  • le sponsor « sans pouvoir » :  on lui a dit qu’il était sponsor mais en vrai, il ne possède pas soit la pertinence soit la confiance requise du top management. Du coup, l’équipe va rapidement se résigner voire se désengager… N’hésitez pas, ne perdez pas de temps, quittez vous aussi le navire!

Evidemment, je caricature un peu, même si ce que je décris est quand même du vécu!

 Identifier les enjeux

Une fois la vision définie et clarifiée, il est intéressant de formaliser les enjeux. Les enjeux peuvent se révéler être de différentes natures (pour n’en citer que quelques uns, les plus classiques):

  • Stratégiques : chiffre d’affaires, reach, performance opérationnelle, ROI, position sur le marché…
  • Usages : accès à l’information, expérience utilisateur, multi-distribution…
  • Contenus : nouveauté du contenu, enrichissement, recommandation, croisement ou agrégation d’informations…
  • Techniques : innovations ou évolutions technologiques…
  • Internes à l’entreprise : amélioration de processus, de la qualité, de la productivité, économies…
  • Internes à l’équipe projet : capitalisation sur une connaissance, une méthodologie, une technologie…

Idéalement, vous serez en mesure de qualifier clairement l’atteinte d’un enjeu, même si ce n’est pas toujours possible ou facile lorsque certains de ces enjeux sont « quali », plutôt que « quanti ». Finalement, le plus simple est de se poser la question « cet enjeu sera atteint si… »  Si possible, je vous encourage à prioriser les enjeux, les uns par rapport aux autres. Si cela s’avère trop difficile de dire que « cet enjeu est plus important que celui-là, parce qu’ils s’ont complémentaires », établissez 3 catégories :

  • Enjeux d’ordre 1 : si on ne les atteint pas, le projet sera un échec. Si on les atteint, on a fait le taf, c’est super.
  • Enjeux d’ordre 2 : si on les atteint, c’est excellent (si les enjeux d’ordre 1 ont aussi été atteints).
  • Enjeux d’ordre 3 : si on les atteint, c’est la cerise sur le gateau, c’est vraiment exceptionnel (si les enjeux d’ordre 1 et 2 ont aussi été atteints).

N’hésitez pas à partager ces enjeux et à les faire challenger pendant toute la phase de cadrage, mais aussi tout au long du projet. Adaptez-les si nécessaire en toute humilité.

Définir le périmètre du projet 

Une fois la vision et les enjeux du produit définis et clarifiés, vous allez pouvoir en tirer et préciser le périmètre global du projet.

L’ouverture, c’est bien, mais restons réalistes!

L’objectif est d’aboutir à une vision partagée à la fois du produit mais surtout du projet que l’on va réaliser. Il faut donc arriver à en définir les frontières et les contraintes peuvent y aider! Les évènements vont vous imposer une date qui ne sera pas négociable en avance (ex: les JO ou les élections). Le budget ou l’espace physique dont vous disposez pourront aussi contraindre la forme de votre projet. Il va donc falloir possiblement sélectionner certaines fonctionnalités, réduire l’ambition… No stress et rappelez-vous d’André Gide: choisir c’est renoncer.

Agile et projet, est-ce compatible?

Depuis quelques années, les méthodes Agiles se sont petit à petit imposées permettant de produire des produits émergents avec des équipes agiles qui ne cessent de mettre en production de nouvelles fonctionnalités, au fil de l’eau… Pourquoi parler de projet dans ce cas? De mon expérience, et bien sur je parle plutôt des contextes d’entreprises ou d’éditeurs de logiciels, plutôt que celui de startups (encore que), il est intéressant de se fixer les limites d’un « projet » afin d’éviter le syndrome de la longue litanies des sprints interminables où l’équipe ne voit plus ce qu’elle a construit. Je caricature. Et d’ailleurs, ce n’est pas parce que l’on travaille en Agile qu’on ne peut pas se fixer des « projets » pour construire un produit. Je le répète, je préfère parler de version alignée sur des fonctionnalités (releases & features) dans le cas d’un produit qui ne va cesser d’évoluer dans le temps. Donc, pour réaliser un produit complexe, je vais définir un projet, composé de plusieurs chantiers. Ces chantiers peuvent être réalisés en agile, de manière itérative.

Il n’est pas nécessaire d’être précis

Je l’ai déjà dit et je le répète : il n’est pas nécessaire de se contraindre à tout définir, bien au contraire. Grâce aux méthodes agiles (mais surtout au bon sens de gens intelligents), il sera possible d’ajuster le périmètre, en fonction de l’apprentissage sur les premiers sprints, et tout au long de la réalisation. A ce stade, il suffit d’identifier les fonctionnalités, « grosses mailles », qui semblent nécessaires au développement du produit. Les méthodes agiles conseillent de commencer par développer les fonctionnalités du produit les plus importantes. Comment identifier ces fonctionnalités et donc le périmètre de ce projet? C’est d’abord la vision du projet et le sponsor qui vont vous le permettre. Puis les contraintes. Il se peut que vous identifiez des fonctionnalités qui ne seront pas utilisées… Depuis quelques années, le Lean startup propose d’aller chercher des preuves de l’intérêt de votre audience pour ce que vous imaginez comme étant un produit intéressant. C’est le fameux MVP, Minimum Viable Product. Le MVP est particulièrement adapté dans le cadre particulier d’une startup, qui possède beaucoup d’agilité et doit aller chercher du reach, de l’audience, des moyens pour survivre. Dans le contexte de grandes entreprises, ce MVP est tout aussi souhaitable pour éviter de réaliser des projets trop longs, des fonctionnalités qui ne servent à rien, des produits qui ne trouvent pas leur public… Cependant, le MVP ne sera pas exactement le même que pour une startup. Par exemple, si je dois réaliser la plateforme pour couvrir les Jeux Olympiques pour France Télévisions, il est inconcevable que je ne conçoive pas un système à la fois complet et robuste. Je sais déjà par avance qu’il y aura un succès d’audience suffisant pour avoir des problèmes 😉 Par contre, toujours dans le cadre de France Télévisions, si nous lançons un projet d’innovation en mode Test & learn, alors, évidemment, on sera dans un projet où on aura un MVP beaucoup plus restreint.  Bref, adaptez le MVP à votre contexte!

Et d’autres jeux pour définir le périmètre

De la même manière qu’il existe des « Innovation games » pour clarifier la vision du produit, il existe des jeux pour aider à prioriser les fonctions, ou tout du moins à définir un périmètre au projet:

  • Buy a feature : le but est de prioriser les fonctionnalités en demandant aux acteurs de les acheter. Une variante qui a ma préférence est de donner des gommettes (3 ou 5) à tout le monde et de demander de les placer sur les fonctionnalités qui ont leurs préférences. Ils ont le droit de poser plusieurs gommettes sur la même fonctionnalité.
  • Prune the product tree: le principe est de définir un arbre dans lequel le tronc correspond au produit, les branches au fonctionnalités actuelles et les feuilles aux nouvelles fonctionnalités. L’objectif est de « tailler » le produit en fonction des besoins. Personnellement, je préfère un exercice de priorisations des fonctionnalités.
  • IN/OUT : une autre manière de déterminer le périmètre du projet est d’exprimer ce qui ni est pas : on peut donc construire la liste des fonctionnalités qui sont inclus dans le projet, et une autre liste des fonctionnalités qui n’y sont pas. Cet exercice est très efficace.

Un mot sur l’impact Mapping

Plusieurs personnes m’ont parlé de l’Impact mapping lors de mon article précédent. J’avoue que je n’ai pas d’expérience suffisante pour pouvoir donner un avis pertinent. Pour ceux que cela intéresse, n’hésitez à regarder le site dédié  et la présentation suivante. L’impact mapping propose de regarder le problème en adressant les questions « Pourquoi? -> Qui? -> Comment? -> Quoi? ». Vous l’avez compris, le principe du cadrage tel que je vous le propose adresse évidemment ces mêmes questions au travers de plusieurs thématiques. Il me semble même que cela va un peu plus loin puisqu’on répond à des questions plus précises d’architecture, de financement, de localisation, de méthode… En fait, personnellement, j’utilise un moyen complémentaire qui s’appelle le CQQCOQP : c’est Dan Roam qui, en plus de proposer de décrire le problème avec des schémas simples (ceux qui me côtoient savent à quel point je raffole de schémas simples sur mon grand tableau blanc), propose aussi cet acronyme CQQCOQP qui correspond aux questions Comment, Quoi/Qui, Combien, Où, Quand et Pourquoi. Utilisez-le pour vous assurer qu’un sujet a été bien couvert.

Quelques références de livres ou ressources qui m’ont influencé sur ce thème :

Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann

Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann

The Back of the Napkin: Solving Problems and Selling Ideas with Pictures by Dan Roam

The Back of the Napkin: Solving Problems and Selling Ideas with Pictures by Dan Roam

Manage It! - Johanna Rothman

Manage It! – Johanna Rothman

De l’importance du cadrage de projet

Cet article est une dédicace à Esther Derby ( qui m’a réellement influencé lors de son intervention à l’USI 2012 où elle y a présenté le concept de «60/30/10».

Je vous encourage à revivre cette présentation grâce à nos amis de @USIEvents qui ont re-publié cette vidéo en un temps record! 

Et n’hésitez pas à visiter le site Youtube de l’USI pour encore plus de vidéos.

Le principe de 60/30/10

Lors de sa présentation, Esther se basait sur une étude menée par J. Richard Hackman (cf lien en fin d’article) dans laquelle il démontre au travers de ses nombreuses recherches que l’efficacité d’une équipe est directement liée à la manière dont elle est construite et lancée :

  • 60% de l’efficacité d’une équipe se décide à la construction de l’équipe (avant son lancement)
  • 30% au lancement
  • 10% dans la suite du projet (après le lancement)

Par extension et projection sur la réalisation de projets informatiques, Esther en déduisait que beaucoup de choses se passent donc avant et pendant le kick off d’un projet, et qu’il faut par conséquent apporter une attention particulière à la manière dont on construit l’équipe.

J’en ai retiré 3 points importants :

  • le cadrage
  • la construction de l’équipe
  • le lancement (ou kick off)

Afin que cet article ne soit pas trop long, je vais surtout parler du cadrage. Je reviendrai dans un autre article sur les 2 autres points.

De l’importance du cadrage

Combien de fois ai-je fait le constat qu’un projet était parti trop vite, sans réel partage d’une vision claire, des enjeux, des échéances clés, de l’attente des sponsors, voire des moyens alloués, de l’architecture globale ou encore de l’organisation? Un nombre bien trop important, j’en ai peur… Fort de ce constat et de la mise en perspective d’Esther, nous avons formalisé, au sein de ma direction, ce qui se passe en amont d’un projet sous la forme d’un cadrage, dont l’objectif principal est de lancer le projet sur de bons rails et de le sécuriser.

Qu’est-ce qu’un cadrage?

« Une préparation réalisée en temps contraint, au cours de laquelle se succèdent un certain nombre d’activités et d’ateliers permettant d’aligner tout le monde autour de thématiques structurantes, qui se termine par un livrable global et synthétique pour validation et démarrage effectif du projet  »

Allez, déconstruisons cette définition!

Réalisé en temps contraint

Il est important de bien cadrer mais il est tout aussi important de réellement démarrer le projet! Un cadrage trop long, avec trop de temps passé à définir et décrire le projet, peut être tout à fait contre-productif. Il faut donc trouver le bon compromis. L’idée ici est de se contraindre par le temps et de se dire que ce n’est probablement pas grave si on n’a pas eu le temps de TOUT cadrer. Cela permet surtout de se concentrer sur l’essentiel.
Alors, combien de temps allez vous me demander pour un bon cadrage? Et bien, cela dépend beaucoup du contexte, de la complexité du projet, de l’âge du capitaine et tout et tout. Bon, de mon expérience, je pense qu’il est possible de cadrer la plupart des projets entre 4 à 6 semaines. Finalement, ce qui contraint le plus un cadrage est souvent la disponibilité des sachants et des sponsors!

Des ateliers pour détailler les thématiques structurantes

Comme le montre le schéma suivant, le cadrage comporte 6 ateliers permettant de dégager les éléments les plus structurants des thématiques suivantes :

Cadrage de projets

De façon à obtenir une meilleure efficacité, je vous recommande de contraindre dans le temps chaque atelier, de vous assurer de la disponibilité des bonnes personnes (notamment le sponsor) et de faire valider les résultats de chaque atelier au plus tôt. Les ateliers peuvent durer 2 à 4 heures. De mon expérience, il est quasiment impossible de mener les ateliers en parallèle puisqu’ils impliquent souvent les mêmes acteurs. Je vous conseille donc de les réaliser dans l’ordre présenté ci-dessus. Par contre, il n’est pas impossible que le résultat de certains ateliers viennent influencer ce qui a été défini dans un atelier précédent. C’est même une évidence et il faudra souvent plusieurs aller-retours avant d’obtenir une version aboutie. C’est normal et logique. Par ailleurs, certaines thématiques peuvent nécessiter plusieurs ateliers, ou même une préparation adaptée. Par exemple, l’architecture d’une nouvelle application peut donner lieu à plusieurs ateliers, voire à la réalisation de preuves de concept (POC) permettant de valider la faisabilité de certaines hypothèses techniques.
Afin de conserver cet article lisible (not tl;tr), je décrirai ces différents ateliers dans un prochain article.

Aligner tout le monde

Le cadrage, au travers des ateliers, va permettre d’aligner un nombre important d’acteurs clés du projet sur un même objectif. Cela concerne souvent 4 populations différentes, qui peuvent être mélangées en fonction de votre organisation :

  • le fonctionnel (aussi appelé Métier ou MOA)
  • le marketing
  • la technique (aussi appelé MOE)
  • l’exploitation (aussi appelé Production ou Opération)

Au-delà de ces acteurs opérationnels, il faut aussi s’assurer que les « décideurs » seront impliqués et informés des orientations choisies. Je peux vous assurer que cette tâche n’est pas la plus simple!

Un livrable global et synthétique

Le livrable est dit « global » puisqu’il va contenir l’ensemble des éléments structurants dans un seul et même document. Malgré cela, le document doit être le plus clair et synthétique possible. Je vous encourage à utiliser beaucoup de schémas qui, selon l’adage bien connu, valent mieux que de longs discours! A partir de cette présentation, vous allez pouvoir réaliser un poster synthétique du projet que vous collerez au mur, et tout autre présentation que vous aurez à faire en l’ajustant en fonction de votre public.


Il est fondamental que le cadrage soit validé par les décideurs de votre organisation. De mon expérience, les points les plus critiques et qui nécessitent une attention particulière, sont :

  • l’organisation : assurez vous que les acteurs positionnés sur les rôles de sponsor, Product Owner, possèdent à la fois la pertinence et les mandats nécessaires.
  • les ressources ou le budget : assurez vous que le budget alloué est légitime et pertinent. Attention aux projets qui souhaitent partir coute que coute, avec un budget ou un planning sous-taillé… Vous en payerez toujours les conséquences. (cf l’article sur la planification réaliste).
  • l’architecture : assurez vous que l’architecture proposée respecte les standards de votre entreprise ou au moins que vous assumez en connaissance de cause que cela ne soit pas le cas.

Démarrage effectif du projet

Du livrable, vous allez pouvoir en tirer une présentation de communication pour le kick off. Ce kick off est donc le prochain moment clé qui va permettre à toute l’équipe de se mettre en mouvement et démarrer le projet. Mais ça, c’est une autre histoire 😉

Pour en terminer sur le cadrage, j’ai toujours en tête une phrase qui m’aide à obtenir le bon état d’esprit:

L’important n’est pas tant le résultat que le chemin que nous parcourons ensemble!

PS: je tiens à remercier Jean-Claude Grosjean (@jcQualitystreet) et Guillaume Duquesnay (@duquesnay) avec qui j’ai la chance de collaborer au quotidien et qui ont largement participé à ce travail de formalisation.

Quelques références de livres ou ressources qui m’ont influencé sur ce thème :

Collaborative Intelligence: Using Teams to Solve Hard Problems - J. Richard Hackman

Collaborative Intelligence: Using Teams to Solve Hard Problems – J. Richard Hackman

Manage It! - Johanna Rothman

Manage It! – Johanna Rothman