Category: General

  • Managing Time

    Managing Time

    When I searched for “time management” on google this morning, there were 238,000,000 results. So, we could consider that it’s not necessarily useful to add one more.

    A quick look at the first page of results, and we can already see divergent opinions. From the rigid daily structure to the statement that time management is ruining our life.

    Let’s start with the most important first: why do we want to manage the time we have?

    The common answer is: “To get things done”.

    What are those “things” we want to be done? and why it’s important?

    Because those things contribute to the accomplishment of a greater goal.

    All that sounds really great! So, why do people are saying, from time to time, that they don’t have the time to do what they want?

    As I fall myself into that kind of trap, I can try to list a few potential causes:

    • Knowing what you want and why you want it: if you don’t, the lack of time could be just a nice excuse? Writing down your vision of where you will be in the next 5 to 10 years on the different aspect of your life could be a good exercise.
    • Knowing what is the most important thing right now in order to make it happens: if you don’t, you want something, but you did not do your homework yet in order to make it happen, and so the question you need to answer is: What’s the ONE Thing you can do such that by doing it everything else will be easier or unnecessary?
    • Driving yourself: Maybe your calendar or your inbox are driving what you are doing? If this is the case, you know what is the most important thing, but you are not doing it. One way to solve that could be to block some time, at the beginning of the day for the most important thing, and then only after that, choosing to invest time working on your inbox. Another important one is to empty your calendar, you will not be able to participate in everything and contribute to everything. Choose where your contribution is valuable.
    • Interruptions: multitasking is a myth, and so you want to limit the interruption during the block of time you are working on the most important things. The number of decisions we are able to make in a day is limited, so you don’t want to make decisions at each new notifications, new mail, new message on social media…
    • Care for yourself: you should have a block of time to care for your body, to exercise, to meditate…
    • Invest in social interactions: you are not alone, and you need, as a human being, social interactions, so you probably want to invest in interactions that will have a positive effect on yourself, so you can have a positive effect on others.

    I practiced the Pomodoro Technique in the past, and that definitely helped me to increase my focus on ONE thing at a time, and not to be fooled by my own estimates.

    Maybe something to start with?

     

     

    The header picture is from Ryan McGuire.

  • Team Identity

    Team Identity

    The sense of belonging is an important experience to have. Belonging means that we are accepted as part of, as a member of the group, the team, the company.

    We want to be part of a team because what defines the team identity is appealing to us. The team is defined by its vision and its working agreements.

    When you are building software the open source way, you can identify 3 main categories of team identity:

    1. Upstream project
    2. Downstream product
    3. Jobs to be done

    1- Upstream project

    The team members belong first to the upstream project. They will tend to prioritize what they think is the best for the upstream project. They will be progressively disconnected from the people that are using the technology they build. They could even miss new needs and be surprised that people switch to another technology that is not so different/better/other qualifiers…

    2- Downstream product

    The team members belong first to the product they build. They will tend to prioritize what they think is the best for the product. They will tend to forget that building the open source way is a great way to understand why people want to use the technology by confronting your point of view and requirements with those of the other members of the community. The extreme is that they will end up being alone, and disrupted by another product.

    3- Jobs to be done

    The Jobs to be done theory has been described by Christensen and his colleagues. I wrote an article about one of his book: How to measure our life and I will probably write another one about Competing Against Luck.

    In short, the Jobs to be done theory explains why people are making choices, hiring or firing a product or service, by focusing on the understanding of the jobs, the problem they are trying to solve.

    The teams that identify themselves to the jobs to be done are stronger because they can work on technologies in the open, curate technologies that they need, invest in new technologies that could replace their current core technologies, without losing their identity. They can envision their solution as a sole product, or integrated into other products knowing that the most important thing is the jobs to be done. They can partner with other knowing precisely what they are partnering on without feeling that they could lose/win something in the partnership. They can focus on their users and solve a specific problem, a specific “jobs to be done” without the temptation to expand the scope of what they are doing.

    I guess that the jobs to be done should be the first thing you want a team to agree upon.

    Thoughts? Please comment, tweet, email…

     

     

     

    The header picture is from Ryan McGuire.

  • Town Hall Meeting

    Town Hall Meeting

    The term Town Hall Meeting is often used inside a company to characterize a meeting organized by a highly ranked executive and gathering a large part of the company employees, or even all of them.

    Usually, the meeting is meant to give a short status on what the executives are working on for the future of the company and to answer some of the burning questions that have been heard in the hall way. Some of those questions have not been heard directly by the executives, but have been reported to them by some people. I have used two times the word “some” in the last sentence to give a sense of fuzziness, and uncertainty of what are the real concerns of people.

    Let’s imagine that you are this executive, you have organized the meeting, you are ready for your speech, everybody is there. So now, you delivered your speech and you are ready for questions.

    And, there’s no question.

    Or, if there are questions, there are pushed by some manager, that want you to repeat what you already said, something that will reinforce their own beliefs, or positions.

    In your speech, you have even gone further than what was planned to be said with your management team, and you have said that.

    But still, there’s no question.

    And, you know that there are unspoken questions. But the time is over, and there’s no way to know what are the real questions.

    What is the problem?

    Maybe the problem lies in the format itself. The Town Hall is not giving the sense to people that they can contribute to the thinking, that they can disagree. The Town Hall presents yourself in a position of power, with the authority to say yes or no.

    Now, let’s say that you are a participant of the Town Hall Meeting.

    At some point during the speech, you had one question. It was not really a question, in reality, it was more a slight disagreement. Maybe you wanted a clarification.

    During the course of the speech, you have seen that effect reproduced 2 or 3 times. But that was not the time for questions.

    And when the time for questions came, you cannot find a way to formulate all this in a meaningful way.

    You even heard some of your coworkers said at the end of the meeting: “I bite my tongue because I really not agree with what Mr. Z said on this topic”.

    Another option?

    Maybe, If we want more interactions, if we want people to ask for clarifications when it’s time to do that, we need to use another format of meetings.

    One of those formats could be a Fish Bowl.

    In a fish bowl, the executive will not be alone in the center, so he can be joined in the fishbowl by some people in his or her management team. And it’s a moderated conversation, so topics can flow more freely from one or the other.

    In addition, there’s an empty chair in the middle, and any person in the audience can sit on that chair to join the conversation at any time. When this occurs, an existing member of the fishbowl must leave the fishbowl and free a chair.

    This way the clarifications questions and the slight disagreement could be covered at the moment they arise, and more questions and concerns can be covered.

    Are you ready to try this?

     

     

     

    The header picture is from Ryan McGuire.

  • Why Transformation Efforts Fail?

    Why Transformation Efforts Fail?

    Thanks to a push email from Harvard Business Review, and discussions around ongoing transformation efforts, I read again an old article from John Kotter: Leading Change: Why Transformation Efforts Fail.

    The first lesson is that change is not an event, it’s a process. The second lesson is that change takes time, and not following the change process could create an illusion of speed, but will result in failure.

    If we study successful or unsuccessful changes attempt using the 8 steps proposed by Kotter, we could learn a lot on what we could improve in the future.

    One aspect that is not directly covered in the 8 steps is what is called “Your organization”.

    I learned from successful (and unsuccessful) changes, that defining “The Organization” is crucial. It will define who is part of the core group, and more importantly, who is part of the core group from the start.

    Let’s say that in your organization, you have several teams that need to work together to deliver a product or a service, and you observe that they are struggling to deliver, they could even engage in politics and blame game.

    If you engage with team A and team B. That could be, for example, because they are at the beginning of the production process, or for other reason, as you will always find great justification for what you did and cannot undo. I am smiling there, at myself, please don’t be offended.

    You could work with those teams on step 1, and establish a sense of urgency. You could work on step 2, and form a group that will lead the change.

    Now that you learned more on the production process, you can clearly see that team C, plays a crucial role, and needs to be involved.

    As you are yourself driven by the sense of urgency, you could decide to involve team C for step 3. You could rationalize this shortcut as much as you can, but it will cause you a lot of troubles.

    The best option is to go back to step 1, and work with team A, B, and C on establishing a sense of urgency, and continue the process from there. Until that restart, Team C will not see the same crises or potential crises, they will not see the same causes, and they will not want their future to be dictated by other teams.

     

    The header picture is from Ryan McGuire.

  • Fight Club Retrospective

    Fight Club Retrospective

    You probably remember the first 2 rules of Fight Club, right?

    Let’s review the rules:

    “Welcome to Fight Club. The first rule of Fight Club is: you do not talk about Fight Club. The second rule of Fight Club is: you DO NOT talk about Fight Club! Third rule of Fight Club: if someone yells “stop!”, goes limp, or taps out, the fight is over. Fourth rule: only two guys to a fight. Fifth rule: one fight at a time, fellas. Sixth rule: the fights are bare knuckle. No shirt, no shoes, no weapons. Seventh rule: fights will go on as long as they have to. And the eighth and final rule: if this is your first time at Fight Club, you have to fight.”

    ― Chuck Palahniuk, Fight Club

    Let’s now define what a retrospective is. A retrospective, is a specific session, in which a team reflects on what happened during the previous iteration. This reflection will lead the team to decisions, either to reinforce positive behaviors, or to invest time to improve what is preventing the members to achieve their goals.

    There’s a lot of ways to facilitate retrospective, you could go here and there to find out more.

    Isabel, my amazing wife, had the idea to create an “all-in-one” retrospective plan based on the Fight Club rules. You will learn more about this plan in her book to come.

    In the meantime, I would like to present how I used the idea to foster productive conversations in a team that is scared of conflict. This is the second of the 5 dysfunctions of a team.

    Maybe you think that using fight is too violent in the workplace. And at the same time, what happens in us, during a discussion could be felt as fight.

     

    The meeting will start with the explanation of the goal, and how the Fight Club rules are transposed in our work environment.

    The first 2 rules are useful, because, as stated by a manager in the team, the children don’t want to hear that “mum and dad are fighting”. I could argue that this statement in itself says a lot about the current state of trust in the organization, and that in an effective organization, the manager will probably not consider himself or herself as the parent of the team members. If we put that aside, the first 2 rules are useful to create a secured space in which conflicts are allowed, and nobody knows that we could have conflict in this team.

    So we are saying there, that during this specific meeting, we will not seek artificial harmony, we will accept to start the conversation on topics that we are not in agreement (yet).

    Third rule, we need to be able to stop the conversation. Fourth rule, only two people involved, everybody fighting at the same time against one is not a smart idea, right?

    Fifth rule: one fight at a time. Let’s not mix all the topics in the conversation.

    Sixth rule: no protection and no weapon. Is referring to your boss a weapon? Let’s discuss what it means for the team.

    Seventh rule: … as long as they have too… We need the conversation to end with a decision.

    Eighth rule: first timer have to speak up. In fact, every team member will have to bring a topic on the table.

     

    What is missing there, is a way to bring topics that is non judgmental. So we could have a productive conversation. Isabel proposed to use Non Violent Communication, to encourage people to observe, express their feelings (and not their thoughts), to express their unsatisfied needs, and their requests.

     

    This explanation of the 4 part of the NVC process could help 🙂

     

  • How to measure our life?

    How to measure our life?

    A colleague recommended me to look at the work of Clayton Christensen. This is an article to encourage you to do the same.

    We are living in a nested system. In the world, there are nations, and in nations, there are corporations. In corporations, there are business unit, in which there are teams. And in teams, there are individuals, and individual there are brains…

    The way we are looking at the world because our brains need to simplify things to understand those, is mainly by using causal effect. Something happens, because of some characteristics.

    And Often, there’s in fact a correlation between the characteristic and the effect we are looking at, people who are buying a newspaper for example, but that’s not the cause.

    The cause is that there’s a job to be done, and people will hire a newspaper to do that job.

    The job to be done is the cause that will drive the behavior of people, teams, business unit, corporations, and nations.

    If you understand the job to be done, and you are selling to big people at high margin, you will sooner or later face the disruption, of people that could deliver the job to be done, to small people at low margin… (and that will then come to the big people that will not pay you anymore). The disruptors are not competing against you at the beginning, they are competing against non consumption by making an affordable product.

    The problem we will face is how we will measure success. If our way to measure success leads to short term profitability decision, that will kill long term success.

    For corporations, that could be when you are measuring return on net assets for example, and that you are taking the easy way of outsourcing to reduce the assets, instead of finding ways to increase the return.

    For individuals, that could be to mobilize all energy on work, because we could measure success with the money we earn, or the position on a corporate ladder, and as a consequence losing family and friends.

    The way we will choose to measure our life, will have a consequence on the long term.

    What is the impact of our actions on people?

     

     

    Header photo by Olu Eletu.

  • How to start when managers are stuck in uncertainty and fear

    How to start when managers are stuck in uncertainty and fear

    How to start when managers are stuck in uncertainty and fea? That was the question I asked to my peers that participate to the Happy Melly Coffee.

    This was the first day I was able to participate to the Happy Melly Coffee since when I moved to Boston.

    Uncertainty and Fear were the main questions.

    Unfortunately, I was forced to leave the building, and to loose the Internet access after a few minutes.

    The good thing is that my peers continue to discuss the topic, and the recording is available just above 😉 THANK YOU!

    This could inspire you to participate in a future coffee, the Trello Board with the questions is there.

    The previous recordings are there.

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

    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)

  • Autobiography

    Autobiography

    25 years ago, a friend told me that I should read the autobiographies of famous people to understand how they found their way to achieving great success.

    I did not understand this advice. I didn’t appreciate the difference between autobiographies and cheap magazines that followed the life of the “rich and famous.”

    I was wrong.

    After I read Benjamin Franklin’s autobiography, I understood this advice. I have to admit that it was with quite a considerable delay until I discovered why it was so exciting to read books about people who had written their life stories on their own.

    Autobiographers share what they learned from their journeys and life experiences, with the hope that it will inspire and help their readers. There’s probably some ego involved in the writing process, and when you read an autobiography, you may need to deal with that, with a gentle smile on your face: yes, sometimes what we do could be ego-driven.

    Reading a story makes it easy to identify yourself in similar situations.

    These are some of the things I wished I had discovered earlier:

    • how Benjamin Franklin designed a system to create good habits (based on a calendar where you mark your success which helps you reflect on what needs more focus or improvement),

    • how he discovered the ideal size of a group for a meaningful conversation (the answer is a maximum of 12 people), and

    • how he refused patents for one of his inventions because it was for “the good of the people.”

    More importantly, what I learned from reading his autobiography was that he worked on himself first, and this work on himself had an impact on the world.

  • Contribute to the Success of OpenStack

    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

  • Happy or not?

    Happy or not?

    Tracking the mood of the team is something that agile practitioners are doing for quite a long time. For example, in 2006, Akinori Sakata, explained in this article the use of Niko-niko calendar.

    The idea is to tighten the feedback loop, and to detect problems even before they become really conscious to an individual, or to the team.

    By exploring how we feel at the end of the day, it helps us to take a step back, and sometime to express what is not going well from our point of view.

    So, I used it for teams, co-localized or distributed, for quite some time. The tooling is really simple if you only want to deal with the mood of one team.

    At some point, I wanted to expand this to track the mood of an entire company, so we could be able to get more feedback, and to adapt what we were doing.

    I had a look at what was on the market, and at this time, hppy.com provided a tool to allow a quick feedback using a smiley ( 🙂 😐 🙁 ) and to leave a short text message associated to that.

    There’s now a lot of tools on the market that are exploring employee engagement, like Niko-Niko or Happify.

    Is it a tooling problem?

    Obviously the quality of the tool you will use, will have an impact on your ability to run analysis, or to scale the mood measurement, but my take after several experiments is that it’s not a tooling problem.

    It’s how you will take into account the feedback and act accordingly.

     

     

    You could also be interested in this article Manage Your Emotional Culture published in the Harvard Business Review at the beginning of the year.

     

     

     

  • Sequence vs Priority

    Sequence vs Priority

    There’s sometimes conversations within teams about the responsibility of prioritization of backlog items.

    The problems is the end result of this conversation. Whoever could have this responsibility, that could be the Product Owner or that could be an agreement within the team, the results will look like:

    • 80% of the items in priority 1
    • 15% in priority 2
    • 5% in priority 3

    That leads to end-less discussion to find what could be priority 1, 2 or 3, and that’s not really helping to decide by what we need to start the first iteration, and what could be the meaning of it, and what could be the meaning of the next marketing release.

    Near the planned date of the marketing release, people starts to worry about the priority 1 items that could not be included in the release. Suddenly the meaning of priority 1 became “must land in the release”, and people are focused and what will not land, instead of what will land in the release.

    That’s the reason why I am trying to avoid the “priority” word. Instead I am asking in which sequence the items should be delivered. I am interested in the sequence of the items that could be included in the next 2 iterations. What could be the meaning of the iterations, and what could be the meaning of the release for the product and its users. It’s not priority, it’s a sequence.

    Another illustration of sequence versus priority is the way the airlines are boarding their plane. Some of the airline are boarding first the business class and give a “priority” access to frequent flyers. That’s not solving the problem of boarding a plane as fast as possible. During my last visit in Austin, I have seen that Southwest Airline, organize the boarding in sequence with indicators inside the boarding terminal. This is a better attempt to fix the system.

    That means that we need a tool that is able to record that sequence. A wall with post-its can do that. Most of the task/project tracker are not able to do that.

     

    Header picture from Ryan McGuire.