Author: Alexis

Time flies and I wanted to tell you a few things about success

Time flies and I wanted to tell you a few things about success

One of the last chapters of Changing Your Team From The Inside is about success. Specifically about measuring success. In that chapter, I relate how a team started to adopt OKRs. While I was reviewing that chapter, John Doerr published Measure What Matters, and I rushed to read the book as I wanted to check my knowledge with someone who inspired Google and a lot of other companies to use OKRs.

One of the readers of the book told me that I should have started the book by that chapter, and I have to admit that I hesitated to change the order to have the opportunity to figure the quote from Clayton M. Christensen which is coming from How Will You Measure Your Life?

Last month, someone recommended me to read Radical Focus by Christina Wodtke. The book starts with a business novel and goes through the process of defining and using OKRs. This is a very short book that I recommend if you are interested in achieving your goals with your team. I also suggested the book to one book club, and we start the discussion on that book tomorrow! I am eager to hear what are the perspectives of the other readers.

Focus is one of the key factors highlighted by Richard St John in his 3-minute TEDTalk from 2007.

After The top requirement for high-impact teams, and Could your team be managing itself? I published What a Coding Dojo taught me about agile on In the article, I go back to why It’s essential to value individuals and interactions over processes and tools, also known as the first value of the agile manifesto. The article made it to the top 10 this week. Thank you for your support, I really appreciate your comments, likes, and shares!

I want to finish that newsletter with a big thank you to John Poelstra and Lisette Sutherland. I enjoyed the podcasts recorded with them!

As usual, I will be happy to hear from you, please answer to that message, or send me a message on Twitter or LinkedIn. I will be glad to answer your questions or read your feedback.

If a friend sent you this message, you could subscribe to the mailing-list following the link, yes you will have to scroll a little bit.

PS: I will be traveling to Germany, Switzerland, and France starting at the end of the week. I will speak at a meetup organized by the CARA in Lyon on November 12, and at agile conferences: Agile Grenoble on November 14 and 15, and at Agile Rennes on November 23 and 24. Add the sessions to your agenda!

Could your team be managing itself?

Could your team be managing itself?

I was engaged recently in a passionate conversation ignited by a simple comment: “A team has to be managed.” The comment made me think I wasn’t on the same page as my interlocutor.

I was discussing the importance of designing organizational roles that won’t become bottlenecks (roles that won’t prevent the organization from delivering efficiently or to adapting quickly to changes). In classic organization design, we tend to think that designing boxes on an organizational chart and putting great people in charge will solve all our problems. That approach could work in static environments, where what you have to deliver is defined once and for all.

But if your environment is continually changing, you need to adapt your value proposal to those changes. Your organization needs to be adaptable.

My interlocutor was on the path to designing the boxes of a new organization. On his radar were managers that will have full responsibility for certain groups and team leaders with full responsibility of the teams making up those groups. Static groups, static roles, static functions.

But you can’t achieve a capacity for adaptability in your organization if you rely on overloaded people dealing with multiple responsibilities. I suggested an alternative: Self-organizing teams designed around roles that are not bottlenecks, roles that team members could take either full-time or for a portion of their time.

Unfortunately, my interlocutor jumped to the conclusion that my goal was to remove all managers and team leaders from the organization—as if self-organizing teams and management were somehow mutually exclusive.

Not exactly.

Managing the self-organizing team

The Open Organization Definition lists five characteristics as the basic conditions for openness:

  • Transparency
  • Inclusivity
  • Adaptability
  • Collaboration
  • Community

I’ve recently discussed the importance of making work visible when attempting to achieve transparency and collaboration at scale. Here, I’m more concerned with adaptability—creating teams without single points of failure, teams better able to adjust to changing conditions in dynamic environments.

I agree that a team has to be managed, and I think many of the activities we see as the sole responsibility of the managers or the team leaders could, in fact, be delegated directly to the team—or to team members that could effectively deliver the activities serving the team.

So from my perspective, a team has to be managed, but a large part of that management could be done by the team itself, creating a self-managed team.

Let’s review some of those activities:

  • understanding the business and the ecosystem the organization evolves in
  • understanding why we provide solutions, products, features, services and formulate a clear vision
  • defining what needs to be delivered and when it should be delivered
  • determining how it will be architected
  • identifying how it will be implemented
  • defining how it will be documented, demoed, tested
  • distributing the work between the team members
  • delivering the work
  • implementing the documentation, testing
  • presenting the demo
  • collecting the feedback from users and stakeholders
  • ensuring that the result of the work is continuously flowing to the customers or users ensuring that testing is automated and triggered for each and every change
  • improving the way the team is working and increasing its impact and sustainability
  • improving the efficiency of the larger system formed by the different teams
  • supporting customers and partners who use the product
  • fostering collaboration between users, customers, and partners in the defining and implementing the product or service
  • defining the compensation of team members
  • controlling the performance of team members
  • supporting and developing people in the team
  • hiring people

When I look at those activities, I see some that could be delegated to a system put in place by the team itself—like the distribution of work, for example. The distribution of the work can be made obvious for team members by simply making the work visible to everyone.

I also see activities that are difficult to move away from managers, like managing the compensation of team members (because it would require building a compensation system that’s more transparent, which is difficult when you don’t start from scratch due to preexisting discrepancies in the compensation of people).

I see activities that are focused on users and the why and what the team is delivering. On some teams with which I’ve worked, those activities are delegated to a team member taking, for example, the role of User Advocate or Product Owner (to use the Scrum terminology).

I see activities that are focused on how the team is working. Those activities are delegated to a team member taking, for example, the role of Team Catalyst or Scrum Master.

In both cases, their role will be to ensure that the activities are done by the team, not necessarily to handle everything by themselves.

By looking at the activities in more detail, I can envision many of them being handled by team members as part of their current role, or in a new role.

Giving managers or team leaders the ability to consider the activities for which they’re accountable and the activities they can delegate to the team can remove the bottlenecks and single points of failure that currently exist in some organizations.

Which activities in your organization could a self-organized team handle best? What have I left off my list? I’m interested interested in hearing from you.


The post was originally published on on August 14, 2018.

The top requirement for high-impact teams

The top requirement for high-impact teams

What is the top requirement for high-impact teams? When I was recently asked this question, I started making a list.

  • You need to know why you are doing what you are doing, and everyone on the team needs to know what that is.
  • You need to trust the people on the team. Trusting them is connected to personally caring for each member of your team.

Assuming your team has a great purpose and people who trust and care for each other, will that guarantee a high impact? Maybe not.

From my perspective, the one thing that is essential on a high-impact team is for everyone to understand the workflow—from the beginning to the end. And not only to have a clear, shared understanding of all the steps but to have the workflow visible to all team members at all times.

How to make your work visible

If you build software or do other work in the virtual world, it’s not easy to make your workflow visible at each step. Here’s a process I came up with some time ago when working with a team that was in charge of delivering a website for a luxury products company. The expectations for the user experience were incredibly high. Some would say ridiculously high.

We started to investigate our team’s workflow by beginning at the end. On the upper far-right side of a large whiteboard, I wrote the word DONE in large letters and asked two questions:

  • How do we know that our work is done? The website is behaving as expected by the customer on all the defined platforms.
  • What changed between now and before? We implemented a new feature or a fix to an existing feature, and the result of this implementation is that the website is behaving as expected by the customer on all the defined platforms.

These questions gave us information about the steps that had to happen before considering a work item “done.” We need to test the website on all of the platforms. And we need to implement a feature or a fix.

On the whiteboard, I wrote TEST to the left of DONE, and IMPLEMENT to the left of TEST.

In the whiteboard’s upper-left corner, I added a new column called INBOX. I explained to the team that we would use cards on the whiteboard to represent all the work items we had to do. When a new card (i.e., work item) enters the workflow, we would place it in the INBOX column.

  • What needs to happen between the INBOX and the IMPLEMENT column? Before we begin working on the issue, we need to assess its severity. We need to understand the new feature and how it will affect our personas.

I added an ASSESSED column between the INBOX and IMPLEMENT columns.

  • How do we know what we need to implement? There are two types of work: planned work and unplanned work.
    • Unplanned work is the fixes that are detected by the users, the customers, or our teams. We are committed to delivering the fixes in a defined timeframe according to the severity of the issue.
    • Planned work is the new features that are defined with the representatives from the customer teams.

To distinguish between the types of work, I added a horizontal line across the columns to create an area in each column for Fixes (unplanned) and Features (planned) work.

Here’s what the whiteboard looks like:

High-impact teams workflow

We identified another issue we needed to address: The list of defined platforms had changed regularly, so we decided to make that list visible on a wall in the team room and use it as a checklist for the implementation and test activities.

How it works

A card enters our workflow in the INBOX column:

  • If the card describes an issue to fix, the team assess its severity and places the card in the ASSESSED column of the FIX swimlane. The card is timestamped and assigned a due date, then all the cards are sorted by due date and severity.
  • In the case of a feature to implement, the team evaluates what the ask means, discusses the implementation approach, and places the card in the ASSESSED column of the FEATURE swimlane. The customer and the team agree on the relative importance of the feature compared to the other features already in the column.
  • On the list of defined platforms posted on our team room wall, the team also discussed and displayed the assessment criteria for bugs and features on each platform.

What’s the benefit?

This example walked you through how we identified our workflow and made the work visible. In the interest of brevity, I simplified what was a multi-day planning process.

The fundamental principles to make work visible are: Start with the desired end state, ask questions to understand what needs to happen to reach that state, and iterate to reach the beginning of the workflow. This must be a team activity because each team member will have his or her own view of the different steps.

The immediate benefit for the team is it is obvious what needs to be worked on next, so each team member can pick the next card knowing that he or she is doing the right thing for the project. The indirect benefit is that it shows where in the flow we are overinvesting–we can see it because the cards are pilling up in the column just to the right of our overinvestment. In this case, we must limit that space according to the capacity of the team and focus on keeping a continuous and even flow of cards.

What do you think?

By making the work visible, the team knows where to invest its energy to have the most impact. This is why I think making work visible is the top requirement for high-impact teams. What do you think is the #1 factor in a high-impact team? Please post your answer in the comments or tweet @alexismonville or @opensourceway with the hashtag #ChangingYourTeam.


The post was first published on on July 31, 2018.

Product Management and Engineering Collaboration

Product Management and Engineering Collaboration

The Boston Product Management Association hosted a meetup at HubSpot yesterday about the collaboration between Product Management and Engineering. Chatting with a few people before the start of the event, it sounded like there was a need for a productive tension between the two roles. Here are a few notes from the discussion about that productive tension.

Michael Woonton facilitated the panel composed of Sophie Higgs and Stuart Layton from Hubspot, Adam Buggia and Bryan Dunn from Localytics, and Kylie Brennan and John Siemering from Wayfair.

In the first 5 seconds, a panelist explains his role as ensuring that every member of the team understands what the “North Star” was. They are using OKRs (Objectives and Key Results) to reach that shared understanding and to ensure the focus on the customers.

For context, all the panelists are working with self-directed small teams. The vocabulary differs from each other, some are calling them agile teams, others scrum teams, and others squads, but the focus of one team delivering end to end a specific area is similar.

Another panelist highlighted the fuzzy separation of roles between the product manager and the engineering manager. The blurred separation makes their collaboration better and avoids the “threw over the wall” effect of a more classic division of the roles.

Investing in the relationship between the product manager and the engineering manager is crucial to make the collaboration sustainable and effective. Learning to speak each other language helps to find common ground on aspects that seem to traditionally opposed product management and engineering. “Do we want more new features?”; “Do we want to resolve our technical debt?” are not questions they are asking. They are not working on technical debt for the sake of it, but for advancing the resolution of a problem for a customer.
Speed is the critical aspect highlighted by all. Speed to get problems solved faster. Speed for the users of the products.

One of the product managers mentioned that with his engineering background, he noticed that his own technical knowledge could be a limiting factor. When he believes something is not possible, he could even avoid submitting the problems to the engineering team. He realized that as technology evolves fast, his limiting beliefs were sometimes wrong.

The roadmap represents the best guess at solving the right problems right now. Adjusting regularly the assumptions and continuously evolve the roadmap is part of the game. The roadmap will not present a list of features, but the business outcomes positioned in the business context, and they nearly all agreed that OKRs is the way to share objectives between teams and foster collaboration. The only caveat was on being cautious not to lose the vision and the associated narrative [which is the way OKRs are supposed to work anyway].

Dependencies between teams are a lack of communication. The communication needs to make visible the connection between the business outcomes and the contributions of the different teams. Once again, OKRs are a way to ensure that several teams understand their contributions to the same Key Result.

On the topic of dependencies, one of the panelists mentioned Conway’s law, as a reminder of the connection between your organizational structure and the product you build.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Conway’s Law

Continuing on dependencies, I appreciate the honesty of one participant explaining how her team tried to solve by itself a problem that should have been addressed by another team. The process of learning the skills they did not have was at the same time interesting, and a big waste for the company as the other team could have solved the problem faster, if only they understood how important it was.

Who gets to hear the feedback of the customers, was another question unifying the panelists. Having the team hearing directly the feedback from the customers is beneficial. Having the team working directly with the support organization, and feeling the pain of customers help them to find a faster way to solve important pain points.

A question from the audience was around legacy and technical debt. Hearing the question, I thought it was more a “legacy organization” question in a company where product management and engineering were in opposition instead of collaborating on shared goals.

What are your thoughts on this productive tension between product management and engineering?

Collaboration Superpowers Podcast

Collaboration Superpowers Podcast

I enjoyed the interview with Lisette Sutherland for the Collaboration Superpowers Podcast.

The focus of Lisette is on collaboration between people working remotely. She has a ton of ideas on how to make remote work successful.

Lisette is the author of a great book: Work Together Anywhere: A Handbook on Working Remotely—Successfully—for Individuals, Teams, and Managers.

Check out the podcast and let me know what you think!

Graphic design of the header by Alfred Boland (reused shamelessly from the Collaboration Superpowers website)

The Matrix of Principles

The Matrix of Principles

The Matrix of Principles is a reflection tool to capture how stakeholders understand Deming’s 14 Management Principles.

Reflecting on the management principles enables the team to share their beliefs on management, to share their views on where the organization is, and to identify areas for improvement.

Follow the few steps below

  • Take a blank sheet of paper, or use a whiteboard,
  • Draw a 2×2 matrix,
  • The horizontal axis represents your agreement with the principle. On the right, you agree; on the left, you disagree,
  • The vertical axis represents how the principle is applied to your organization. “Applied” at the top, “not applied” at the bottom,
  • You will now position Deming’s 14 Management Principles by placing their numbers on a 2×2 matrix. Each team member uses a different color.
  • After placing each principle, the facilitator asks the outliers to explain their position.
  • The facilitator asks the group if it inspires some ideas for the team.

You can use the tool as a self-reflection one. As a facilitator, it is useful to try the exercise first by yourself to be able to pick the principles that will most resonate with your team.

There is one assignment per chapter in the book Changing Your Team From The Inside. The Matrix of Principles is the assignment from the chapter two.

The practice is available in the Open Practice Library. You can find other great practices in the library and you can even contribute to it!


On The John Poelstra Show!

On The John Poelstra Show!

I was on The John Poelstra Show last week, and as John said: It was a great conversation. John is energetic and supportive, and I enjoyed the way he guided the conversation.

One part, I really enjoyed, was the transition he made between his question about waterfall project management and the reference to the book Ego Is The Enemy. It helps me realize that I was not exactly kind and moderate in my previous answer, and I wondered at that moment who was really speaking.

John gives the highlights of the conversation in his post.

The podcast is available on Spotify, and, of course, your favorite podcast listening tool.

Let me know what you think!



Featured image is by

Back to School

Back to School

For a lot of people, September means that we are back to school! Or maybe that we are not in school anymore, and so we need to take care of our learning path. I learned a lot from your feedback on Changing Your Team From The Inside. Keep that coming! It is very useful! I am working on a revision of the book that will be available by the end of October.

If a friend sent you this message, you can subscribe to the mailing-list following the link, yes you will have to scroll a little bit.

The planning of my trip to Europe is nearly done. I will be traveling to Germany, Switzerland, and France. I will be speaking at Agile Rennes on November 23 and 24, and Agile Grenoble
November 14 and 15. Add the sessions to your agenda!

As it is two agile events, people asked me if I will speak about agile. The answer is yes and no 🙂

If you read the UncleBob’s post reacting to Martin Fowler’s keynote at Agile Australia, you can see that the tension is about values and principles. The roots of the agile movement were about team members having the autonomy to deliver excellent work. Uncle Bob (Bob Martin) wrote in a sort of conversation with himself:

“But aren’t Scrum Masters kind of like project managers?

Heavens no! Scrum Masters are coaches, not managers. Their role is to defend the values and disciplines. Their role is to remind the team of how they promised themselves they would work. The role was supposed to be shared by the team, not usurped by managers. Every few weeks a new team member would volunteer to act as coach – if needed. The role was supposed to be temporary. A mature team doesn’t need a permanent coach.”

And yes, I have seen that level of maturity happening more than once. The frameworks, the tools, the practices, are useful things that you can use and improve along with your transformation journey.

About framework, I love the approach Agnostic Agile, and I encourage you to have a look at the principles.

“As experienced agile practitioners and as people responsible for agile change and transformation, we should recognise the importance of being agnostic with agility at any level. This means one size does not fit all, one framework is not the answer, and the ‘what’ and ‘how’ should be suited to customer context and to a wider strategic vision.”

As usual, I will be happy to hear from you, please answer to that message, or send me a message on Twitter or LinkedIn. I will be happy to answer your questions or read your feedback.

Thank you!

PS: Your comments, like and share are really helping the message to reach more people. Please, help me share those articles on

Project Aristotle – A Conversation Starter

Project Aristotle – A Conversation Starter

In Measure What Matters, John Doerr speaks about the quality prized by Andy Grove: collective accountability, fearless risktaking, measurable achievements. John explains that Google studied 180 teams using five questions. The internal project code name was Project Aristotle.

The results? Standout performances correlated with affirmative answers to these questions:

  • Structure and clarity: Are goals, roles and execution plans on our team clear?
  • Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
  • Meaning of work: Are we working on something that is personally important for each of us?
  • Dependability: Can we count on each other to do high-quality work on time?
  • Impact of work: Do we fundamentally believe that the work we are doing matters?

A few weeks back, I decided to test the five questions with a team during their quarterly face to face meeting. I used the length of the meeting room as a scale and identified graduations with sticky notes on the wall from zero at one end of the meeting room to ten on the other end.

I asked everybody to stand up and explained the rules. I will ask questions, the more you agree, the closer to ten you need to be, the more you disagree, the closer to zero you need to be.

We started with a few questions just to warm-up the group and to have opportunities to clarify the rules. And then, I began to ask the five questions.

First one about structure and clarity, two people moved to five and six, all the others looked at how the boss will react, and one ask a clarifying question: When you say “our team,” what do you mean? I clarified, the team is the people that are in this room now. The rest of the people are moving between seven and nine.

I am now asking a few clarifying questions asking them to explain their position on the scale. I also encourage them to ask questions. The newcomer in the team suggested that it could help us to use Objectives and Key Results (OKRs) as he was doing in his previous company. An interesting conversation followed, and I am capturing on sticky notes discussion topics for the rest of the meeting.

We continued with the other questions, and people moved faster to their graduations (even with their manager in the room). The conversations focused on what the people need to give a better grade, which gave us plenty of topics to cover in the meeting, restructuring the agenda to better fit in what was essential to the team.

The exercise was useful as it raised the awareness on some aspects that were missing to “really” called this group of people a team.

Try it and let me know!

What a Month!

What a Month!

Last month on July 1st, and thanks to your support, I published Changing Your Team From The Inside. It has been a great month! (If a friend sent you this message, you could subscribe to the mailing-list following the link).

I learned some of you organized several book discussion clubs. It is fantastic to see the book selected for discussions! It will give me a lot of suggestions to improve the future editions of the book. As a reminder, whatever version you choose to purchase, you are entitled to get all the forthcoming revision of the electronic version.

The question I would like to ask readers is: “What do you need to give the book a 5-star rating?

As you probably already know, ratings help readers to pick their next book, so if you can rate the book on,,, and, you will help me!
And of course, if you can send me or publish a review that will help me to improve the book, it will be even better!

I published an article, What is the top requirement for high-impact teams, on, please tell me what you think using the comments or by dropping me a note at Sharing and liking the article will help me too.

Several people already purchased the team edition of the book, and I am scheduling the discussions with the different teams. I will report back on the blog, what we learned from the conversations. The last post is On Consultants reacting to the Steve Jobs talk recently published by the MIT Sloan School of Management.

As I live in Boston, I am available for talks in the area, in North America, or further away. I announced a few weeks back the travel to France in November, I will speak at Agile Grenoble and Agile Rennes, and the trip will give me opportunities to meet with other people, organizations, and companies. Let me know if you are interested! Also, If you attended one of my talks in the past years, please provide a testimonial on SpeakerHub!

As usual, I will be happy to hear from you, please answer to that message, or send me a message on Twitter or LinkedIn. I will be happy to answer your questions or read your feedback.

Thank you!

Contrat Creative Commons
Les articles publiés ici sont mis à disposition selon les termes de la Licence Creative Commons Paternité 3.0 non transcrit.