25 years ago, I have been told that I should read autobiography of famous people to understand how they found their way to achieve great things.

I did not understood the advice. My understanding was that looking at famous people was a little bit like what poor magazines are doing following the life of rich and celebs.

I was wrong.

When I read Benjamin Franklin autobiography in 2016, I understood the advice; a little bit late; I discover why it was so interesting to read people who are telling the stories of their life.

Autobiographers are trying to share what they learned during their journey in hope that it could help others.

There’s probably some ego involved in the process, and when you read autobiography, you could need to deal with that, with a nice smile on your face: yes, sometimes what we are doing is definitely ego driven.

To give you an idea of things I should have discovered earlier:

  • how he found a system to create good habits (based on a calendar where you mark your success and that helps you reflect on what needs more focus or improvement)
  • how he discovered the ideal size of a group for a meaningful conversation (the answer is maximum 12 people)
  • how he refused patents for one of the invention because it was for “the good of the people”
  • and many other things

The question is now, what is the next one I should read?

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

Happy or not?

Tracking the mood of the team is something that agile practitioners are doing for quite a long time. For example, in 2006, Akinori Sakata, explained in this article the use of Niko-niko calendar.

The idea is to tighten the feedback loop, and to detect problems even before they become really conscious to an individual, or to the team.

By exploring how we feel at the end of the day, it helps us to take a step back, and sometime to express what is not going well from our point of view.

So, I used it for teams, co-localized or distributed, for quite some time. The tooling is really simple if you only want to deal with the mood of one team.

At some point, I wanted to expand this to track the mood of an entire company, so we could be able to get more feedback, and to adapt what we were doing.

I had a look at what was on the market, and at this time, provided a tool to allow a quick feedback using a smiley ( 🙂 😐 🙁 ) and to leave a short text message associated to that.

There’s now a lot of tools on the market that are exploring employee engagement, like Niko-Niko or Happify.

Is it a tooling problem?

Obviously the quality of the tool you will use, will have an impact on your ability to run analysis, or to scale the mood measurement, but my take after several experiments is that it’s not a tooling problem.

It’s how you will take into account the feedback and act accordingly.



You could also be interested in this article Manage Your Emotional Culture published in the Harvard Business Review at the beginning of the year.




Sequence vs Priority

There’s sometimes conversations within teams about the responsibility of prioritization of backlog items.

The problems is the end result of this conversation. Whoever could have this responsibility, that could be the Product Owner or that could be an agreement within the team, the results will look like:

  • 80% of the items in priority 1
  • 15% in priority 2
  • 5% in priority 3

That leads to end-less discussion to find what could be priority 1, 2 or 3, and that’s not really helping to decide by what we need to start the first iteration, and what could be the meaning of it, and what could be the meaning of the next marketing release.

Near the planned date of the marketing release, people starts to worry about the priority 1 items that could not be included in the release. Suddenly the meaning of priority 1 became “must land in the release”, and people are focused and what will not land, instead of what will land in the release.

That’s the reason why I am trying to avoid the “priority” word. Instead I am asking in which sequence the items should be delivered. I am interested in the sequence of the items that could be included in the next 2 iterations. What could be the meaning of the iterations, and what could be the meaning of the release for the product and its users. It’s not priority, it’s a sequence.

Another illustration of sequence versus priority is the way the airlines are boarding their plane. Some of the airline are boarding first the business class and give a “priority” access to frequent flyers. That’s not solving the problem of boarding a plane as fast as possible. During my last visit in Austin, I have seen that Southwest Airline, organize the boarding in sequence with indicators inside the boarding terminal. This is a better attempt to fix the system.

That means that we need a tool that is able to record that sequence. A wall with post-its can do that. Most of the task/project tracker are not able to do that.


Header picture from Ryan McGuire.

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.

The after meeting feedback

I usually ask for feedback regularly during the meeting I facilitate. I use several techniques to do so depending if it’s a short feedback before a break or if we have more time at the end of the meeting.

One of those techniques is the ROTI, the Return On Time Invested.

I ask the participant to evaluate with their 5 fingers. If their time was well invested: 5 if their time was well invested, they have learned and contributed, 1 if it was not the place they should have been. I am asking them to answer the question all at the same time.
The name itself should led the participants to understand that I am asking them to value the investment of their time. I am not asking them to evaluate me, or to give me a grade. But it’s not necessarily working this way each time.

One thing I have tried after listening to Heiko Fischer is to tweak the question a little bit.

I am asking the participants to evaluate how the meeting was awesome on a scale
from 1 to 5?

I let the people being cynical about it…

And then ask a second question: On a scale from 1 to 5 how did you contribute to make this an awesome meeting?

The learning there is that there’s no magic, the meeting is a result of our commitment.

Obviously, it’s not needed in all environments, but sometimes it could be useful.



Header picture by Ryan McGuire.

Beyond Measure

Beyond Measure: The Big Impact of Small Changes is a book by Margaret Heffernan published by TED.

And it starts with:


The author suggests an exercise for team members. Form pairs in which one will ask a real question and listen for 5 minutes: “Who you really are?”, “What do you want in life?”. Silent listening, maintaining eye contact for 5 minutes is a great exercise. And then we switch role for another 5 minutes.

I already tried similar exercises using appreciative inquiry to start workshop or training with people that doesn’t know each other really well. I can attest this is really efficient!

Trust between team members is a prerequisite to develop our ability to talk about our mistakes, and to develop our ability to learn from those mistakes. This foundation for effective teams is also covered in this article: The Five Dysfunctions of a Team.

Social capital

Margaret introduce the notion of social capital with:

“The dynamic between people is what brings organization to life.”

She explains the importance of the time spent together at work, during breaks or lunch. She gives an example of the decision to synchronize breaks in a call center that dramatically improved the performance.


If some time needs to be dedicated to interactions between people, quite time needs to be organized to allow concentration. I already covered this topic in a previous article: Let us Code. One of the example given is a scientific study that shows the danger of multitasking. People are shown a video recording – in a typical news channel format – of a CEO explaining the strategy of a company. People are told to focus their attention to the sequence as there will be some questions to answer after that. They have been asked to give their opinion about the strategy… And if they were able to remember some information, together with not relevant ones about weather, stock quotes, other news alerts, that were displayed on the multiple banners… They were totally unable to criticize the strategy. The conclusion of the study was that multitasking prevents us to think. Quite scary if we think about who are the people addicted to multitasking in organizations.


The author also quotes other studies on work day duration (more than 11 hours a day lead to depression) or necessity for the brain to rest at least for 7 or 8 hours a day (less lead to reducing the ability to think).


Margaret explains the Pygmalion effect: expect great things, and they will more probably happen. This reminds us the importance to define ambitious goals, and to believe in the ability of people to reach those goals.

She encourages also to get rid of silos, and to empower people, to accept that leadership needs to be fluid, linked to skills and not to titles and ranks… Title and ranks could lead a part of the people (unfortunately the majority) to think that they are not good enough… And the Pygmalion effect will play in a bad way.

She recommends to people to choose to make some space for their contribution, even if it’s not their job or their role, just because it’s their life.

The author also gives the example of check lists, that reduced by a third mortality in hospitals as a way to take the power from a few to empower the many. This has been covered in another article: Black Box.

When we accept that there are talented people everywhere, people will think not only about the work to be done, but why we need to do it, and how to do it.

When you have done what is needed, Ask yourself what one more thing you could do to make those people happy?

A book to read (or to listen) and you could start with a TED conference given by the author:


La photo d’entête est de Ryan McGuire.