DATFlock2015, unicorns, distributed teams and bad agile

I was in Berlin for 2 days to participate to #DATFlock2015 the conference to discuss, learn and share about Distributed Agile Teams.

The program was a mix of open space sessions and workshops prepared in advance.

OKR, Feedback and Reward

Two sessions where particularly useful to me:

  • How to use OKR?
  • Fearless feedback and fair reward

Two sessions proposed by Petra Liesmons and Kitty Iding, thank you! Those subjects and the way they were covered are confirming the work I am currently on, to implement those ideas with the teams I work with.

Take away and personal thoughts from the OKR session:

  • Improvement on the way to explain OKR, especially the difference between key results and actions. An important aspect, because people tend to be confused and propose actions as key results, for not so good reasons. For example: because we are doing that today, it’s an important things to do but it’s not connected to another key results… The last point would be a good signal to stop doing that, or to reconsider the OKR already defined.
  • Other important point that is subject to discussions is that OKRs are not cascading from the company level to the team level. There’s objectives and key results at the company level. They will be used to guide the decisions of teams which will define their objectives and key results. One team is able to contribute to a part or all the objectives and key results of the company.
  • Key Results should be a stretch. They will show our ambitions. They should be difficult but not impossible. So it means we need to change the habit to reach 100%. An habit that tends to lower the objective, so we are sure to overcome it…
  • And obviously this bad behavior is increased if kpis are connected to reward. So OKR should not be connected to rewards.
  • Key Results represent success, impact, the behavior we want to drive in the company.
  • OKR is not a top down approach, we need everybody involved in the definition, the scoring, on a regular basis. For example, on a yearly basis for the company OKRs, on a quarterly basis to reconsider OKR for a team, on a weekly basis to score the current Key Results for each team.
  • OKR are public in the company, and time should be taken to align the OKR between teams
  • We probably need sanity indicators like happiness index of team members to check the side effects

2015-11-20 12.49.57Take away and personal thoughts from the feedback and reward session:

  • To receive clear feedback from the team, it is necessary to clarify expectations, so to define the roles: manager, product manager, product owner, scrum master, developer, tester, etc… depending of the organization of the company
  • One model to define roles and responsibilities could be to use the model from Matti Klasson. There was a discussion around the idea to use dos and don’ts and we agreed at the end that it was better to reformulate with dos than to have a long list of don’ts
  • The World Cafe format to define the different roles seems to be the more efficient one. I need to find a way to do that in a distributed mode
  • Introducing personality types (with tools like mbti, ensize, insights…) can be a way to help people understand the different personality types and in this way give feedback in the best way so they can be received
  • One suggestion to help people handle the feedback they receive is to give them personal coach. The personal coach are volunteer from the teams that will coach 4 to 5 individual. Those people will form a virtual team and will be themselves coached and trained.
  • The reward part of the discussion introduce the idea of peer to peer face to face scoring on each person compared to the roles they handle. The personal coach will help the person to review the scores. The person is responsible to define the scores she think good for her. The manager has access to all the scores and people will be ranked for each role. Then there’s a comparison of their score ranking and their compensation ranking, and an adaptation if necessary.

Organization and Architecture

communication-overheadI also appreciate the keynote by Johannes Mainusch On day 2. Particularly the part showing the connection between the size of a team, the number of relationship to maintain between the people and by consequence the decrease of work done when you add too much people on a team.

The conclusion of the speaker was that they needed team not to small to be able to pair program and to be able to form new teams by spliting the teams (like cells).

The idea to have architects that will be part of each teams and that work together to male the architecture changeable, to insure that the cross functional teams can be independent.

ElmoAnd of course I will definitely use the ELMO facilitation technique, that can also work for a distributed team in a video conference call. Each team member has a paper, it could be with Elmo, and when a conversation is taking too much time, they can rise the Elmo, that stands in this case Enough Lets Move On (ELMO).

A fishbowl was organized during the second day, and to open it Lisette Sutherland explained why she invited Yegor Bugayenko, founder and CTO of Yegor is working with distributed people all over the world and states that team building activities are useless. A sign of bad system and bad management that tries to bribe the people and replace discipline with friendship.

It was definitely interesting to have a respectful opposite point of view in the conference. Yegor explains in this blog post the experiment he tried during his workshop session.

The main ideas: the customer wants the software and is not interested in a team, and a team is less efficient than well orchestrated individuals. I have one main disagreement there… But we will come back to it later.

How Yegor’s system works?

Projects are splitted in thousands of tasks of 30 minute each. The task will be proposed to developers that will take or leave. The system is a pay per task, and you get paid only if you succeed to deliver the task with the expected quality level. They need to keep in my that it’s an half hour task, so if they are not able to understand the class they will need to use in a glimpse, it means it’s a bad class that needs to be refactored, so they need to create a new task to get what they need to work on the initial task and put it on hold. They will be paid also to create task. Another person, in the architect role, also paid per task, will validate if the new task is needed.

The risk are solved by numbers. They choose to put 25 developers on a project that needs 3. If one fails to deliver the half hour task (small risk), the task will be reassigned to another one.

Distributed people, not distributed teams

It’s a system that may not work for everybody. Yegor claimed that a lot of people want to work with them, so they have the opportunity to choose. They give tasks to new comers on open source projects to see how they behave, if it’s ok, they will enter the pool and will be given customer projects tasks. If I remember well the metrics is only 1 out of 20 that will be able to continue.


One person during the fishbowl sat on the empty chair and said that the Unicorns (startup with more than 1 billion dollar valuation) demonstrate the validity of cross functional teams, people working together and so on… The humble response of Yegor was that one or even one hundred examples like this are not enough to demonstrate the causality of those successes… How many teams are doing the same things without achieving amazing results? And that’s a good point, we tend to interpret the situations according to our own beliefs…

Disagreement, Creativity and Innovation

The main disagreement I have is around creativity and innovation. Cross functional teams will enable to have different kind of people working together with the same purpose. And from the frictions produced during this collaborative work great new ideas will come up. Agile practices are crafted to organize those conversations and to generate those opportunities.

Bad Agile

The problem is when we look at bad agile implementations. Teams that claim they are “doing” agile but:

  • No collaboration in the team (Assignment of one story per person for example)
  • No discussion with the product owner
  • Stories that are todos without purpose
  • No reviews with the customer
  • No collective splitting stories into task
  • No pair programming
  • Review by one architect
  • Tests by QA outside of the team

If we combine those bad practices with bad management that is not knowing what should be done, changing priorities everyday, fixing unrealistic goals and so on…

We come up with question around how to implement efficient software development systems and warnings around applying only a part of a system without understanding the consequences of those choices.


Thanks to Lisette, Lucius and all the contributors to this great event.

Général livre

Manage it!

Manage it! is a book by Johanna Rothman published by Pragmatic Programmers. You probably know already Pragmatic Programmers, they published Agile Retrospectives by Esther Derby and Diana Larsen, and also Agile Coaching by Rachel Davies and Liz Sedley that my friend Fabrice Aimetti translated into French. If don’t know Pragmatic Programmers yet, I recommend a visit to their book shelf.

When I started the book, I have been surprised, badly, by the classic project management tone, and at the end, it is something I really appreciate in this book. Why ? Because it means that you can recommend this book to project managers and managers that are used to classic methodologies and classic work environments. And they will not think that you are trying to enrolled them into a sect.

Well, this book will not cover principles and values that make the culture of an organization, principles and values that can be reinforced or hustled during an agile adoption.

This book covers project management, as seen by project managers, program managers or managers, sometime as seen by team members. It covers the start of a project, the planning, life cycles, scheduling and scheduling games, estimation, creation of teams, steering, rhythm, meetings, dashboards, multisite projects, multiple projects, test integration, programs and portfolios, and of course project completion. With this short view of all the chapters, you can see what you can expect from this book. Recommendations are simple to understand, and argumentation could be useful to enrich your existing range.

I really like the way powerful questions were introduced, like :

  • What does success look like ?
  • Why are these results desirable ?
  • What is the solution worth to you ?
  • What problems does this system solve ?
  • What problems could this system create ?

I appreciate also the recommendation to introduce retrospectives in the project life cycles (and the way to insit not to call this a postmortem at the end, cause we hope that nobody will die during the project).

This book can be read fast (I read it in the plane on my way back from Red Hat Tech Exchange) and I believe that it can be a useful reference when you are ready to start a new project and to work on an existing one.


Liberté et Cie par le club de lecture

Une nouvelle session de notre nouveau club de lecture à Bordeaux se déroulait ce samedi 20 juin 2015. Cette fois ci, un peu moins de participants que prévu (était-ce du à un ciel trop bleu ?) Claire, Isabel, Fabrice et Patrick se joignait à moi pour échanger autour du livre Liberté & Cie. Le contraste avec le livre discuté lors de la précédente session est relevé d’entrée par les participants, le format est plus universitaire, peu d’illustrations, photos, schéma…

Ci-dessous, la prise de notes au cours de la session :

2015-06-22 09.30.34Les nombreuses entreprises étudiées provenant de nombreux secteurs d’activité est un aspect important pour cette mine d’or (parfois oubliée…). Le livre donne envie d’être partagé, mais il n’est pas si simple d’en provoquer la lecture et les échanges initiaux ne suffisent pas nécessairement à aller au delà de l’impulsion.

Les points qui ressortent sont la nécessité qu’un leader déclenche la transformation, ou créé une organisation avec des principes d’organisation différents. Une organisation qui ne créée pas des règles pour les 3%, une organisation du pourquoi et pas une organisation du comment…

Oui, je sais, il est probable que pour comprendre cela, il faille lire le livre… ce que je vous encourage à faire.

Je termine donc avec une citation d’Isabel :

On ne change pas les gens, mais on peut changer les conditions qui feront qu’ils changeront

Et par l’enregistrement graphique de Claire, effectué lors de sa lecture du livre: 2015-06-20 11.07.45


Agile France et Le Bonheur au Travail

J’ai eu le plaisir de donner une conférence sur le bonheur lors de l’édition 2015 de la conférence Agile France à Paris. Il s’agissait d’une version raccourcie et en français de la keynote que j’avais donné en ouverture lors des Drupal Developers Days : Happiness is Coming.

J’avais choisi de couper beaucoup de contenu pour pouvoir tenir dans les 25 minutes, et il aurait fallu en couper encore…

Un grand merci pour les feedbacks et les sourires !

Agile France – Le Bonheur au Travail from Alexis Monville

Don’t change my mindset, I am not that open

Nick Barcet and I were schedule for the last talk session of the Openstack Summit in Vancouver (Of course, design sessions will continue on Friday).
When we submitted the proposal for this session we were looking for a way to help our co-contributors to the openstack project.
The way we think it can be the more helpful was to share our way of working together to foster change in the organizations of the customers we work with.

The recording of our session has already been published by the Openstack Foundation, and is available here:

Our slides are available there:

Your feedbacks are welcome to continue the conversation!


Bridges and Hierarchy

Mark McLoughlin delivered the Red Hat Keynote, on the morning of the second day of the Openstack Summit in Vancouver.

During the afternoon, he delivered a more intimate talk about the governance of the Openstack project.
The main idea is that, the new Big Tent organization model will allow the emergence of new projects, and it can be the time to redefine the main values that will help the project contributors to take the good decisions.

Mark started his talk refering to the Keynote Eben Moglen gave in Auckland at LCA 2015. In this keynote, Eben Moglen explained that the hierarchical organization model that we all know very well, is the model of the 20th century, and that the organization of the 21st century will be based on transparency, participation and non-hierarchical collaboration, like it is in free software.

Mark continued his introduction with a reference to Andy Hunt’s blog post, The Failure of Agile. Andy Hunt is one of the original writer of the agile manifesto, so when it came to discuss agile, we can at least consider him seriously. The main point of this article is that a lot of people lot’s the agile way by focusing on a set of practices, forgeting the agile values and principles. They are focused on doing agile, and they forgot that depending on your experience, if your are a beginer in a practice, you need clear directives to learn how things work, and more and more your skills are developing you will need coaching on the go, and then you will need some support, and then you will be fully autonomous and during this journey you will have adapted the initial set of practices living the agile values and principles.

That reminds me the stickers I had printed for an agile conference:
When I recieved the stikers at this point, I was thinking… humm I should have crossed also “be” and put “learn” instead… because this is really what we are doing here…

So Mark proposed those 4 high level ideas that can become the high level principles we can refer to as an Openstack contributor :

diverse interests, but a shared vision, based on consensus
individuals and interactions over processes and tools
leadership through empowerment, empathy and trust
every advance must ultimately iterate from the bottom up

And I encourage you to watch the talk to understand the details of his proposal.


Happiness is Coming

I had the great pleasure to deliver the opening keynote of April 17, 2015 of the Drupal Developer Days in Montpellier. The selected theme was Happiness…

Here are the slides:

And a selection of tweets:

Thank you for your great feedbacks and for the great conversations that followed!

I feel ready for the next DrupalCon 😉


The DevOps Opportunity

Capture d’écran 2015-02-11 à 11.01.27In the beginning was the session of John Allspaw and Paul Hammond during the 2009 Velocity Conference, showing how cooperation between Dev and Ops at Flickr allows 10 deployments a day (Header image of this post is extract from this presentation, and it shows how Leonard Nimoy was important for us even if I started this post on February 6th and forget about it after…).
Following that, there was the first DevOpsDays conference in Gent at the end of 2009.
Behind the promise of reconciliation between evolution and stability objectives, reconciliation between devs and ops, some saw technological solutions enabling to shorten the lead time of go lives, and even to go live without human intervention.
Others saw the opportunity to realize the promise of the last 20 years of the agile movement (yes I start to count at the beginning of the discussions about the lightweight project management method and the emergence of XP… already 20 years…).

Capture d’écran 2015-02-11 à 10.58.37

Others questioned the skills that sys admin will need to acquire to be able to consider infrastructure as code.
Others imagined that the devs will need to change and acquire a good understanding of the behavior of their code in production, that they must integrate exploitation constraints into their code, like the ability for their apps to react to failure, to scale in or scale out, the ability to update or upgrade without services interruption…
Others thought that the change should be from the entire system, that we need to reconsider the way we envision software evolution, and information system evolution, looking at it feature by feature – using not only the idea of Minimal Viable Product (MVP) at the beginning of a project but the idea of Minimal Marketable Feature (MMF) during all the lifecycle of our information systems.
Others thought that cloud technologies was an enabler to our way to envision information systems, and obviously others are working on those technologies to enable those transformations.
Others argued that if they want to recruit new people in their team they need to transform their organization because new generations will not accept the constraints of silos that prevent collaboration.
All those point of views demonstrate the complexity of the devops subject and the impact on different domains in the organization: tools, method, organisation and culture.
It was really interesting to observe the diversity of all those views during the Devops CIO’s breakfast organized by Red Hat in Paris on February 6th, my role was to shed some light on the subject and to facilitate the discussion between participants.
Now that eNovance is part of Red Hat, the challenge to transform organization’s culture (internally and externally) continue with the Red Hat Cloud Innovation Practice and the size effect and open source culture allows exiting discussions with my peers.
Red Hat Cloud Innovation Practice
Club de Lecture Général

Club de Lecture

Une session du Club de Lecture de Bordeaux s’est déroulée ce samedi 28 mars 2015, de 10h30 à 12h00. L’idée de proposer cette session m’était venu suite à la participation au club de Toulouse que j’ai raconté ici.

Isabel, Claire, Guillaume, Olivier, Patrick, Philippe se sont joints pour raconter leurs impressions, opinions, expériences en rapport avec #Workout, le dernier livre de Jurgen Appelo.


J’ai trouvé cette heure et demie très courte. Les échanges étaient très riches. Le format, la qualité d’impression, le choix des illustrations contribuant autant à la forme qu’à la réflexion sur le fond, sont des points communs remarqués par l’ensemble des participants.

Les notes de lecture de Claire
Les notes de lecture de Claire

Ils ont également notés que ce livre sur le management est accessible à tous… et même à mettre dans toutes les mains pour transmettre le désir d’essayer d’envisager les choses autrement.

Les idées proposées dans le livre sont étayées (ce qui permet de les transmettre plus facilement), illustrées d’exemples, associés à des références qui font dire aux participants qu’il y a tout (ou presque tout) dans ce livre (agile, coaching, management, communication…).

La possibilité d’adopter une lecture linéaire, en fonction du sujet recherché ou même en laissant faire le hasard fait de ce livre une référence à long terme.

Les participants avaient tous expérimentés au moins une des pratiques proposées dans la livre : guild, identity symbols, motivators, delegation poker ou board, powerful questions, feedback wrap, personal maps, happiness index, feedback door… Certaines pratiques restent “à essayer” : formule pour le salaire par exemple.

La suite du Club de lecture ?

Pour choisir la date :

Un board Trello pour proposer et choisir les livres:

Le principe est :

  • de proposer des livres dans la colonne idée,
  • les livres recevant plus de 3 votes sont sélectionés
  • le livre ayant le plus de vote au moment du choix est retenu comme prochain livre du club


Général livre

Management 3.0 #Workout

Lorsque Claude Aubry a publié cet article à propos du site du club de lecture de Toulouse, j’avais déjà en projet l’idée de lancer un club de discussion. Je m’étais donc dis que c’était une nouvelle bonne raison de le faire.

La réunion du Klub de Toulouse se déroulait lundi 2 février, le livre du jour était #Workout de Jurgen Appelo. Les participants ont accepté que je m’invite à cette réunion en me connectant à distance en video-conférence.

Un grand merci donc à Marie-Josée, Nathalie, Jean-François, Cyrille, Jean-Pascal et Claude pour leur accueil sympathique.


Comment cela se passe ?

La facilitation de Claude est discrète et efficace, il lance une question à laquelle les participants répondent le temps d’un tour de table. Les questions sont par exemple : « quel lien feriez vous avec l’agilité ? », « pensez-vous que le type de management proposé dans l’ouvrage devienne « mainstream » ? », « quels sont les pratiques que vous avez expérimentées dans vos organisations ? ». J’imagine que les participants sont habitués à l’exercice. Le temps de parole se réparti harmonieusement, les éléments issus du livre et de l’expérience se complètent avec équilibre.

Concernant le livre en lui-même, les participants ont apprécié #Workout. Ils ont apprécié les explications simples, les illustrations issues de l’expérience, les propositions d’exercice de mise en pratique avec une équipe ainsi que les nombreuses références.

Ils ont également apprécié les nombreux arguments permettant de diffuser le message vers différents publics.

Vous pouvez retrouver ce livre ici : en version gratuite ou commander une version payante.



Le force du Klub est de pouvoir profiter du regard des autres, de voir ce qui les intéressent et qui parfois m’avait échappé. Un exemple : je n’avais pas remarqué qu’à la fin de chaque chapitre, il y avait une page de références… Bien sur, avec le livre sous les yeux, j’ai été étonné de constater cela lorsque quelqu’un a abordé ce sujet

Cette expérience très agréable me motive pour proposer un club de lecture à Bordeaux, je propose que ce soit un samedi et que le premier livre soit également #Workout de Jurgen Appelo.

Je vous propose donc de prendre le temps de la lecture du livre et de nous retrouver soit le samedi 14 soit le samedi 28 mars entre 10h30 et 12h00. Le Doodle suivant permettra de choisir la date :