Author: Alexis

Happy holidays

Happy holidays

I guess that a lot of you are getting ready for the upcoming holidays. I wish you will have some good time with your families and friends.

Six months after the first publication of Changing Your Team From The Inside, I counted the published versions. There are 14 versions of the book published so far. I continue to work on improving the book to take into account your feedback. So, keep them coming and thank you!

Two fantastic coaches are reviewing the book chapter by chapter right now. I will tell you more about them next year. Our goals are to produce an incrementally improved version and to collect the improvements needed for a second edition. And, of course, whatever the version you bought, you always have access to the electronic latest version. Drop me a note if you don’t know how to get it.

I chose to end all the chapters of my book, Changing Your Team From The Inside, with a section titled “Summary and Action”. The goal of those sections is to give you keys to act immediately on your environment. Learn more about one of the key practices and how readers are using it in this article.

Another book discussion club chose my book for their monthly discussion, and they even took the time to send me detailed feedback. Thank you very much!

If you want to do more to spread the message of the book, a review on goodreads would be great! I suggest a five-star rating 🙂

I will give conferences in Boston and Montreal in January, more details in the next newsletter.

Happy holidays!

PS: If a friend forwarded this to you, you can sign up to get the email yourself here.

Summary and Action

Summary and Action

I chose to end all the chapters of my book, Changing Your Team From The Inside, with a section titled “Summary and Action”. The goal of those sections is to give you keys to act immediately on your environment.

I regularly received feedback about how great it was to have exercises to practice directly and impact your “day-to-day.” Some of the answers to the question I asked immediately after receiving those feedbacks still surprises me.

The kind of question I asked: “have you tried some of the exercises?”

The answers I received were along the line of: “no, oh well, not yet, but I will.”

Some people told me they were not ready to act when they read the book and added the exercises to their backlog of things to try. Some others told me they were too curious to read the next chapter to take action immediately.

The great thing is that a lot of people told me how great it was because they tried one exercise with great success!

Mario Esposito tried the exercise from chapter 5. The practice is a way to guide one-on-ones when meeting new people. Mario worked that with his team with great success. He even printed the cards and adapted the experience section to cover past, present, and future, see the picture below.

Mario told me: “I used it once again today, for the onboarding of a new collaborator who had just joined the team… I tell you only that after 40 minutes we were already like two best friends! Really powerful this workshop!”

Let me tell you more about the exercise.

When you don’t know where to start in creating a relationship with people, you can use the help of a structure like what Portia Tung proposed in her book: The Dream Team Nightmare.

I used the approach when I was the new person in a company. I was tasked with creating and nurturing an agile culture. Of course, some people were enthusiasts, whereas others were a bit skeptical. I planned one-on-ones with all the team members.

To prepare the agenda for the meeting and to make the work visible, I wrote on three mini sticky notes the three headings that give a structure:

  • To Do
  • In Progress
  • Done

The headings are at the top of the three columns of a virtual kanban board that you will form on the table of the meeting room that you will use.

Then, as advised by Portia, I wrote the topics, one per sticky note:

  • Ice Breaker
  • Professional Background
  • Agile Experience
  • 3 Wishes
  • ???

The sticky notes are the proposed plan for the conversation. We start the meeting with all the notes in the To Do column, progressively move the card to In Progress, and finally to Done when we covered the topic.

Let’s begin with the Ice Breaker. Move the note to In Progress. The Ice Breaker is a game in which we take turns asking each other questions. We only have three questions each, and each person has the right to ask a different question. To start with, Portia Tung proposes those three questions:

  • If you could do anything in the entire world other than your current job, what would it be?
  • What do you spend most of your spare time doing?
  • What’s your favorite holiday destination?

Those are great questions, and you will see that you will learn really fast new great questions, thanks to the questions your co-workers will ask you. You will also learn a lot about yourself and the first impression you have on people because of the questions people are asking.

Over the years, I have asked, or I have been asked, questions like:

  • Have you recently thought, “I wish I had done that?”
  • Are you afraid of anything?
  • How do you measure your success?
  • Are there things you don’t know that you feel you should know?

Once the Ice Breaker is Done, you pick the next note in the To Do column and move it to In Progress: Professional background. You will now share your work history that led to your current role.

In the context of my mission, the next note on Agile Experience was crucial to assess the level of experience and understanding of the other person. I had once, in another context, an engineer, specialized in quality assurance, who told me in that section: “My last experience with agile is simple; the agile guru explained that our way of working, separating development and quality assurance, was the root cause of all the problems.” I waited a second before saying anything. I tend to think that separating people in silos is a quite common cause of problems in an organization. The engineer continued: “And then our manager fired all the quality assurance engineers, and that’s how I moved to this company, and so I guess that your mission will be to fire us.” You can see that investing some time in that exercise could be wise. It has always helped me. And I regret each time that I cut corners and don’t invest enough time in getting to know the people I will work with.

Time for the 3 Wishes! You end with another game, asking a question: “If you could have three wishes for transforming your daily work and/or workplace, what would they be?” Once again, what the people say here will teach you a lot about the organization and their current mindset.

The last note, with the three question marks, is a wild card to allow the other person to propose any additional topics to discuss. People will sometimes have nothing more to say, and sometimes they will suggest a topic that could be useful to cover in another meeting, not necessarily one on one.

 

I am delighted to hear your feedback about the book, and especially about the exercises! I think I will put your stories about the activities in the next edition of the book!

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 opensource.com. 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 opensource.com 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 opensource.com 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!

 

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 opensource.com:

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