Tag: agile

The Great Dinner Party

The Great Dinner Party

You are hosting a dinner party in 8 weeks from now, and you wonder how to make it a great dinner party for you and your guests.

First, what is the meaning of “great” for you in that context? If the party is a success what will happen? The answer could be: the guests will be relaxed, they will enjoy tasty and original food and drink while making or renewing connections with people from various backgrounds.

Answering that first question define the vision that you have of your party. How will you measure that it has been a success? It is a dinner party, so surveying your guests after the reception is probably not a viable option, maybe you could try to remember what your guest will say about it, or perhaps you will receive “thank you” cards. Yes in this exercise, you remember the future! What will your guests say or write after the party if it’s success? They could state that they felt welcomed, that they enjoyed the food, that it was a pleasure for all senses. They could elaborate on the decoration, and specific small attention to details, on the relationship they built or renewed during the event.

Imagining, how your guests will remember the event will help you to empathize in advance with each of your guests, and refine your success criteria. It will help you to remember who has specific needs, or to remember to ask in the case that you realize that you don’t know enough about some of your guests.

Of course, you understand that the dinner party is a pretext to learn how to work on delivering any products or services. The product owner would probably indeed conduct and survey “users” to understand what are their success criteria. Empathy map could help to get what they see, hear, smell, feel, taste, say, think.

Now, that you have a refined vision and have a better understanding of your success criteria, what needs to come next? There are only seven weeks left. What is your backlog?

Your backlog is not a list of activities or a list of things to do. Each item of your backlog is a story in which the personas (your guests or yourself) are the hero.

To define the backlog, you will use your vision and imagine what your guests will experience from beginning to end. It is convenient to use post-it notes for this exercise and to record one story per note. You are building a map (a story map) of their experience.

Let’s try to capture some of the stories from a guest perspective!
– As a guest, I receive a formal invitation to the party, so I know about the specific details,
– I know how to dress, and what to bring,
– I know how to get there and where to park, so I am relaxed and confident,
– I switch in a party mindset from the moment I arrive,
– I know where to sit,
– I enjoy a variety of delicious appetizers, and I can choose and adjust the quantity I eat according to my preferences,
– I appreciate the pairing of the drinks and food.

And we can imagine a lot more of those stories. We will keep some of those, while we will just ignore, delete, rewrite or put at the bottom of the backlog others.

If we look at the first one about the invitation, we can define the conditions of satisfaction for the card. What are those details? Why are you organizing the party? Where? When? Does the guest need to reply? Can the guest come with someone else?

You can already see that a story card is a way to capture the conversation that will clarify it. The conditions of satisfaction are a way to carry the details and to ensure that the solution we will choose, will satisfy the story. At this stage, we know why we want this story, we know what it is, but we still don’t know how to realize it. Is the invitation printed and mailed? Is the invitation sent via email? Is it texted?

This distinction between why and how is crucial to enable creativity and innovation. Let’s illustrate that with another example. Let’s imagine now that as a host you want to delegate the realization of this story to a team:
– I want a sweet and original dessert with season fruit, so my guests can finish the meal on a sweet note.
When the team clarified the story with the host, the team learned that individual portions are a must, different textures are essential, and so team presented the results of their work during the demo of that week: a strawberry rhubarb meringue tartlet. Yes, me too, now I want one 😉 As a host, you tasted the tartlet, loved it, asked for slightly smaller size. So now, the team just need to get ready to prepare the tartlets for the event. On that day, the team is not able to find the fresh strawberry that will compensate the acidity of the rhubarb. The team tastes raspberry that appears to be delicious, and so as it will still satisfy the conditions of satisfaction, the team can make the decision. Remember, the dinner party is a pretext to learn, the primary point here is by knowing “why” we are doing something we can adjust the “how” to the circumstances and find more creative solutions.

If we look back at this dessert story, during the grooming of the backlog, we first decided to conduct a spike for one sprint, demoed it to the user, and got some feedback. Then, during planning, we were able to decompose that story into more specific tasks that the team will do to realize the story. And we have been able to adjust to the circumstances by switching to raspberry at the last minute.

Grooming your backlog at the “story” level, and then planning for the sprint and decomposing into tasks only when you will work on a story is a compelling approach.

Let’s recap the approach. We started with a high-level vision. We refined the concept by identifying the different personas and empathize with each of them from the beginning to the end of their involvement in the project. In our case, we probably have the host, the host family members, the guests, the children of the guest.

We captured the stories for all the personas in our backlog. We refined and sorted the stories during grooming sessions. The conversations enabled us to define the conditions of satisfaction for the stories at the top of our backlog.

We continued our work during our weekly sprints, starting with a planning session, in which we checked our understanding of each story, decomposed into tasks if it was possible, or choose to conduct an experiment or a spike in the case of more significant uncertainty or our ability to meet the conditions of satisfaction.

We reviewed and demoed our work at the end of the sprint. We welcomed the feedback and adjusted our plans accordingly.

We now need to invest some time in a retrospective to improve our way of working as a team, so we will be more efficient and enjoy the weeks to come approaching the great dinner party.

What do you think about using a dinner party to explain practices?

I am refining the use of this analogy, among others, in the book to come during Spring 2018, Changing Your Team From The Inside. I am looking for reviewers, let me know if you would be interested.

 

 

The header picture is our Thanksgiving table created by my spouse Isabel 🙂

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.

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:

Manage it!

Manage it!

Manage it! is a book by Johanna Rothman published by Pragmatic Programmers. You probably know already Pragmatic Programmers, they published Agile Retrospectives by Esther Derby and Diana Larsen, and also Agile Coaching by Rachel Davies and Liz Sedley that my friend Fabrice Aimetti translated into French. If don’t know Pragmatic Programmers yet, I recommend a visit to their book shelf.

When I started the book, I have been surprised, badly, by the classic project management tone, and at the end, it is something I really appreciate in this book. Why ? Because it means that you can recommend this book to project managers and managers that are used to classic methodologies and classic work environments. And they will not think that you are trying to enrolled them into a sect.

Well, this book will not cover principles and values that make the culture of an organization, principles and values that can be reinforced or hustled during an agile adoption.

This book covers project management, as seen by project managers, program managers or managers, sometime as seen by team members. It covers the start of a project, the planning, life cycles, scheduling and scheduling games, estimation, creation of teams, steering, rhythm, meetings, dashboards, multisite projects, multiple projects, test integration, programs and portfolios, and of course project completion. With this short view of all the chapters, you can see what you can expect from this book. Recommendations are simple to understand, and argumentation could be useful to enrich your existing range.

I really like the way powerful questions were introduced, like :

  • What does success look like ?
  • Why are these results desirable ?
  • What is the solution worth to you ?
  • What problems does this system solve ?
  • What problems could this system create ?

I appreciate also the recommendation to introduce retrospectives in the project life cycles (and the way to insit not to call this a postmortem at the end, cause we hope that nobody will die during the project).

This book can be read fast (I read it in the plane on my way back from Red Hat Tech Exchange) and I believe that it can be a useful reference when you are ready to start a new project and to work on an existing one.

Agile France et Le Bonheur au Travail

Agile France et Le Bonheur au Travail

J’ai eu le plaisir de donner une confĂ©rence sur le bonheur lors de l’Ă©dition 2015 de la confĂ©rence Agile France Ă  Paris. Il s’agissait d’une version raccourcie et en français de la keynote que j’avais donnĂ© en ouverture lors des Drupal Developers Days : Happiness is Coming.

J’avais choisi de couper beaucoup de contenu pour pouvoir tenir dans les 25 minutes, et il aurait fallu en couper encore…

Un grand merci pour les feedbacks et les sourires !

ScrumWine #15.2

ScrumWine #15.2

Une nouvelle Ă©dition du ScrumWine s’est dĂ©roulĂ©e le jeudi 4 juin 2015. Nous Ă©tions pour l’occasion accueilli par CDiscount. Je remercie au passage Isabel pour l’organisation et adresse toutes mes fĂ©licitations Ă  Damien Tourette, papa depuis la veille ! Notre hĂŽte, Lionel Richer, expliquait dans son introduction que malgrĂ© une dĂ©couverte rĂ©cente de l’agile, 60 personnes travaillaient Ă  prĂ©sent en agile et que le bĂ©nĂ©fice du rapprochement des mĂ©tiers et des Ă©quipes de dĂ©veloppement Ă©tait remarquable.
Les actualitĂ©s ont permis ensuite de mettre en avant les prochains Ă©vĂ©nements consacrĂ©s Ă  l’agile. Agile France bien sur, programmĂ© pour les 18 et 19 juin, et pour lequel j’aurais le plaisir de donner une version courte et en français de ma confĂ©rence sur le bonheur au travail (Happiness is Coming). ALE 2015 qui se dĂ©roulera cette annĂ©e Ă  Sofia, toujours au cours de la derniĂšre semaine d’aout, Ă©vĂšnement remarquable puisqu’il inclut Ă©poux et enfants, ce qui augmente le niveau d’énergie positive de l’évĂ©nement. Je termine par une mention pour AgileTour Bordeaux qui a annoncĂ© la date de la prochaine Ă©dition pour les 30 et 31 octobre 2015.
Olivier Patou a relevé avec succÚs le challenge de la présentation en 5 minutes avec une présentation sur les histoires utilisateur : Comment faire de bonnes User Stories ?
Le programme proposait ensuite 2 sujets en parallĂšle :
– de l’OODA loop Ă  l’innovation collaborative par Emmanuel Henriot, session qui a reçu un trĂšs bon accueil, et j’ai donc essayĂ© de convaincre Emmanuel de la proposer pour AgileTour Bordeaux, car je n’ai pu y assister
 puisque je proposais aux participants de jouer Ă  :
Lego4Devops, un jeu simulatif utilisant les mĂȘmes boites de Lego que le cĂ©lĂšbre Lego4Scrum et dont j’avais participĂ© Ă  la mise au point lors de la derniĂšre Ă©dition de Agile Games France. La version 1.0 est donc bien jouable sur un temps court, moins de 60 minutes, mais il semble prĂ©fĂ©rable de pouvoir y consacrer plus de temps afin d’ĂȘtre moins pressĂ© pour les explications initiales et avoir l’opportunitĂ© de rĂ©aliser plus d’itĂ©rations. Nous avons eu la possibilitĂ© d’avoir 2 Ă©quipes de 7 joueurs en parallĂšle, ce qui nous a Ă©galement permis d’identifier de nombreuses possibilitĂ©s d’amĂ©lioration. Nous sommes en train de compiler de façon collective ces idĂ©es d’amĂ©lioration afin de les proposer pour une prochaine version. Merci Ă  Christophe HĂ©ral pour avoir contribuĂ© Ă  la facilitation du jeu, et bien sur merci Ă  tous les participants !
Rejoignez le groupe pour poursuivre la conversation et construire la prochaine Ă©dition :
https://groups.google.com/forum/#!forum/sug-bordeaux

2015-06-04 18.26.30Et merci à Emma pour son aide 🙂

Don’t change my mindset, I am not that open

Don’t change my mindset, I am not that open

Nick Barcet and I were schedule for the last talk session of the Openstack Summit in Vancouver (Of course, design sessions will continue on Friday).
When we submitted the proposal for this session we were looking for a way to help our co-contributors to the openstack project.
The way we think it can be the more helpful was to share our way of working together to foster change in the organizations of the customers we work with.

The recording of our session has already been published by the Openstack Foundation, and is available here:

Our slides are available there:

Your feedbacks are welcome to continue the conversation!

Bridges and Hierarchy

Bridges and Hierarchy

Mark McLoughlin delivered the Red Hat Keynote, on the morning of the second day of the Openstack Summit in Vancouver.

During the afternoon, he delivered a more intimate talk about the governance of the Openstack project.
The main idea is that, the new Big Tent organization model will allow the emergence of new projects, and it can be the time to redefine the main values that will help the project contributors to take the good decisions.

Mark started his talk refering to the Keynote Eben Moglen gave in Auckland at LCA 2015. In this keynote, Eben Moglen explained that the hierarchical organization model that we all know very well, is the model of the 20th century, and that the organization of the 21st century will be based on transparency, participation and non-hierarchical collaboration, like it is in free software.

Mark continued his introduction with a reference to Andy Hunt’s blog post, The Failure of Agile. Andy Hunt is one of the original writer of the agile manifesto, so when it came to discuss agile, we can at least consider him seriously. The main point of this article is that a lot of people lot’s the agile way by focusing on a set of practices, forgeting the agile values and principles. They are focused on doing agile, and they forgot that depending on your experience, if your are a beginer in a practice, you need clear directives to learn how things work, and more and more your skills are developing you will need coaching on the go, and then you will need some support, and then you will be fully autonomous and during this journey you will have adapted the initial set of practices living the agile values and principles.

That reminds me the stickers I had printed for an agile conference:
sticker-agile-tour-2013-v2
When I recieved the stikers at this point, I was thinking… humm I should have crossed also “be” and put “learn” instead… because this is really what we are doing here…

So Mark proposed those 4 high level ideas that can become the high level principles we can refer to as an Openstack contributor :

diverse interests, but a shared vision, based on consensus
individuals and interactions over processes and tools
leadership through empowerment, empathy and trust
every advance must ultimately iterate from the bottom up

And I encourage you to watch the talk to understand the details of his proposal.

Happiness is Coming

Happiness is Coming

I had the great pleasure to deliver the opening keynote of April 17, 2015 of the Drupal Developer Days in Montpellier. The selected theme was Happiness…

Here are the slides:

And a selection of tweets:


Thank you for your great feedbacks and for the great conversations that followed!

I feel ready for the next DrupalCon 😉

The DevOps Opportunity

The DevOps Opportunity

Capture d’écran 2015-02-11 Ă  11.01.27In the beginning was the session of John Allspaw and Paul Hammond during the 2009 Velocity Conference, showing how cooperation between Dev and Ops at Flickr allows 10 deployments a day (Header image of this post is extract from this presentation, and it shows how Leonard Nimoy was important for us even if I started this post on February 6th and forget about it after…).
Following that, there was the first DevOpsDays conference in Gent at the end of 2009.
Behind the promise of reconciliation between evolution and stability objectives, reconciliation between devs and ops, some saw technological solutions enabling to shorten the lead time of go lives, and even to go live without human intervention.
Others saw the opportunity to realize the promise of the last 20 years of the agile movement (yes I start to count at the beginning of the discussions about the lightweight project management method and the emergence of XP
 already 20 years
).

Capture d’écran 2015-02-11 Ă  10.58.37

Others questioned the skills that sys admin will need to acquire to be able to consider infrastructure as code.
Others imagined that the devs will need to change and acquire a good understanding of the behavior of their code in production, that they must integrate exploitation constraints into their code, like the ability for their apps to react to failure, to scale in or scale out, the ability to update or upgrade without services interruption…
Others thought that the change should be from the entire system, that we need to reconsider the way we envision software evolution, and information system evolution, looking at it feature by feature – using not only the idea of Minimal Viable Product (MVP) at the beginning of a project but the idea of Minimal Marketable Feature (MMF) during all the lifecycle of our information systems.
Others thought that cloud technologies was an enabler to our way to envision information systems, and obviously others are working on those technologies to enable those transformations.
Others argued that if they want to recruit new people in their team they need to transform their organization because new generations will not accept the constraints of silos that prevent collaboration.
All those point of views demonstrate the complexity of the devops subject and the impact on different domains in the organization: tools, method, organisation and culture.
It was really interesting to observe the diversity of all those views during the Devops CIO’s breakfast organized by Red Hat in Paris on February 6th, my role was to shed some light on the subject and to facilitate the discussion between participants.
Now that eNovance is part of Red Hat, the challenge to transform organization’s culture (internally and externally) continue with the Red Hat Cloud Innovation Practice and the size effect and open source culture allows exiting discussions with my peers.
Red Hat Cloud Innovation Practice
Contrat Creative Commons
Les articles publiés ici sont mis à disposition selon les termes de la Licence Creative Commons Paternité 3.0 non transcrit.