Category: General

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

Take 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

I 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.

And 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.

When I present the 14 points of Deming and the 7 deadly diseases of organization, I usually take some points and diseases as a starting point for discussion and thinking.

One disease I usually pick is the third one:

Evaluation by performance, merit rating, or annual review of performance.

People react in a similar way. They agree they have a problem, annual appraisal are inefficient and demotivating factor… But they “have to” comply to the rules of their organization.

To be clear on that, thoses rules have been set-up usually with the intent to develop people, and improve the performance of the organization. The intent is good, the problem is the evaluation of the performance of the solution, and not to have reconsider the solution sooner.

Since summer 2015 and the announce of the end of annual performance review at Accenture, in the Washington Post, or the Financial Times for example. Accenture join the club of enterprises that get rid of those old practices, like Deloitte before them that work to simplify radically their performance and development system.

Those news represent a good opportunity to start a change in the organization that are still using the old appraisal systems. An opportunity to rebuild the system redefining the intent. What do we want to accomplish? Developing people? Improve organization performance? Something else?

Gojko Adzic and David Evans starts a series of books with efficient catchy titles: 50 Quick Ideas…
I only read the one about User Stories for the moment, but you could be also interested in the ones on Tests and Retrospectives.

Illustrations of ideas are great, it helps to remember them.
Even if I already knew and used some of the ideas, the way it’s explain give sometime a better way to deliver the message to a team.

The structure of each ideas are: a short explanation of the idea, key benefits and a part on how to make it work.

The authors also created card decks with the same content (Start-up idea: I would like a digital card deck that I can carry in my phone please 😉 )

Reinventing Organizations a book from Frederic Laloux, is structured in 3 main parts:

• The first one describes the evolution of organizations
• The second one presents the practices of evolutionary organizations
• The third one the emergence of those organizations

History

The author uses color coding and starts the story with the first groups of human (Infra-Red) who where evolving in groups of around 12 people. The group cannot scale above this size. Then came a period when explanations of what is happening are provided through magic (Magenta) the group is lead by elders wisdom and chamans (in a dangerous world, being alive is a proof of wisdom).

The next stage (Red) enables the organization to grow, the organization depends from a chief with all powers, and those chiefs will demonstrate theirs powers at every opportunity. Examples of those kinds of organizations are regularly finger-pointed: gangs, mafia…

The next stage is the “Command & Control” conformist organization (Amber), human groups can settle and start agriculture and first forms of civilization, they can start to plan for long-term and the group can continue to grow. Those organizations are often described from their tendencies to polarize: good versus evil, us versus them… One of the examples given by the author to illustrate those kinds of organizations is the Catholic Church.

Another stage further is the “Predict & Control” achievement organization (Orange). Those organizations use Management by objectives, process, projects. They have a lot of staff functions that define how the others in the organization must work (HR, Marketing, Finances…). Organization is seen as a machine. The organization is rational, hierarchical, ego is absolute there, social inequality rules.

The Pluralistic organization (Green) is described as a family. Respect, fairness, community, stakeholders interest are important things. Those are value driven culture organizations that work for an inspirational purpose.

Every evolution leads to look at the previous stage as retarded ones… And it will happen probably for the next stage.

The last current stage (Teal) is describe as living systems. Ego is not absolute but a variable, they are looking for wholeness. Those organization are built on principles like self-actualization, building on strengths, wisdom, peers relationships. They have no hierarchy, and few staff as advisory.

Practices

The part 2 presents practices of teal organization discovered during research conducted by the author in several organizations. Those organizations don’t know each others, are from several sectors and sizes, and share a lot of practices.

Those practices are grouped by 3 principles:

• self-management
• wholeness
• evolutionary purpose

The comparison between Orange and Teal organizations is really interesting. You will find below comparative charts that you will find in the book.

Emergence

Frederic Laloux describe in the last part the emergence of teal organizations and the impact on the whole society.

The author gives ideas to start a new company and transform an existing one, with teal organization’s principles.

This book was discussed during the session of Saturday September 19th of the Bordeaux Book discussion club. Passionate discussions that lead me to tell you to read this book.

To taste what you can find in the book, you can have a look to a conference given by the author:

I used, once again, listening exercises during the Devops Masterclass that I delivered with one of my colleagues in Ho-Chi-Minh-City for the APAC Red Hat Tech Exchange. I committed this time to publish a short description of those exercises.

I set the stage for the exercises with a short warm-up exercise 1-2-3-Go ! That helps to understand we are not probably using only our ears in the listening process 🙂

Then, I asked the group to form pairs.

First Rule

I explained to them that we will start with one listener and one talker and that we will have the opportunity to switch role later.
The talkers will have to speak for 60 seconds and deliver a story on any subject that is really important to them.
The listener will have to respect a first rule : Don’t talk.

I then facilitate a debriefing session, asking the listeners how they found the exercise, and then how the talkers felt about the listening of their counterpart. I insist on how they felt 60 seconds was, long or short ? I insist also that asking question may derail the talkers from their path, and that it may lead them on something that is important to you, but not them.

Second Rule

When the group is ready. I propose that we switch the role of listeners and talkers and that we introduce a second rule : Don’t even think about talking.
And we start again for 60 seconds on a story that really matters.

The second debriefing session is even more interesting about how difficult it is to not let the mind wander on something else. There’s obviously questions on the importance of questions that are here to clarify what the talkers are saying, or that demonstrate the interest of the listeners.Usually, I don’t need to answer those ones, a part of the audience gets it very fast and is able to answer that. What is the goal of your question if we are not listening to the answer but are working on preparing questions ? Our questions will probably be answered if we let the person continue their speech, or this question may have a small interest at the end.

Variants

There’s a lot of variants possible for this simple exercise:

• you can propose to the person to prepare their speech fixing the topic on introducing themselves. You will need to add more time for this (probably go for 90 to 120 seconds…)
• you can propose the persons to add a small bar on a paper each time they have a question during the first phase, and to tick this bar when the question is answered. And ask them to consider the bars that are still there at the end and to measure the importance of those questions.
• you can propose to the group to work in group of 3 people, with one observer each time

I first heard of this exercise from Paul Klipp in ALE2014. Another time, I attended a session with Olaf Lewitz and Michael Sahota during the Scrum Day in Paris in 2015. And one more time with a session delivered by Oana Juncu during Agile France 2015. Each time, there was variants, and each time it was really powerful. I had the opportunity to test it on different occasion, and it is a good eye opener to ease the following conversations.

When will you try it ?

Header photo Listen to ME! by Jonathan Powell under Creative Commons

Last week, I rehearsed a session around the evolution of organizations, methodologies and IT with some people of the Red Hat Montreal office. Thank you to them for their valuable feedback! Even if the title of the presentation was Devops and Bimodal IT, I presented some roots of the evolution of organizations and methodologies, and their short term and long term impacts on businesses.

I used a timeline and zome out to show previous moves, and “selected” important events, like Deming involved in the Japanese reconstruction, the new new product development game by Takeuchi and Nonaka, or The Machine That Changed the World : The Story of Lean Production by Womack and Jones.

At the end of the presentation, there was a discussion thread around clarity of vision and goals of enterprises. One question arose that foster an animated conversation : “What is the goal of agile enterprises?”.

This question led to a definitive answer from one attendees : “The goal of enterprises is to make money.”

And the discussion starts…

There was opinions like: “the others purpose are only things to hide the main goal of making money…” or “good intentions, but if we look at what enterprises are measuring, we know that money is the main driver”… and so on…

I tried to push my opinion that money was only a by-product of a higher purpose for enterprise that operate on a different model than “making money” ones. And that it worked for those companies… People seemed not really convinced… Still some work to do on this 😉

Featured image by Jericho [CC BY 3.0], via Wikimedia Commons

The first time I explain that to enable collaboration, we need to create the conditions of this collaboration between people, people approved… But I feel like it’s not really understood.

The idea that a meeting needs to be facilitated to help participants to achieve their goals is seen as animation… Like if it was only entertainment…

I lived an interesting experience that can illustrate this idea of “creating the conditions”. We joined friends for a weekend in an holiday village. It was a real discovery as we didn’t know the kind of village and the place.

When we arrived by car on the car park, several employees was waiting for them with big smiles on their face. They took care to explain to the three of us that they will take care of the luggages, indicates us where to park, and how to find our room.

The simple fact that they were smiling, welcoming, benevolent enable in a snap a total deconnection from the week. I was on holiday! Nice weather and nice place probably count also… But I am sure that it was their behavior that makes a real difference.

The last sentence pronounced by one of them reveal their intention : “The dream begins now”.

And it works, I was instantly on holiday, and those one and half day spend there was really restful.

This can makes us think of the behavior we will adopt during our next appointment or meeting?