Tweaks for Personal Map sessions

TL;DR: I’ve found a few ways to gamify Personal Map sessions that has yielded engagement from participants. You can download a facilitation guide here.

A great way to build trust with a team is to run them through the Personal Maps exercise from Management 3.0. Here is Jurgen Appelo explaining how it works:

Over the years I’ve worked with teams who have come up with innovative ways to make the exercise more engaging and fun. Here they are…

Only answer questions about the map

With this one the participant shows their map to the rest of the team but instead of having the one who creating the map choosing what to talk about it’s up to the other participants to ask questions about the map. By doing this the others get to explore the person showing the map instead of the person owning the map deciding what is interesting.

Add a lie to the map

Inspired by 2 truths and 1 lie you can instruct the participants to add something that is false to the map. It’s then up the other participants to guess what on the map is incorrect. Having this element of gamification usually brings more engagement as it can turn into friendly competition while still thinking about what they think is true or false about the person.

Leaving out the name

Instruct the participants to leave the middle blank (where the name usually goes). In the session everyone folds up their map and puts them in the middle (or in a hat if you have one of those). Then, at random, you pull a map and have someone run through it. It’s then up to the participants to guess who the map is about. You can combine this one where you add a lie to take out something that is obvious about you.

Hope these small tweaks will help you create a more engaging experience for the participants. Good luck!

Feedback and growth as a team activity

Feedback is key to any successful organisation but in my experience the way formal feedback is handled is not always optimal or doesn’t suit everyone. Below you can read about an experiment I’ve done to try to make things a bit better in my current setting.

The “normal” way of doing feedback

The way this traditionally works where I’m active at the moment is that people send out feedback requests to their teams and the feedback is handed back via email or an internal tool following this structure:

  • Achievements
  • Mastery
  • Behaviour

Each category has the sub sections:

  • Things to be proud of
  • Things to improve

When feedback is sent, the manager is cc:ed on the email or can see the feedback in the tool, later on the person receiving the feedback sits down to go through the feedback together with the manager and come up with a plan for the next 6 months. At this point the feedback from the managers is also incorporated and any additional feedback that the manager might have solicited.


I’ve found that this way of handling the feedback has some flaws:

  • Unless asked for, there is no face to face communication about the feedback that the person receives.
  • There is always room for misunderstandings in written feedback, especially in a multi-language organisation.
  • There’s often a shotgun effect to the feedback you receive, since those giving feedback do not necessarily know what areas the person wants feedback on.
  • Often people send out feedback requests to mailing lists. This means that everyone would receive 10-15 or more feedback requests. This can be overwhelming as it takes quite a bit of time to write well thought through feedback.

Personal growth as a team activity

As an experiment for improving the situation we are doing some significant changes to how feedback is done in the teams I’m working with at the moment.

Growth areas

First, we wanted to make sure everyone in the teams are aware of what their teammates have as their growth goals. To kick it off we had a session where everyone listed:

  • Top 3 growth areas. This could be anything from Java, testing frameworks, Cassandra and BigTable knowledge to public speaking or mentoring.
  • Up to 2 behaviours that they wanted feedback on. This could for instance be if they were interrupting too much, not speaking up enough or not being specific enough when doing code reviews.

Once everyone had written down their own improvement areas we went around the table and everyone told the team about the areas they wanted to improve in. This creates an opportunity for  a valuable conversation if several people had the same thing noted down. A consequence of this is that people could start looking after each other as new tasks came up. For instance, someone wants to grow their Cassandra skills a change was needed in the Cassandra cluster. The team could then help that person by giving them space and support when performing the task instead of having the person with the most knowledge pick it up and just get the job done.

Effectiveness Reviews

The inspiration for this part has come from Peer Reviews in S3 but we adjusted it to interface with the way we normally do feedback (see above). This was the process:

  1. Think about 5-6 people who you would like feedback from. This can be members on your team, people you have collaborated with and preferably your manager.
  2. Invite them all to a 1 hour meeting in a place and time of your choosing.
  3. In preparation for the meeting a few things should happen.
    1. As the recipient of the feedback you should remind the feedback givers of your growth areas.
    2. Evereone (including the recipient) should start thinking about feedback.
    3. The recipient should consider inviting a neutral facilitator that can explain the setup and make sure the session stays on track.
  4. The review would typically run like this:
    1. The facilitator starts by drawing the grid below on a whiteboard or several flip chart papers and explains the rules of engagement (see below).
      Effectiveness Review 1
    2. Appreciations:
      1. Everyone (including the recipient) is given 4 minutes to write appreciations connected to the 3 themes. 1 appreciation per post-it.
      2. The recipient goes first and puts up the appreciations for themselves and explains what the post-it says and what they mean.
      3. The feedback givers do the same and cluster appreciations that are similar. Here there is also the possibility to build on what have already brought up.
    3. Improvement areas are bigger themes where the person could improve to have an even greater impact (note that these are not actions that the person could take – that comes in the next step). The setup here is the same as for appreciations, write post-its, the recipient goes first and then the rest. Ideally the growth areas that you brought to the session should now be on the board.
    4. The time has now come to be concrete. For another 4 minutes the participants write up suggestions for actions connected to the improvement areas. Say for instance that you have an improvement area that is public speaking then suggested actions might be: “Do lunch and learns for the team”, “Take this public speaking class that I’ve heard is really good” or “Watch this TED talk that really helped me improve”.
    5. The session is now over. Time to thank the feedback givers for their contributions.
  5. Following up from this session the person receiving the feedback creates a document where all the input is gathered and grouped into categories. You then book a time with your manager where you look at the feedback and decide what you want to focus on improving. It’s important to note here that just because someone else says you should improve in an area it doesn’t mean you need to. It’s up to you to decide how you want to grow.

Rules of engagement for the session

There should be a positive spirit to all pieces of feedback. If people start bringing up negative feedback and other people start building on it the session can quite easily turn into a bullying session that would be highly uncomfortable for the person receiving the feedback. Trust is key for the feedback to be received well. It’s the facilitators responsibility to bring the conversation back on track again if things are starting to go off the rails.

People in the session are welcome to ask clarifying questions if anything is unclear. They should however not start debating or question the feedback someone is giving.

How time consuming is this going to be?

Say that you are part of a team of 7 people and you are invited to the Effectiveness Review for 4 of them (probably the people you work closest with), then you have 1 hour spent on your own and 4 hours in the reviews for other people. You should spent a bit of time preparing for the sessions thinking about what feedback you want to give and then you need to summarise the feedback you receive. In total, in this scenario, I would guess you spend about 6 hours per person.

It’s worth noting though that this process was not designed to optimise the time people spend on feedback. It’s optimised to produce better and more meaningful feedback coupled with help with how to proceed with you own development. All of this in a setting where you as team members care, boost and look out for each other.

Learnings and next steps

When it was introduced, a few people on the team were skeptical and because of that wanted to stick with the old format. This was perfectly fine. What I wanted to provide was a variety of ways to gather feedback where people would pick the one they were most comfortable with. However, after attending the sessions for others people generally changed their minds and booked their Effectiveness Reviews.

Based on a survey I did with the team, I found out that the format above works really well and people want to keep doing it. When people had attended a session the need for a facilitator went down as people were familiar with the format and knew what to do. I’d still recommend having a facilitator to keep an eye on the rules of engagement and to be the time keeper.

We did this as a replacement for the annual feedback sessions that happens every 6 months. I can really see this being done more frequently (quarterly or even monthly) to have more continuous feedback. If you go for that you probably want to tweak the format a bit and feed in what you are currently working on and perhaps use your team to help guide you and keep you accountable to what you said you would do.

Retro Kit

Continuous improvement is important for any team but sometimes it is hard to know how to start. To make it getting started easier me and a couple of Agile Coaches at Spotify have created the Retro Kit. We have been testing it internally and the reception has been very positive and since we have drawn knowledge from the community to create it we figured that it would only be right to share it back. Hope you find it useful! 🙂

The Retro Kit has been published on Spotify’s external blog, Spotify Labs.


Team Mission and Definition of Awesome

In this post I’ll describe some exercises that can be used when kicking off a new team or if you want to get an existing team aligned on how it wants to work and what value they provide to the organization.

The package contains of the parts below. Depending on how far you want to take it and how you work with improvements you might want to settle for the first two parts.

  1. Setting the stage and warming up
    1. What is an awesome team?
    2. Appreciative inquiry
  2. Mob writing: Mission and Definition of Awesome
  3. Are we there yet? Identifying the current condition and obstacles.
  4. Identifying candidates for first steps in reaching the definitions of awesome.

All of these usually take about 3 hours to get through (including breaks).

Setting the stage and warming up

The first thing you want to do is to talk about why you are there (you probably already touched on that in the invite) and why it is important that the whole team participates.

After that you will want to get people in the right mindset with some warm up. Especially if this is the first thing you do in the morning.

What is an awesome team?

In this part you can throw up examples of teams and ask the group if they are awesome or not. Discuss why or why not. You can find your own but here are some examples and points that you can discuss.

  • The A-team
    Cross functional
    Have clear missions
    Help each-other to solve tricky problems
    … and like the A-team all teams need a crazy helicopter pilot. 😉
  • Fellowship of the ring
    A clear mission
    Not that aligned on how to reach that mission
  • Orchestra or a rock band
    Sound better when they work together
    Practice really hard individually on their skill but also need to play and practice with other types of competences.
  • Sports team (in this particular case Chelsea when they won the Champions league)
    This picture tells the story about a sports team that were the underdogs throughout the kick out phase but managed to get to the finals. In the finals they met Bayern Munich and were again underdogs. In the end Chelsea had done all their substitutions and a defender got injured. Fernando Torres (a forward) took a place in the defense of the team. He went outside of his expertise to to what the team needed at the time and in the end the team won after overtime and penalties.
  • People working out at a gym (compared to a sports team)
    From the outside it might look like everyone is really busy and working on the same kind of thing (like a sports team). In reality there is little to no cooperation and everyone is only focused on their own goals/agendas. Do the team participating in the workshop want to be people working out at a gym or a sports team?

Appreciative inquiry

This warm-up is a segway into the third part – Mission and Definition of Awesome. The purpose being that the team members start telling each other what they think is working well from their perspective.

This exercise builds on appreciative inquiry where you only focus and talk about what is working well or what could be working well.

Stage 1

Ask the participants to write on post-its what is working well today. One thing per post-it. After about 3-4 minutes you ask the participants to present their post-its one by one and talk about what they have written.

Stage 2

Ask the participants to imagine that you have created a time machine. You all step through this time machine and travel into the future. Depending on what context you might want to select different amounts of time but it can for instance be a year into the future. In this future you walk over to the office and meet your future selves. They say that it has never been this great. Everything is working perfectly. You are productive, happy etc. Ask the participants to write on post-its what their future selves tell them and what they see around them. Present as you did in stage 1.

Mob writing: Mission and Definition of Awesome

The next part is to as a group agree on what the mob-writing-300x156.pngpurpose of the team is (Mission) and
what identifies them when they are working really well (Definition of Awesome) is.

Start by explaining the format
and the rules:

  • Format
    • You will have one or two sentences describing the teams mission. Try to make it snappy.
    • You will have five (not more!) statements describing what identifies the team when it is working really well. The team can draw inspiration from the post-its on the wall from the previous exercise as inspiration.
  • Rules
    • Everyone participates Everyone can write, erase, reformulate… It is done when no one has objections or adjustments.

Invite everyone to the whiteboard and hand out pens. What usually happens is that people start adding statements without getting questioned. The magic happens when all five slots are full. Then the teams needs to start communicating, arguing and agreeing on what they think is important. Try to give the team as much room as possible but if discussions derail ask the team to move on the something else and then go back to pick up the statement discussed later on.

When the discussions are cooling down you can enter the group again and point at the first statement and ask if everyone agrees. Thumbs up = agree, thumbs to the side = could be improved, thumbs down = this is not ok.

When the team is in agreement move on to the next part.

Are we there yet? Identifying the current condition and obstacles.

roads-300x172.pngSo now we have identified where the team wants to be – the Definition of Awesome. Let’s figure out how to get there. Here we use the classic coaching format of identifying the target condition (Definition of Awesome), current condition, obstacles and actions/improvements. In the picture to the right the rainbows and unicorns is the definition of awesome. This is where the team wants to be. The five roads represent the five statements and the swamp is where the team is today.

Step 1: Current condition

In this step the team writes post-its describing the current condition connected to each track. These are represented by the yellow post-its on the picture.

Step 2: Obstacles

Here the team looks at what is preventing them from reaching the target condition. These are represented by the pink post-its.

First steps

improvement.pngIn this part the team will identify how Awesome can be reached. We use a rotating flipchart style where you set up five flip charts or Magic Charts spread out around the room. Split the team and spread out among the charts. On each chart you talk about one of the definitions and what you can do to reach it. If the idea is complex you might want to use a Kata style approach – we put them on the upper part. Actions that are quick and straight forward are put in the bottom.

After about 5 minutes it’s time to rotate and you go to the next chart and discuss that. After four rotations everyone should have visited each chart/definition.

To have something concrete to bring back and to get started when right away when you come back to the office it can be a good idea to vote on one quick fix per chart to do right away. Assign people to take responsibility for each quick fix that are voted on.

Following up

After these exercises the team will have a lot of materials to drive improvements from. Bring it all back and try to make as much of the results visibal and present near the team. If you aren’t already using a Kata-style approach to improvements perhaps you can find some inspiration in this blog post: Toyota Kata – an alternative to retrospectives by Håkan Forss.

However you do it, the important thing is that you continue to work with the results so the time wasn’t wasted and just a nice experience in a conference room somewhere.


This set of exercises have proved to work quite well for me. Off course you might want to tweak them to fit the teams needs or add other exercises if you do this as part of a full day.

I hope this post was helpful and don’t hesitate to comment below or reach out to me if you have any questions or want help in facilitating a workshop.

Good luck!

Shorten your feedback loops with Cafe Testing

One of the teams I have been working with lately develop and maintain a retailing web site. Historically what they should focus on was decided by someone high up in the organization with little to no involvement of the team. After a lot of time and money invested most of those ideas turned out to have little to no impact on the number of purchases made through the site. To remedy this we wanted to leverage the collective intelligence of the team and also use a more scientific approach when deciding what to do. The approach we took drew inspiration from Lean UX and Lean Startup. We also used tools like Impact Mapping where the idea is to have a clear goal of what we want to achieve, see what actors could affect that goal and then look at what assumptions we have about those users related to that goal. After that we have our Impact Map and it’s time to get to work with the assumptions. We did this in really short iterations to keep the investments small if assumption turned out be false. One really useful way of validating ideas we found was to do lightweight usability testing. The way we did it often included theses steps:

  • We have an idea or an assumption about how we can better achieve one of the goals we are striving for at the moment. We selected the assumption that we thought could best contribute to the goal.
  • In the most lightweight way possible we create a mockup, prototype or MVP that could in some way validate or invalidate our assumption.
  • The next step is to do the validation and now it was time to get out of the building. We found that a good place to find test subjects was at a café at the grand central station in Stockholm. The benefit of this is that you find people from all over the country of all different ages. They are very often just waiting for their train and because of that very open to answering some questions in exchange for us buying them a cup of coffee.
  • When we have interviewed about 3-5 persons representing different personas we usually have enough data to go back to the drawing board. Did our assumptions hold true or do we need to focus on something else? Of course we can’t blindly go by what the test subjects were saying but it is usually a good indication.

We can usually go through this cycle in a day and that gives us really fast feedback loops and we avoid investing too much time and money in developing something just because someone high up in the hierarchy decided it was a good idea.

This approach has helped us a lot and perhaps it is something that can help you as well if it fits your context. Please post a comment below if you found this post helpful or if you have tried it yourself and have some insights or experiences to share.


Avoiding the meeting menace for your development team

Have you ever heard members of a development team complain about too many meetings? And when you look in their calendar all you find is a couple of meetings spread out through the week. As a Manager, Scrum Master, Product Owner etc. you might have thought “That’s nothing – I have meetings a day long!”. This is a natural reaction but the point you are missing is that the nature of your work is radically different compared to that of the development team. While a lot of your work is done in meetings and your days are fragmented the teams work doesn’t work that way. Paul Graham describes it very well in his post from 2009 about the Maker’s Schedule and the Manager’s Schedule (I really recommend reading the whole post). He describes that a developers day may be blown to pieces if meetings are scheduled in a way that prevents them from getting some flow in their work. To remedy this I recommend talking about this within your team and adding it to your Teams Working Agreement (because you have one of those, right?).


Examples of how this could look in practice:

  • Do like Facebook and have a meeting free day per week. During that day the team can completely focus on the work at hand without interruptions.
  • Have something similar to visiting or opening hours for the team. During these hours it is ok to schedule meetings. When you choose these hours I recommend considering having your prime working hours (high energy) as your non-meeting time. On the Working Agreement this could be formulated something like:
    • “We are all in the office at least between 9 am and 4 pm. Meetings are scheduled after 2 pm.”
    • Or “We do meetings after 2 pm. All meetings have a clear agenda and purpose. We are on time.”

I really recommend trying this out. And who knows, maybe you as a non developer find value in getting some uninterrupted thinking time as well.

Ps. You should of course still talk to people if you need help getting unblocked or help someone else get unblocked. “People and interactions over processes and tools” is still what we strive for. This is merely a tool to help getting you meetings under control if that is a problem for your team. Ds.