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 Teamed.io. 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.

Unicorns

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.

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 !

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:
sticker-agile-tour-2013-v2
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 😉