Category: General

  • Work Rules – Insights from Google that will transform how you live and lead

    Work Rules – Insights from Google that will transform how you live and lead

    Work Rules is a book from Laszlo Bock, SVP of People Operations at Google. You will find that the “People Operations” that could be called “Human resources” in other organizations is really different in its way to operate.

    work-rulesMain difference is the focus on data, not on opinion, and to be careful with natural human biais.

    They decided to measure everything that concerns people and their interactions. They started with the recruitment process, and analysed how the numerous interviews and tests was not able to eliminate interviewer’s biais. They changed the way interviews was conducted and continue the measurement to see what was working or not.

    Brain teasers appeared not so useful. They probably demonstrate that the one who is asking the question is smart, but they will not help to find the right people for the organization. Asking questions that help people to share their behavior is much more interesting. For example: “Tell me about a time your behavior had a positive impact on your team” and “Tell me about a time you had difficulty working with someone”.

    Their recruitment goal is: “Only hire people who are smarter than you are, no matter how long it takes to find them”.

    They also improved employee surveys and gave analysis capabilities to managers and employees.

    One of the things that I found particularly interesting –  and one of the thing I try to put in place with every team I work with – is the peer feedback. They improved and simplified radically their system to reach 2 questions:

    • One thing the person should do more of
    • One thing the person should do differently to have more impact

    A benevolent way to help people grow.

    You will discover also things that I already covered on this blog, like the way to thank people, to send kuddos. They have G-thanks (that doesn’t need manager’s approval) and they also have 750$ peer bonuses (that doesn’t need managers approval either).

    Of course, the author covers the way to set goals with the OKR approach. You can have a look to the re:Work guide designed by Googlers to learn more on this.

    I encourage you to read the book, to read this illustrated summary. And to intrigue and give you really the desire to do so, I will share the summary in 10 points:

    1. give your work meaning
    2. trust your people
    3. hire only people that are better than you
    4. don’t confuse development with managing performance
    5. focus on the two tails
    6. be frugal and generous
    7. pay unfairly
    8. nudge
    9. manage the raising expectation
    10. enjoy (and start over to 1)

     

    Header picture is from Jason Yu.

     

     

  • LessPass – password management

    LessPass – password management

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

  • The Chimp Paradox

    The Chimp Paradox

    The Chimp Paradox is a book from Steve Peters subtitled: The Science of Mind Management for Success in Business and in Life.

    I used the model proposed to represent how our brain is working during conferences I gave on the Search for Happiness, and I had some positive feedback.

    In this article, I would like to give you a little more and invite you to read Steve Peters’s book.

    TheChimpParadox

    This book is an exploration of a solar system. The sun is the place you wanted to be. The planets represent zones to explore like: yourself, others, communication, stress, success, happiness, trust, security.

    The first planet is divided. It represents our mind, our way of functioning, the battle between our human and our inner chimpanzee.

    The model proposed by Steve Peters is simple and is composed of three parts:

    • the human: us, in our frontal lobe,
    • the chimp: our emotional machine, in our limbic system,
    • the computer: the place where we store information and manage automatic responses.

    If we look at the way a responsible human being will deal with a situation. He will first look at himself, what he has done to generate this problem. Then, he will look at the circumstances and their impacts on the situation. And after, he will look at others and search for ways to help them change their behaviors.

    If we look at the way a chimpanzee will deal with a situation. It will be less rational and much more emotional, and it will work in the opposite direction. The chimp will first look at others and finger point at what others have done, then it will look at the circumstances and blame them, and in the end, it will look at himself with pity.

    A human being has to live with an inner chimp that will wake up fast (5 times more quickly) each time it feels danger and will take over the thinking with the 3 F: Fight, Flight or Freeze.

    The chimp is ours. It’s a part of ourselves given at birth. We cannot say: “Oops, sorry, it’s my chimp.” Like if it was our dog, we are responsible for it if the dog bites someone.

    The third part of the model is the computer. The computer, 20 times faster than the human, will take over to handle known situations. So, it will relieve us of a lot of thinking. That explains why, in some circumstances, we react and then think: “why did I say that?”.

    The problem is to whom we want to delegate computer programming: the human or the chimp?

    After introducing the model, the rest of the book studies ways to manage our inner chimp and to reprogram our computer with the human.

    The header picture is from Matthew Wiebe.

  • OpenStack Summit Austin 2016

    OpenStack Summit Austin 2016

    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:

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

    Thanks for your support!

  • The submarine story

    The submarine story

    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.

  • Joyful Year!

    I hope that 2016 will bring you joy and that you will have the opportunity to bring joy to others!

    Joie means joy in french. This nice picture from David Hermans express the wish well.

    2016-David-Hermans-Joie

  • Massive Peer to Peer Collaboration

    Massive Peer to Peer Collaboration

    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

  • DATFlock2015, unicorns, distributed teams and bad agile

    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.

  • Annual Performance Review

    Annual Performance Review

    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?

  • Black Box

    Black Box

    The black box in this article are those installed in planes. Those black box allows to analyze what happens during a more or less dramatic incident. Setting an organization where facts are analyzed to improve the system is a defining characteristic of airlines industry. A characteristic that enables an incredible improvement of security.

    Matthew Syed starts by showing this fundamental difference in his book: Black Box Thinking – Why Most People Never Learn from Their Mistakes–But Some Do.

    Compared to the health-care system where the culture is to blame people that made mistakes. A culture that leads to the dissimulation of mistakes and to no improvement of the systems, causing 400,000 deaths per year in the US (third cause of mortality before traffic).

    Matthew explains the anthropological and psychological root causes that leads us to avoid recognition of mistakes, and then to incapacity to conduct improvements.

    One main aspect is the mindset in which we look at the development of our skills. As stated by Carol Dweck there’s two types of mindset: fixed mindset, where we think our skills depends of our gene, and growth mindset, where we think our skills depends on practices.

    The book presents transparency approach from people and organization that allows experimentation avoiding our natural biais.

    One approach is marginal gains, the fact to change small things to correct a small weakness, that will lead at the end to high performance.

    Another approach is to avoid closed loop thinking that leads to deny mistakes reallity, and then to reproduce those mistakes over and over again.

    As stated before, avoid the blame culture is necessary to create the conditions that allows people to reveal their mistakes.

    So we can try and try again a lot of times to finally succeed.

    A must read!

     

  • The Search for Happiness

    The Search for Happiness

    During the past days, I had the opportunity to give two conferences. One in Raleigh, North Carolina, on October 20, 2015, for the Red Hat Agile Day. The other, in Bordeaux, France, for the closing keynote of AgileTour Bordeaux, on October 30, 2015. I adapted the content according to the feedback received after my opening keynote of the Drupal Developer Days.

    Agile

    The first sentence of the Agile Manifesto is often ignored:

    We are uncovering better ways of developing software by doing it and helping others do it.

    Studying this sentence helps to understand the state of mind of the manifesto writers, continuous improvement, mutual aid, listening. We could apply the same way of doing things to other areas than software development ones. And, of course, there’s no reason to restrain the application to one team. Some practices and tools proposed by some framework limit the application to a team.

    Culture

    Culture is the immerse part of the iceberg. When you observe an organization, you will be able to see the tools and practices. The principles and values that define the culture are seen through the actions of the organization members. When you try to introduce practice and tools that will not fit the organization culture, even if there’s an improvement at the beginning, things will be back to “normal” after some time.

    That’s why Peter Druker said:

    Culture eats strategy for breakfast, technology for lunch, products for dinner and soon thereafter everything else too.

    An agile company

    Some years ago, I was facilitating a meeting with the leadership team of a small company, they were around 20 at that time. We were working on the organization principles of the company. The team knew the company will need to grow fast, and they wanted to keep the creativity and innovation that made the success. Long story, short : we ended up with 6 principles organized on a main one:

    Employees Happiness

    Those principles were: autonomy, responsibility, trust, transparency, communication, and the conviction was that growing agile would be the way to achieve it.

    how-do-feelAs the company was growing fast, we wanted to know if we were heading in the good direction, and if employees were really happy. And the best idea we found to get this information was to ask people on a day to day basis, using 3 simple buttons and a form to collect feedbacks so we can know what we could continue doing, what we could change or stop doing.

    When I start explaining that idea, during one of the new comers breakfast session, one person asked me a simple question:

    What do you mean by happiness?

    A simple question, I was not able to give an answer to. Everybody knows what is happiness, but I was not able to define it. That leads me to follow the Science of Happiness Berkeley course of Dacher Keltner and Emiliana Simon-Thomas. I learned a lot on what is happiness, differences between happy and unhappy people, and mainly how to become a happier person.

    « Happiness is the meaning and the purpose of life, the whole aim and end of human existence. »
    Aristotle

    Why be happy?

    Scientific study shows what we may be able to guess. Happy people feel good, have a stronger immune system, are physically healthier, live longer, are more sociable, better liked by others, more resilient, more cooperative, more productive, more energetic, have more social support, are better leaders and negotiators, have a richer network of friends, earn more money, are more charitable, demonstrate more flexibility and ingenuity to solve problems

    What makes us happy?

    circumstances-daily-activities-set-pointAnswer may not surprise you, it’s not a new car, even a fancy one. Circumstances like that will have an effect on our happiness level, but we will go back to our set point soon or later. The most important finding, according to me, is that our happiness depends by 40% on our activities, and not on our genes or the circumstances. We can choose to have an impact on our happiness level.

    How?

    Being positive. Trying to look at situations from other angles in every day to day life situation and relationship with others.

    Optimism

    Being optimistic. Investing time as an individual and as a team to define what could be our best possible future. Working to create the conditions that help people to do their best. One of the proposed exercises is for example to write your self portrait, your best possible self. Taking 10 minutes a day to write and refine this portrait during 10 days will learn you a lot on yourself and what you can do.

    Gratitude

    Expressing gratitude. Creating the conditions that help people to do the same. In organizations, Retrospectives are good opportunity to do so, you can organize Kudos Box, or distribute Wow cards. It could be done using a diary, encouraging people to do the same, especially interns and new comers, so they can keep a trace of their surprises and learnings that could be useful in the future.

    Kindness

    Practicing kindness. Kindness letters are a simple way to do so. There’s even a world kindness day on November 13th, that could be a good opportunity to do something as a team.

    Forgiveness

    Forgive, a practice simpler to say that to do, especially when it’s our turn to forgive. A practice that, like gratitude and kindness, is the more beneficial to the sender than the receiver. Practices that work even in the absence of the receiver.

    Carpe Diem

    Seize the day, an idea simpler to understand, harder to practice. I will cover several different notions around time management. Flow from Mihaly Csikszentmihalyi that helps to understand those time when time flied and when we were incredibly focus and efficient as an individual or a team. We can enjoying those kind of moment when we maximize the focus and minimize interruptions. I even seen a team synchronize the work around pomodoros cycles to avoid interruptions.

    As recommended by Philip Zimbardo “the optimal temporal mix is what you get from the past — past-positive gives you roots. You connect your family, identity and your self. What you get from the future is wings to soar to new destinations, new challenges. What you get from the present hedonism is the energy, the energy to explore yourself, places, people, sensuality.”

    Celebrate

    Savoring life’s joy is a way of life. Celebrate success, our own successes or the successes of a team or an organization, is an important, not so usual, activity. There’s several ways to celebrate success and we need to find our own, a way to do it is to set up a work expo as proposed in Workout from Jurgen Appelo.

    Goal

    Celebrate success supposed to define goals. Several scientific studies on this subject demonstrate that goals must be intrinsic and not extrinsic (like money). Defining goals, prefer approaching ones to avoiding ones. That’s why I like the OKR approach (Objectives and Key Results). Because the objectives and key results are created through the conversation of all stakeholders and not hierarchically imposed. This is also an excellent opportunity to look at objectives in more shades than the binary black and white, and to consider each steps in the good direction as a partial success that we could celebrate.

    Nurturing relationship

    Contribute to a goal bigger than self, with people you appreciate. Create your tribe, troop, group in which you will be able to connect, share, learn. Your surrounding will have a dramatic influence on your ability to deliver. Surround yourself with passionate people will give you a lot of energy. You can also provide this energy to the people that surround you.

    Soul and body

    « A sound mind in a sound body.»

    This quote from Juvenal has been repeated for a long time, is there to remind us that we have a body and that when we take care of it, it has an influence on our mind… and so the opposite. And more than sport, ideal activities to practice with personal or professional relationships, meditation can be an opener on the happiness journey.

    Balance

    Happiness at Work implies that we could be happy or not depending on where we are. Work life balance separates two worlds in where we will not be the same person. Maybe it’s time to behave as only one person, without any professional mask? Maybe it’s time to be happy in life? Maybe it starts with us, with our smile?

     

    Thank you for your feedbacks at the end of the conferences and your messages on Twitter.

     

    Some links to go further:

  • 50 Quick Ideas to Improve your User Stories

    50 Quick Ideas to Improve your User Stories

    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.

    50quickideasIllustrations 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 😉 )