Author: Alexis

Some time ago, I add a card in the inbox column of my personal GTD kanban board (I can share the model if needed). The card was labeled “Standing Desk”.

During the next review, I moved this card in the “Someday / Maybe” column. And the card sat there for… nearly ever.

During the same week several factors made me reconsider this card:

• I had skipped some breaks during the days, and forgot to change posture, so my back started to hurt a little
• Colleagues at work were discussing the idea to buy standing desk and they did it and report that they were happy 🙂 (Thank you Mark and Hugh!)

So, I moved the card directly to the to do this week column, look at the options and decided to change my whole desk (I bought the previous one 20 years ago) and chose the IKEA Berkan model.

With this desk I can have my whole set-up moving. The first week, I thought it will really help me to “not forget breaks” and to “not forget to change posture” as it was difficult for me to stand for long, so I alternate sitting and standing position during the day.

After 2 weeks, I can stand longer, the cat is using my chair, and I need to be sure to start my pomodoro timer to remember to have a break and to change posture. The fact to stand has a good impact on my numerous conference call during the day: I am able to close the call faster. The same effect that leads to decide that a daily synchronization meeting should be done standing up, this way it could be shorter (There’s a study on that effect here).

I recommend you to test, and you will probably adopt it!

 

The day I received my IKEA desk, Lisette Sutherland published a post showing her desk, probably the same model in another size! By the way, if you are interested in collaboration and remote work, follow her!

 

 

Header picture is from Ryan McGuire.

LessPass is a password management system based on a completly different idea compared to existing solutions.

Most of the solutions are based on a centralized storage of password protected by a master one. The centralized storage can be basic, like a spreadsheet on your own computer or on a server. It can be a little bit more complex like commercial solutions available nowadays.

LessPass is different is the sense that it will not memorize any of the password. The system will only generate the password based on the informations you will provide. You don’t need to trust someone else to keep your password safe.

Of course, the project is open source, the code can be audited. And, there’s no tracker on the website (you can check that with  Privacy Badger for example).

Next OpenStack Summit will be in Austin in less than 70 days.

You can vote for your preferred sessions following this link.

I submitted two talks: the first one will cover what science knows about happiness that could transform OpenStack and the second one with Mark McLoughlin will study how organization can increase the impact of their contributions inspired by practices, principles and values of opensource and agile projects.

To vote for those sessions:

• What science knows about happiness that could transform OpenStack
• Contributing to the Success of OpenStack

Voting closes Wednesday, February 17 at 11:59pm PST (February 18 at 7:59am UTC)

Thanks for your support!

Once more, I have been to a conference given by Jean-François Zobrist. It’s always the same ; he tells what he have learned during the years he was managing FAVI ; and it’s always different as he adapts the content to the audience.

This conference was organized by Germe Bordeaux groups at ISG. Germe started as an initiative of APM, a not for profit organization regrouping entrepreuneur’s local clubs to improve their management practices. Jean-François Zobrist tell stories connected to what he has learned during APM or Germe’s sessions.

This post to deliver one of those stories, and to invite you to met him in a conference or to read what he wrote to transmit all the learnings

So, the story. During one session organized by Germe, they invited a nuclear submarine captain to explain his management role. They were really surprised by the fact that the captain is not supposed to do anything in the day to day of the submarine. He could spend all his days in his cabin without being disturb by anyone.

What if an “enemy” submarine was just crawling in front of their nose? The team would not disturb him as they know perfectly what to do in those kind of situation. But if a shoal of fish looked really too similar to a shoal of fish for the board instruments, then they will probably call him.

This short story shows the importance to setting an efficient system (people, teams, organization, processes…) and to let this system work, and at the same time listen to weak signals that will drive today’s actions or tomorrow’s innovation.

He explained that when a surgeon was explaining the challenge of heart operation was to deal with the clock, because of the growth of microbes. Favi started to look at this problem and develop new antimicrobial alloys.

 

Header image is the “Typhoon3” by Bellona Foundation. Licensed under Copyrighted free use via Commons.

I have been asked by Philippe Honigman to answer 2 questions about open source collaboration to help him on one of his projects.

I was wondering what could be the questions not already answered thousands of times. This curiosity led me to an interesting conversation, with interesting insights I would like to share with you.

First question: What’s the hardest part about rewarding a community supporting an open source project?

There’s a lot of different motivations and rewards you can find contributing to an open source project. The first one could be the product or service you are contributing to. The motivation and satisfaction to contribute to a greater good. The fact that collaboration with others, will improve the quality and security of the product.

There’s also a lot of learning opportunities. Because the code base is public (in case of software development) you can learn how the others are solving problems when you review the code, you can also benefit from the reviews of others. All this could also lead to interesting employment opportunities.

Some people will work hard to increase their reputation, to gain status or authority on a project.

So, the hardest part about rewarding the community supporting an open source software could be first to understand the motivations of the contributors and to adapt the reward to the motivation.

Second question: What’s the hardest part about making decisions in open source project?

The question around decision is an interesting and also a tough one. Some of the mechanisms are really collaborative and we can say that the best ideas win. But sometimes, decisions based on authority gained in the past seem irrelevant, or even totally ego-driven

The organization of some open source project are quite traditional and hierarchical with board, technical committee, and a hierarchy for sub-projects. Even if the people are co-opted or elected by their peers  to gain authority and status, it is still a hierarchical structure.

Hierarchies emerge because of our limited understanding of decision-making processes. We are looking for someone who will ultimately “take” a decision.

In some organization where there’s no arbitration mechanism, nobody to decide, people tend to become more reasonable and start making decision and avoid letting their ego undermine the collective effort. Those people have learned how to make it happen.

We continue the conversation about different kind of organizations and decision making process. And then, we came back to the first question… I (intentionally) forgot to speak about money and value sharing because I don’t really have a solution to propose that really satisfies me… People that contribute to open source project are often  employed by a company that needs the product / service, and when they are not, some of them are looking for an employment opportunity… For the others, some of them have another source of revenue, and are OK with the other rewards.

That’s the aha moment when Philippe explained me the ideas they had, to tackle the reward questions for contributions and to be able to distribute the decisions avoiding the effect to have a concentrated power in the center.

They want to use the powerful blockchain technology popularized by the bitcoin experiment. I’m saying “experiment” because the Bitcoin is a particular application of the blockchain technology.

This short video can give you a little overview of what blockchain is about:

 

If we use the blockchain technology to create distributed services, we can create a car sharing service with no centralized control, like LaZooz. So the people who are sharing the goods / services are doing well and it benefits to the community of people involved instead of being confiscated by a platform like uber, airbnb, blablacar…

We can imagine to use the blockchain technology to facilitate the decisions making process in an open source project and to reward the contributors according to the value of the contribution and the risk they are taking when they join a project at an early stage for example. More on those ideas, if you look at http://backfeed.cc/ and https://www.ethereum.org/

 

Lessons (re)learned:

• Don’t tell them, ask them. If you want people to give some interest to your idea, it’s probably a good idea to ask them some questions that will help them to be aware of the problem you are trying to solve.
• Raise the awareness on motivation and their difference between people is an important piece to start working with a team, I will reuse my trello board to use the moving motivators with a distributed team.
• Open your mind…

Comment and share this article if you like the reading 🙂

 

Header photo by Tim Swaan

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?