How Agile and Open Source work together in (nearly) perfect harmony

This article is based on the talk I gave for the Red Hat Agile Day in Raleigh on October 11, 2016.

The conversation about agile and Open Source usually starts with an interruption in this form:

Agile will not work in an Open Source context because…

That’s usually how a conversation will start, and that’s the motivation behind this talk because I feel that’s there’s a lot to learn on that, especially if we continue to listen after the word “because”.

One example of possible cross-fertilization between Open Source people and Agile people was given by Jim Whitehurst during the opening keynote.

Jim presented briefly the Open Decision  Framework that is meant to help making decision in an Open Source way. It’s on github for you to try, learn and modify!

This presentation was intended to discuss the collaboration mechanism in open source software development and how those mechanisms are evolving to tackle more complex problems.

If we want to simplify the explanation, we could say that one individual has a problem. She or He will build a piece of software to tackle this problem. She will do that openly, because it’s build on top of other open source software, or it works with other open source software, or maybe because she wants to enable people that have the same problem to use the software, to look at how the software is made and even to contribute to this software. Contribution could be comments, bugs, suggestion for improvement, or even patches…

That’s how collaboration works!

People have problems, they solve their own problems writing pieces of software, and others with the same, or nearly the same problems will use and even contribute to the piece of software that solves those problems.

And that’s how it works and how it continues to work for a lot of software, and we can see that some of the software have a few number of maintainers (some time few is one) even if the number of users is huge.

For a lot of software the developers are the main users of the software, real users, with real production need.

So when you are trying to tackle more problems at the same time, you will need to find a way to foster contributions to avoid the “only one maintainer” risk for your software (that could be really dangerous, if you plan to use in production, distribute or support this software).

How to contribute, how to recognize small contributions to encourage the next steps, how to announce your intention early so your idea could be challenged, the implementation of your idea could be challenged and at the end your code is better, accepted and merged. How to avoid the counterproductive effect of giving too much power to people that were here at the start and so on…

I would recommend The Art of Community by Jono Bacon as a starting point for studying that 🙂 or to look at all the resources available on OpenSource.com to learn more about Open Source. I am adding that especially because I add three questions after the conferences that started by: I didn’t ask the question during the Q/A session because I feel I don’t know enough about Open Source… And after that, the question was great, and I would have loved to have this question during the Q/A session :).

Even if sometime people tend to submit code without discussion expecting that a good solution will win the adhesion of other people (some time it works, and some time it’s not).

All those aspects of fostering collaboration are important, and we could expect that projects that forgot to have a good collaboration code, with “no assholes rules” for example, will probably not stay relevant for long.

The diversity of the community is one of the important factor that will improve the relevance and the quality of the solution that will be built. If we are all the same, all similar, we will probably rally easily one point of view. By having different point of view of the problem that we are trying to solve, we could improve the solution that is built to solve it.

Impossible Mission

The developers are not the users anymore, and we can see that when we look at the comments of people who attempt to use the first release of some software:

  • Impossible to install
  • Impossible to update or upgrade
  • Impossible to debug
  • Impossible to operate

The challenge is to welcome the voices of the real users, that are unable to contribute with code to the software. And to give the ability to the contributors to become proxy for real users of the product, so they could improve the conversations they have on the problem they are trying to solve and on the implementation strategy to solve those problems. That’s where the role of the contributors that are working for companies are especially important because their users, customers, partners are the real users of the software, and they need to be the proxy voices of those users.

And this could change the way we are envisioning the open source model. It’s not only solo engineer work…

 

In 1986, Takeuchi and Nonaka studied the teams that were building highly successful products that were disrupting existing well installed product on the market. Their study, published in the Harvard Business Review, is titled The New New Product Development Game.

In the new new product development game Takeuchi and Nonaka studied the reason that make teams to build products that were able to take all the market because those products were really better than the others.

What those teams that built disruptive products had in common?

According to the article (not a long one, you should read it), here are some of the important aspects:

  1. Built-in instability: Broad goal, Strategic importance, Challenging requirement, Funding and Freedom
  2. Self-organizing project teams: Autonomy, Self-Transcendance, Cross Fertilization
  3. Overlapping development phases: It’s not a relay team, it’s a rugby team (yes, they used the term SCRUM for the first time referring to a team, and that’s  what inspired others to create an agile methodology with this same word). Each team member feels responsible for – and is able to work on – any aspect of the project. Cross functional teams, Small teams (under 12 people to enable direct communication), End to end responsible to deliver
  4. “Multilearning”: Multilevel learning, Multifunctional learning
  5. Subtle control: Selecting the right people, Creating an open work environment, Encouraging team members to go to the field, Establishing an evaluation and reward system based on group performance, Managing the differences in rhythm, Tolerating and anticipating mistakes, Encouraging suppliers to become self-organizing
  6. Organizational transfer of learning

 

So if I go back to the challenge that is to welcome the voices of the real users, that are unable to contribute with code to the software.

And to give the ability to the contributors to become proxy for real users of the product, so they could improve the conversations they have on the problem they are trying to solve and on the implementation strategy to solve those problems.

One solo engineer, in charge of one technical component, will not be able to listen to the real user voices to fix problems that are more complex than those solved by one individual technical component. And the real user will not necessarily be able, or willing to assemble the components by themselves.

The classic way to organize the contributors by grouping them in technological area that make a technical sense, limits the ability for the technology to solve needs that cross the technology groups.

 

One diverse cross-functional team, responsible end to end of the delivery of the software, could welcome the real user voices. And could solve more complex problems, cross technology problems, than those solve by one technical component.

How diverse? How cross-functional? What end to end will really means in a specific context?

Let’s imagine that we answered those questions in one specific context.

This diverse team will work together to reduce the feedback loop so they can listen to their users. That is the try – learn – modify aspect of the model that Jim was referring to during the morning keynote.

There’s several aspects, The first one is being able to listen to the real user voices (and not to mock them, or to prove them wrong).

That means that your product managers, or your product owners are member of the team. And that’s probably in this area that there’s a lot of differences between “standard” agile practices and what open source projects are doing. This is probably the area where we could import and adapt a lot of practices that will help to understand what and why a user want something.

That means also that we will benefit from having team members that will be in direct contact with customers from time to time… on the field…

The second one is to improve the whole production work flow in order to be able to deliver a new release of the software, so the user could test the idea, and give feedback, and so on…

That’s challenging when you want at the same time, to deliver new features and to offer a long term support.

That’s challenging when a large part of the production work flow is shared upstream with other contributors, that could come from other companies.

We need at this point to recognize that improvement downstream will be meaningless if we are not solving the problems upstream.

And that could prevent us to deliver the value to our users as often as we could need to.

And maybe that’s challenging because we need new features to become available in an existing software continuously, and we don’t need new release with painful updates and upgrades.

This last aspect demonstrates why the end to end responsibility needs to include important aspect for user like install, update, upgrade, debug, operation, and that those aspects should not be delegated to another team.

This last aspect shows how the architecture of the product is impacting the potential value we could deliver.

So far, we covered 3 aspects, what features and why the user need those features, how we are building the product, how the feature are implemented.

On all those aspects we need to reach a shared understanding and agree that we will try-learn-modify on each of those aspects.

redhatagiledayOn those 3 aspects that could be formulated as value, people and process and technology.

On the understanding the value, practices like story mapping, impact mapping, backlog refinement, could be highly valuable.

On the people and process part: Retrospective is the first one that came to mind, value stream mapping, constraint theory are directly following as they will help to bring this systemic sense that is absolutely needed.

On the technology part, I will just reinforce the need for a really modular technology, and the need to formalize the architecture principles accordingly to the business objectives and to understand the tight connection between those two.

On all those aspects, there’s a lot of agile practices that could be (and are) used in open source projects (I don’t mean a specific framework, I mean specific practices to solve specific problems that fit the distributed organization of open source projects. That means also that a lost of experienced agile practitioners could bring a lot of value in the Open Source world (we need you and we are hiring 😉 ).

What I understood is not what you understood, and that’s not because one of us is wrong.

It’s not a solo work, and it’s important to invest in a shared understanding as a diverse team to be able to tackle more complex problems faster.

The three aspects need to be taken care of independently:

  • You need to invest time to understand the value, the benefit for users, as a diverse team.
  • You need to challenge the implementation of the ideas that will bring this value to users as a diverse team.
  • You need to reflect on your organization and processes as a diverse team.

The 3 aspects are influencing each other.

We tend to think that the value will directly be represented in the technology, and to forget that the 3 aspects will influence each others.

If we have a fixed waterfall release schedule, we will have a big planning session upfront, people will tend to force all their ideas in it in the hope that they will get out of the process at the end.

If we have a siloed organization with a lot of hands off, that will have an impact on the value you can deliver with the technology.

If we defined in your value that there’s a need for non disruptive upgrades, that will have a huge impact on our ability to use a better / newer technology to solve our problems.

 

To come back to the question I asked before: How diverse, how cross-functional and how end to end the team should be?

I would say that the answer is as much as we can, because it will have an impact on our understanding of the value we could bring to user, our structure will define the structure of the technology, and the way it could evolve in the future.

The open source way continues to evolve, cross-fertilization with agile practices benefits to both.

 

The header picture is from Jason Hibbets (CC BY-SA 4.0)

Contribute to the Success of OpenStack

During the OpenStack Summit in Austin, Mark McLoughlin and I delivered a talk titled: “Contribute to the Success of OpenStack”.

Our talk was meant to explain how we were inspired by agile values and principles to improve our internal organization, and how we thought it could impact our ability to contribute more effectively to the OpenStack project.

One of the idea that is often used to describe the way companies are contributing to open source project is that you need at some point to wear your company hat to represent what your company needs, and some times you need to wear your upstream hat to represent what the project needs. We speak some time of the need to balance between upstream and downstream.

Our point was to say that this idea represents the reality perfectly well in projects were the developers are the users of the projects. In this case they are solving problems they are facing on a regular basis.

The OpenStack project is more complex in this sense that the developers are rarely the main users of the project. They don’t have to operate a large scale cloud on a day to day basis.

So, to be able to understand the needs, and to propose effective solutions, the developers of the project need to hear from the real users. That’s were they need to wear at the same time their corporate and upstream hats, because the customers and partners of their company represents the needs of the real users, and wearing those hats they are bringing a lot of value to the project by proxying the real users.

We also explored the fact that when the reaction toward one of the idea that we were bringing on the table was really hostile, there was probably good reason for that, and that was great value for our company that the project was bringing to us. This obvioulsy can only be achieved when the maturity of the project is high enough, especially on the corporate diversity aspect.

We covered after that how we were organizing the teams that are contributing to OpenStack by giving them a clear focus to solve some real user’s needs, and end to end responibility to solve this. Those teams are primary responsible for contributing to some of the components, but the components are not driving the structure of the organization.

For each team, we want the team members to understand their mission, their goals, and to drive their contribution in the value flow.

Here is the recording of the session:

 

For the next Summit in Barcelona, I proposed 3 talks:

  • The first one with Maria Bracho: “Providing Tooling for Effective Collaboration”
  • The second one with Nick Barcet: “Does your voice count in OpenStack? Yes!” this one could be consider as a followup of the talk given this spring
  • The third one: “Raising the awareness on diversity”, one workshop during the last summit was an eye opener for me, and I would like to continue the effort to raise the awarness on that topic.

You can vote on your preferred presentation here: https://www.openstack.org/summit/barcelona-2016/vote-for-speakers

If you want to vote for the one I submitted search  for my name: monville 🙂

Thanks!

 

Header photo by William White

Beyond Measure

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

And it starts with:

Beyond-MeasuresTrust

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

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

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

Social capital

Margaret introduce the notion of social capital with:

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

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

Interruptions

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

Rest

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

Leadership

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

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

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

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

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

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

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

Margaret-Heffernan-TED-Talks

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

Let us code!

I started this article a long time ago. And that’s a comment from a person I work with that triggered the sense of urgency to contribute to solve this problem. He said:

Stop interrupting us! Let us code!

I became sensitive to interruptions when I discovered the Pomodoro method, subject that I covered in this article.

I experimented that, when I was able to focus on one thing, I was extremely efficient. Though, I tried to influence people in teams I worked with to preserve periods of time without interruption.

People easily identify others as interruption sources. It is usually something easy to cover with a team to find agreements to stop the interruption flows and stop the downside of them.

It’s more difficult to admit that we are our own source of interruption. We start something, get caught by a notification, our mind wanders and takes us somewhere else… We need a strong commitment to resist to the multiple temptations to quit what we are doing for something else.

The problems became major with a distributed team.

With colocated teams, I experimented 2 strategies:

  • The first one is to adopt a sign on the desk meaning that the person wish not to be interrupted (a funny puppet for example)
  • The second is to synchronize the team on the same schedule: 50 minutes of work without interruption, 10 minutes break, 15 minutes for interruptions, and so on, with a bigger break for lunch.

Synchronization is the most efficient strategy, but it’s also the most demanding one for team members.

With a distributed team, the connection is established through electronic communication means. You can observe some tacit agreement that you need to answer fast to solicitations by email, and faster to solicitations on chat rooms (irc, jabber, slack or others).

If you agree with that, you can spend your whole day jumping from one subject to another without really accomplish something.

LarryKim-MultitaskingThe illustration on the right is coming from Larry Kim’s article multitasking is lilling your brain and it explains quite well the situation.

Our overall satisfaction will suffer from those constant context switch. Furthermore, each time we will try to go back to a task, it’s highly probable that we will need a lot of time to re-gain the level of understanding of the problem we had when we left this task.

MikeCohn-ContextSwitchingIn his book Succeeding With Agile, Mike Cohn quotes the study from Kim Clark and Steven Wheelwright on the impact of multitasking on productivity that are shown on the graphic above.

In an organization where the work is distributed by managers and where the managers convey the pressure of instant response, the time wasted by permanent asks will paralyze the whole organization. This is why some small teams of 10 can achieve more than teams of 300 letting bigger organizations questioning themselves.

The phenomenon will be less important in an organization where the work is distributed by the system, an organization in which each team member knows what he/she needs to take after a completed task.

group-chat

Funny synchronicity, Jason Fried published an article on the same subject on Medium when I was writing this one. He suggests some ways to change the agreement on the use of communication tools that are important.

My recommendation would be to invest some time with the team to refine:

  • the use of communication tools: what needs to be covered by email, by instant messaging, on chat room, or what needs to be covered with share documents that will help to build a common position. In each case we need to define what are the agreed reaction delay
  • the way to protect each individual from interruptions: by accepting unavailability period, by synchronizing the whole team on the same schedule (more difficult if you are on several timezone), by dedicating people for a period of time to handle interruptions that we cannot avoid
  • to play a game to understand the power of focus (like the name game)

And about you, what are your strategies to let the people that are working with you to do their work?

 

Header picture is from Ryan McGuire.

 

 

 

The Five Dysfunctions of A Team

“If you can get all the people of an organization  rowing in the same direction you can dominate any industry on any market against any competition at any time.”

When the author use this quote from a friend in front of executives, they are all nodding, not only to express their approbation, but to express their inability to make it happen.

TheFiveDysfunctionsOfATeamSuccess comes to those who are able to overcome the human bias that undermine the teamwork.

The five dysfunctions of a team is a book by Patrick Lencioni (not a new one, but it’s often useful to re-read some “classics”). This book use a novel at the beginning to make easier to understand the ideas that are further reexplain at the end.

The five dysfunctions can’t be treated in isolation, the first one is the foundation of the next and so on.

TheFiveDysfunctionsOfATeam-2The five dysfunctions are, according to the author:

  • Absence of trust: unwilling to be vulnerable within the group
  • Fear of conflict: seeking artificial harmony over constructive passionate debate
  • Lack of commitment: feigning buy-in for group decisions creates ambiguity throughout the organization
  • Avoidance of accountability: ducking the responsibility to call peers on counterproductive behavior which sets low standards
  • Inattention to results: focusing on personal success, status and ego before team success

The author suggest tools to resolve each of the five dysfunctions. It’s probably there that the age of the book is visible as some of the tools had been overpass by others more recent and more effective.

Nevertheless, the model proposed by the book is useful to help a team understand what they will need to achieve to become an efficient team.

A book to recommend to many 🙂

You will also appreciate Rafael‘s review on goodreads (and all the others that will motivate you to read (or re-read) some books.

Header picture is from Adam Przewoski.

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.

 

 

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: