Contribute to the Success of OpenStack

During the OpenStack Summit in Austin, Mark McLoughlin and I delivered a talk titled: “Contribute to the Success of OpenStack”.

Our talk was meant to explain how we were inspired by agile values and principles to improve our internal organization, and how we thought it could impact our ability to contribute more effectively to the OpenStack project.

One of the idea that is often used to describe the way companies are contributing to open source project is that you need at some point to wear your company hat to represent what your company needs, and some times you need to wear your upstream hat to represent what the project needs. We speak some time of the need to balance between upstream and downstream.

Our point was to say that this idea represents the reality perfectly well in projects were the developers are the users of the projects. In this case they are solving problems they are facing on a regular basis.

The OpenStack project is more complex in this sense that the developers are rarely the main users of the project. They don’t have to operate a large scale cloud on a day to day basis.

So, to be able to understand the needs, and to propose effective solutions, the developers of the project need to hear from the real users. That’s were they need to wear at the same time their corporate and upstream hats, because the customers and partners of their company represents the needs of the real users, and wearing those hats they are bringing a lot of value to the project by proxying the real users.

We also explored the fact that when the reaction toward one of the idea that we were bringing on the table was really hostile, there was probably good reason for that, and that was great value for our company that the project was bringing to us. This obvioulsy can only be achieved when the maturity of the project is high enough, especially on the corporate diversity aspect.

We covered after that how we were organizing the teams that are contributing to OpenStack by giving them a clear focus to solve some real user’s needs, and end to end responibility to solve this. Those teams are primary responsible for contributing to some of the components, but the components are not driving the structure of the organization.

For each team, we want the team members to understand their mission, their goals, and to drive their contribution in the value flow.

Here is the recording of the session:


For the next Summit in Barcelona, I proposed 3 talks:

  • The first one with Maria Bracho: “Providing Tooling for Effective Collaboration”
  • The second one with Nick Barcet: “Does your voice count in OpenStack? Yes!” this one could be consider as a followup of the talk given this spring
  • The third one: “Raising the awareness on diversity”, one workshop during the last summit was an eye opener for me, and I would like to continue the effort to raise the awarness on that topic.

You can vote on your preferred presentation here:

If you want to vote for the one I submitted search  for my name: monville 🙂



Header photo by William White

What science knows about happiness that could tranform OpenStack

A short article to publish the video recording and the slides of the talk I gave today at the OpenStack summit in Austin.



Header picture is from Ryan McGuire.

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.

1500 développeurs dans mon équipe

1500 développeurs dans mon équipe est le titre de la session que j’ai eu le plaisir de donner lors de l’édition 2014 l’AgileTour à Bordeaux.

J’apprends l’agile depuis déjà longtemps en pratiquant et en partageant les valeurs, principes et pratiques avec des clients et d’autres pratiquants. Et c’est peut-être depuis que j’interviens au contact d’Openstack, un logiciel libre d’infonuagique (ou si je parle en presque français “a cloud open source software”) que j’ai appris le plus.

Ce que j’ai appris ? 

2014-10-31 15.15.17J’ai appris que l’on pouvait créer un produit avec une équipe de 1500 développeurs répartis sur tous les continents, que l’on pouvait avoir la certitude de délivrer les nouvelles versions à date fixe tous les 6 mois, que le processus de revue de code apportait beaucoup plus de bénéfices que ce que j’imaginais au départ, que la gestion des branches de développement pouvait être plus simple et plus efficace. J’ai aussi appris que la socialisation, l’accueil des nouveaux arrivants, le maintien du lien était une chose très importante… 

L’idée de cette session est de partager ces apprentissages pour que vous puissiez vous en inspirer dans vos organisations.

Et bien sur, il ne s’agit pas de “mon” équipe, mais de l’équipe qui contribue à Openstack… Et il n’était pas 1500, mais 1419 à avoir contribuer à la 10ème version JUNO publiée le 16 octobre 2014.

La photo d’entête est de Anne Gentle (License Creative Commons 2.0) Il s’agit de la vue de la salle pour la Keynote d’ouverture lors du Summit à Hong Kong en Novembre 2013.

Agile and Openstack

Here are the slides and the video from the session “How do you agile your global team to contribute to Openstack?”

Slides from the session:

Video from the session:

Développer des produits avec des équipes distribuées

Après la conférence que j’ai donné le 10 avril pour le ScrumDay, je suis en train de préparer celle que je donnerais lors de Mix-IT le 30 avril 2014.

Le résumé de la session est assez similaire entre les deux, voici celui du ScrumDay :

De nos jours, presque tout le monde sait faire grandir une infrastructure de machines en mode distribué, avec une très bonnes communication entre elles, et en évitant les points uniques de défaillance (c’est une traduction de SPOF, single point of failure). En y réfléchissant, des serveurs distribués à travers le monde ne sont pas si différents que des équipes distribuées, elles ont besoin de connexion et de synchronisation…

Vraiment ?

Nous sommes des humains … pas des machines …

Dans cette session, nous allons voir comment eNovance, une société qui conçoit des produits destinés à bâtir des infrastructures informatiques, d’ou le pitch initial… Nous allons donc voir comment eNovance a fait grandir son équipe de développement produits en mode distribué en suivant les valeurs et principes Agile. Cette session expliquera comment nous nous appuyons sur nos Product Owner pour guider nos contributions à des logiciels libres constitutifs de nos produits. Nous verrons par exemple comment nous planifions nos itérations en suivant le rythme donné par le projet Openstack. Nous verrons également comment nous organisons nos scrums, sprint planning, sprint review et retrospectives en nous adaptant à des équipiers positionnés sur différents fuseaux horaires.

La session présentera le mode de fonctionnement d’un projet open source emblématique : Openstack. Ainsi que la façon de contribuer de l’équipe eNovance.

La différence entre les sessions va se jouer sur plusieurs aspects :

  • l’expérience acquise par la première présentation,
  • les retours et les questions des participants,
  • les questions posées par un des organisateurs de Mix-IT qui vont orienter la présentation sur des aspects différents.

Franck Depierre, l’organisateur qui a posé ces questions stimulantes, m’a demandé de préciser certains points. Les questions sont en gras :

  • Pourquoi faudrait-il avoir toutes les équipes distribuées qui travaillent ensemble ?
    Ce sont les membres des équipes qui sont distribués à travers le monde. Pour une équipe qui développe un produit, les équipiers sont répartis entre les bureaux de Bangalore, Paris, Montreal et San Francisco, de plus certains équipiers travaillent de chez eux (Hambourg, Dallas, San Francisco, New-York, Bordeaux, Toulouse…). Les équipes sont composées de personnes ayant les compétences nécessaires pour développer le produit, leur localisation n’est pas un critère de choix.
  • N’est-il pas plus simple de faire l’intégration sans avoir de communication entre équipe ?
    Nous préférons une approche ou l’équipe livre un produit déployable. Les produits sont modulaires et combinables entre eux : une infrastructure cloud de base peut être associée à l’usine de développement logiciel par exemple.
  • A qui est destiné cette session ?
    A des agents de changement dans l’organisation, à ceux qui, dans le flux de développement d’un produit, s’intéresse à faire évoluer l’organisation de leurs équipes.
  • On a l’impression que tout est bien dans le meilleur des mondes. Quels sont les freins, les problèmes qu’il faut identifier ? Est-ce uniquement un pb de product owner ? Ne pourrais-tu pas donner des recommendations pour tout les profils de l’organisation ?
    Tout est encore loin d’être bien dans le meilleur des mondes… La distance créée de nombreux problèmes que nous n’aurions pas avec une équipe colocalisée et des communications face à face (on s’en doute)… Je compte évidement aborder ces difficultés et les solutions que nous avons identifiées pour l’instant.
  • Est-ce qu’un coach ou facilitateur aide à ce mode de travail ? Si oui, est-ce que le coach doit être unique et intervenir sur tous les sites ? Est-ce qu’il faut monter une équipe de coaches ? Quelles sont les réunions à mettre en place ? Sur quel cycle répétitif, basé sur Scrum ?
    C’est mon role dans l’organisation. Nous formons progressivement une équipe de personnes intéressées qui diffusent dans leurs équipes la culture agile et open source de l’entreprise. Et oui, avec une approche itérative 🙂
  • Comment justifier que les équipes distribuées sont plus viables que les colocalisées ?
    Les équipes distribuées permettent de regrouper des personnes compétentes sur un produit sans avoir besoin de leur imposer une localisation… Dans l’idéal, je préférerais que toutes les personnes puissent travailler dans la même pièce.

Il me reste une semaine pour revoir la session afin de maximiser la valeur des messages à transmettre ! Vous pouvez également me poser des questions via Twitter, en commentaire de ce billet ou par mail pour que je les prenne en compte dans ma préparation.

Pour en savoir plus sur cette édition de Mix-IT 2014, consultez les actualités et particulièrement les articles présentant le programme.


[modification du 15 novembre : la vidéo de la session de Mix-IT vient d’être publiée]