Teams don’t like me as Scrum Master

It is true… development teams don’t like me as Scrum Master. They blame me, they tell me it is my fault, they tell stakeholders that Ralph the Scrum Master said it was not good enough. Probably making the stakeholders think: “Who is that guy to decide if it is good enough?”

Why do they don’t like me? Because after one sprint of hard work, I am the one who tells them that they are not allowed to show the results of their hard work to the product owner and stakeholders. It is me who is so black and white. It is me as Scrum Master who doesn’t understand that they really worked hard and even did some overtime!

Sometimes the product owner or some of the stakeholders ask me “Ralph, but why not, this seems so unfair?”

OK, let me explain why sometimes I am a horrific Scrum Master in the eyes of the development teams.

We all know these projects where the team reports 80% of the work as done, and when the software/framework is done, we can do everything we need to do, and even more. OK… sounds good, so let’s just wait until that final 20% gets done. For some reason, however, that last 20% of the work will then start taking 80% of the project time.

What will happen when a development team shows work done during the sprint that is not really done? Maybe they even say, it is not completely done. Trust me, when stakeholders leave the room, they will remember the software that has been shown during the demo. They will forget that small footnote, it is not done yet. So the impression is, the project is on track, everything was done.

The team will still need to finish the items that they showed during the sprint review (not sprint demo!) The work that is not done could pile up, and it will take a few days in the next sprint before they can start working on the new sprint goal. With a bit of bad luck, this will get worse over time, and also influence the velocity.

The most important reason I forbid teams to show work that is not done at the end of the sprint, there is no learning! No reason to improve! Scrum is for me all about making things visible, being transparent, and inspecting and adapting. If we don’t show to each other that we don’t have items done, why improve?

Let me tell you about a few recent examples, where I coached teams and made them have a bad day because of this.

One team committed to two items in one sprint. They estimated the items to be around 40 points. The team believed they were able to make around 80-100 points in a two-week sprint. I told them upfront, guys it could be smart to split up those items. Either the team was too stubborn or I did not explain myself clearly. The day of the sprint review came and I asked hey guys, what are you gonna show during the sprint review? Those two items? Are they done? Yeah, almost, 90%… Nope, you are not gonna show them. I used my veto and forbid it. The team was upset and blamed me explicitly during the sprint review. Fine, no problem for me. Guess what happened in the next refinement session… they split all big stories up into small stories.

A second case. One team had a big dependence on a visual designer. However, this person was overloaded with work and also reported ill a few days during the sprint. The team said we can show and report it done during the sprint review. The only thing we need to do is to do the styling, but we can explain this and do it next week. Well sorry again team, but you are not gonna show these items. They are not done. I would like you to report why it is not done, though, because of your dependency on the visual designer. You should make the organization aware of this problem, by mentioning it during the sprint review, and the impact, it will get attention. There was a second team who reported the same issue. The result was that the management team looked into, and started to get some extra project funding together to get an additional visual designer.

To make this all work, make sure you have a good Definition Of Done. The Definition of Done is used to decide if an increment or backlog item is done. In a very transparent way, the Scrum team should know what the Definition Of Done (DoD) is. As Scrum Master, you can refer to the DoD and not just because “I say so.”

I hear you thinking, Ralph, Scrum is all about inspecting and adapt, and you throw away this opportunity. True, I throw away THIS opportunity, but the moment I tell the team no you are not gonna show it, I also ask them to schedule a meeting with the Product Owner asap to show the progress to him. Furthermore, I advise them to have regular meetings between Product Owner and team members to discuss progress. The sprint review can and should be no surprise for the product owner.

What do you think, do teams don’t like me for a good reason?

Why is HR not agile?

The title of this blog post triggered you: Either you agree, or you disagree.

Let me first explain in a nutshell why you need agile, and then how it relates to HR.

I have a background in software development. Many frameworks in software development assume they can predict the future. In other words, they think projects can be managed entirely by making big plans, introduce hand-over moments, etc.

In the nineties, we had the Software crisis, the software was always too late, and quality was too low. The industry had to do something. There were two ways to go: one that would introduce even more frameworks, steps, documents, etc and the other is what we now call agile. To me, agile proved about realizing that you need to use an empirical approach to manage complex projects.

What makes those projects complex? I could name a wide variety of things here, but one of the most important factors is the fact you work with people. You simply can’t manage people like a machine. Nowadays we call this management 1.0, and you can read all about it in the works of Frederic Taylor.

In my career, I worked with many people from Human Resources, Human Capital and probably there will be more different names for this department. I don’t like it when people talk about ‘human resources’, but in this blog post, I will refer to HR as the organization who in most organizations needs takes care of hiring, career development, salaries, firing, etc.

All those organizations had one thing in common. They worked with corporate models for personal development and reviewing people. At every organization, HR created a framework to help people grow and to help managers to review people. In most cases, HR headquarters created it, sometimes assisted by a fancy consultancy company. The HR department then would develop this model further for all employees, and because they realize they have different functions, they described a lot of skills, competencies, levels, etc.

When we execute technical projects, we use an empirical approach. We are transparent and inspect & adapt. We understand that we need to be flexible, that we need to embrace change and realize that every project needs a different approach. We come to understand that there is no magic approach that will solve everything.

So why does HR still believe that they can develop a framework that can cover everything related to people? Why do they develop one size fits all frameworks that all departments need to use? Why do get agitated when a manager decides to disagree with the HR model?

I think the time has come for HR to use a different approach.

HR has a lot of knowledge about local employee laws, skills, competencies, and people. I am not saying they are prutsers. Definitely not! I am just saying they are using the wrong approach.

Why not create some guidelines, or principles on what you expect managers or teams to take care of? I think it is very useful to use a model in some cases. Nothing wrong with that.

HR should ask teams and managers to think about how they are going to help people develop themselves. They should offer their expertise when asked for by teams, tribes or departments. They should give teams and or departments the freedom to develop their own approach.

Isn’t this very ineffective or inefficient you may ask? Perhaps, I am not saying you should not talk to each other and learn from each other. However, I believe it should mostly be a bottom-up approach. When a manager does not know where to start, HR should definitely help that manager. They should help the manager develop a framework that fits the manager’s department or team. In doing this, there is nothing wrong to be inspired by frameworks that are used by other departments or teams.

So why is HR not doing this?

No alarms and no surprises during your sprint!

I did many projects in my career. I had the role of developer, tester, manager and scrum master. During these years, I can even almost say during these decades (I am getting old…), I learned one thing: I do not like the people who at the end of the iteration, project, whatever, say “I already knew that for many months.” “Err… so why didn’t you speak up earlier?” “You didn’t ask.” Followed by a look from me like WTF-are-you-a-professional-or-not?

GiftI learned about a simple practice, a really simple one to make sure the right information is flowing through the team when necessary. Let me explain, and I will do it based on an iteration.

At the start of the sprint, the product owner and scrum master decide on a sprint goal, the objective that will be their compass during the sprint. When I am involved in a team or when I am coaching a team, I ask them to perform a sprint confidence vote a few times a week. I ask them on a scale of 1 to 5 how confident they are that they are going to meet the sprint goal. Most often, we will vote on Tuesday and Thursday in the first week of the sprint, and on Monday, Wednesday and Thursday of the second week. Assuming a sprint of two weeks that ends on Friday of course.

You simply vote by using your hands. If you show your thumbs (up), you are 100% confident the team will realize the sprint goal. If you show five fingers, a full hand, it means stop! Hold it right there, we won’t make it. The score is on a scale of 1 to 5, where 1 is fully confident we will make it, and 5 is a no way we will make it. Everyone votes at the same time. So, someone counts 1-2-3, and the group cast their vote. Look at the hands, if everybody votes the same number, it is clear. Still, you maybe need to take action. If everyone votes a five, and you all then continue as if nothing happened, then again you will see my WTF-are-you-a-professional-or-not face?

Now the interesting scenario is when a few people vote a 1 or a 2, but some other people vote a 4 or 5… This then implies that some people have information about the progress towards the sprint goal that other people do not have. In such a case, you apply the practice of let’s talk about it. People need to explain why they voted for the number they gave. By talking about it, information will start flowing through the team. When information flows, things become transparent, and it will allow the team to inspect and adapt. I always keep track of the score in the sprint over time, just to see if things are getting worse or not. It sometimes is possible to discover trends in your sprints.

By explaining and using this practice, I got several questions and remarks.

Stop signWho is allowed to vote? Should the product owner or the manager who are in the room during the standup also be allowed to vote? I don’t know… what do you think? I personally feel that everyone in the room should vote. Everyone may hold a piece of information related to achieving the sprint goal. If you, as a product owner, think the team won’t make it, but the team is 100% confident, it would be a good idea for the team to update the product owner about the progress.

I also had many discussions about what exactly are we voting for? Are we voting for a great demo, are we voting for finishing all sprint backlog tasks, or are we voting for the sprint goal? Again… what do you think? I would say you are voting for achieving customer value. Who outside of the team would care whether you finished all sprint backlog tasks? Who cares about a great sprint demo if what you are showing is of totally no value to the customer? So, I would say you vote for the realization of the sprint goal. Moreover, I assume your sprint goal is adding value for a customer.

What happens when you work distributedly? Well, nothing special. Why do some people think working distributedly makes things hard or even impossible? Turn on your webcam, as always, and on the count of three, you show your score.

I worked with a team once, who voted the day after their sprint planning. They spent the whole previous afternoon together with their product owner on making a sprint plan and defining the sprint goals. The next morning, so approximately 16 hours later, they all voted and to our surprise, one team member voted a 5. He was totally not confident the team would make the sprint goal. Only 16 hours before, however, everyone committed to the sprint. Let’s call it at least remarkable. We had a good discussion with the team and looked for a root cause of this behavior. That became a different story altogether. The practice of confidence voting got us talking, however, and made things visible.

I said earlier that everyone should vote. What happens though, when someone just got back from holiday, or someone has their first day on the team. Well, I don’t care. IMO, you have your professional experience. You listen to what is being said in the standup and based on that information you vote. Should you vote something completely different than the rest of the team, you talk about it, because someone is missing some information. If you vote the same as the team, it seems you have a good understanding of the progress (or you were just lucky ;)).Are We Gonna Make It Visualization

We already have so many meetings, is this again an extra meeting? Err, no. I would say you just vote at the end of your daily standup. It will take you just a couple of minutes. Yes, when the voting is done, and the votes are all over the place you need to talk about it. However, I think this is valuable time because for some reason people are not aligned.

Where should we put the flipchart with the score? Somewhere where management can’t see it I assume? Why? I always believe that everyone in the team is a professional, and committed to doing everything (what is legal and possible) to accomplish the sprint goal. I also believe that most projects are empirical projects, that we live in a complex world. Therefore, things will not always go as expected. You can do two things, just ignore it and assume everything goes according to plan or open up so you can inspect and adapt. As you can understand, I prefer the latter. Therefore, in my opinion, there is nothing wrong showing the outside world how you feel about the sprint goal.

Does this practice solve a problem? Nope. Just like itself, Scrum doesn’t solve any of your problems. However, it can help you become more transparent, and with that, you can start addressing your problems.

Impact Matrix

Annelies and I are Agile Coaches. We often work with teams who would like to implement Scrum or other frameworks that fit within an agile mindset. You can implement this bottom down; Management decides they would like to use Scrum as a framework. Another approach is, bottom up. One or more software development teams learned about Scrum, and they decided they want to start implementing it. Implementing Scrum, or any agile methodology for  that matter, is a big change for any organization. It will take years in large organizations to implement. You will encounter people who will be happy about it, and people who will decide to leave the organization.

In this article, we would like to talk about four categories of people you encounter during a change process and how they can support your change. We’ll stick to the example of implementing Scrum for the sake of this article.


impact_matrix_promotorsTeams who decide themselves they would like to use Scrum are willing to start using it. They also realize their process will be highly affected by implementing Scrum. Teams who are highly willing and are highly affected are true Promoters of the change. You can use the people in the team to spread the word in the organization. Ask them to attend Lean Coffee sessions or share their experiences in Communities of Practice or Guilds. Ask them to write blog posts or share their experiences via internal newsletters. We call these people the Promoters.


impact_matrix_ambassadorsIn organizations there are always people who have much knowledge about certain topics, who maybe have experienced tools or techniques in the past or in other organizations. If you would like for example to implement Scrum in an organization, there will be people who have already knowledge about Scrum. The larger the organization, the more people there will be who have knowledge about a certain topic, but who are not directly affected. Those people are willing to change. However, it could be they are not (yet) involved in the change. We call those people Ambassadors. They can promote your change and are not directly involved. They have no direct benefit to the change. The Ambassadors can become Promoters in the future when they are affected by the change. It is important to find the Ambassadors. Ambassadors will promote your change because they are not directly affected, they do not have any benefit promoting the change. Except for the fact they believe in the change. Find your Ambassadors; you can connect them to your Worriers.


impact_matrix_worriersWhen Management decides to implement Scrum in an organization, you have a top-down implementation. There will be teams who will be happy; they were probably already thinking about using Scrum themselves. They will quickly become Promoters of the change. However, we know, as with every change, there will be teams or individuals who will be affected by the change but are not really into this agile stuff. “Scrum and Agile are chaos; nothing will be documented anymore, why does the Scrum Master make me stand up every day and why should we want to deliver software every day?”. Er, right. Those teams or people are not willing to implement Scrum. There can be many reasons reasons for this. People are worried about this changer. These people we call the Worriers. We assume you will understand why we call them Worriers… You will need to spend a certain amount of effort on those people. However, you would like to call in the help of other people. Realize you are not alone! We talked before about Promoters and Ambassadors. Connect Promoters and Ambassadors to the Worriers, and you Worriers can disappear like snow in the sun. Too bad, it probably won’t be that easy. However, you can talk for hours with your Worriers. You can come up with facts, your experiences, it will cost you much energy and why would they believe you? They will think you are from the Scrum Borg, trying to assimilate them. If you can connect Promotors and Ambassadors to the Worries, they can do the hard work for you. They will share their stories and experiences with the Worriers. Especially, the Ambassadors have no interest in assimilating the Worriers. The Ambassadors are not affected by the change. They support your change because they believe in it, they will show passion for the change. You cannot ignore the Worriers, you need to coach them where possible and necessary, but 80% of your energy should be focused on the Promoters and Ambassadors. Keep the Promotors willing to change and keep the Ambassadors informed and involved where possible. Link the Promotors and Ambassadors to the Worriers and allow change to happen.


impact_matrix_futureThere is another group that is not willing to change, but also not affected. We call them the Future. They can grow into Worriers, or they can grow into Ambassadors and, if you are lucky, straight into Promotors (Yeah right… be lucky). However, they are currently not involved in the project They could be located in a different department or different country. It is wise to keep in contact with the Future. You never know what the Future will bring, but you would like to think about it now and then. You need to keep your options open when looking at the Future. However, you probably can’t forget about the Future because some day the Future will be here.

In this article, we looked at four possible groups of people being faced with change. The Promotors, the people who are highly affected by the change but are also really willing to implement the change. The Ambassadors, people who are not affected by the change but they believe in the change, and they are willing to support the change. The Worriers, the people who highly affected by the change but who are not willing to change. Don’t forget about your Worriers but use where possible the Promotors and Ambassadors to get rid of your Worriers. The last category is the Future. The people in the Future are not affected by the change but also not willing to change. But it is the future. You should not worry too much about the future today. However, you should now and then think about the Future, because sometimes the future is here before you realize.

You need to think about where people fit in the matrix because it can make your life as change agent easier. Find your Promotors and Ambassadors.

If you want to learn more about how to help people to move in the matrix, attend one of our Lean Change Agent workshops.


40 ideas to spice up your retrospective

In this blog post, I want to share some ideas for hosting agile retrospectives, including some ideas on how to make a retrospective visual more attractive.

Click here to download a zip file with all the pictures. For some reason, not all pictures are always loaded correctly.

People who have worked with me, know how important I believe retrospectives are. Retrospectives are the backbone of every team, project, and organization. We can have a lot of discussion about Agile and what it stands for, but for me, when you have no regular retrospectives, things are definitely not Agile.

I am not going to explain in depth how you should organize a retrospective. I really recommend, and I mean really recommend, that you read the book Agile Retrospectives: Making Good Teams Great by Diana Larsen and Esther Derby. It is a must read if you want to learn more about retrospectives.

In this book, the authors explain a retrospective as having the following steps:

  • Set the Stage: make sure everyone feels safe and is in in the retro
  • Gather The Data: what happened, make sure everyone has the same picture
  • Generate Insights: analyze the data to find root causes
  • Decide What To Do: what are experiments that could help us to improve 1% a day
  • Closing: don’t just walk away but close the retro with an activity

For every step you can use an activity. For example, for the Gather-The-Data step, you could use “What Went Well and What Went Wrong.”

Now I hear you think… you know that activity! Good point! Many Scrum Masters, or facilitators, always use the same activities during the retrospective. Worst case, people already come in with their findings written on a sticky note to put it on the board as soon as they enter the room. When you talk to those teams, they often complain that the retrospectives are not interesting anymore, they are boring, not productive, and are considered as just another mandatory tiresome meeting.

OMG… Retrospective Hell created by a facilitator who doesn’t know how to create Retrospective Heaven… A retrospective should be fun, energetic, surprising, and people should love it!

I am not going to describe how to act as a facilitator here. I will just share the activities to make your retrospective fun and how to make things visual. To make it fun, it should be visual and colorful.

Note that most activities come from Retromat, some from the book mentioned earlier Fun Retrospectives, some I found using Google and some of them I created myself.

I always said I can’t draw, I am bad at drawing pictures, really. However, I just do it… and people seem to like it OK. As I said, retrospectives (any meeting) should be colorful.

Set the Stage

In this step, we establish the focus for the retrospective, share the plan for the meeting, establish or re-purpose work agreements, and get every person in the room in the meeting. The activities described below are for getting people to speak out. As soon as you have said something, it will be easier to say something again. You connect people to the meeting.

Visualization Example Description
prime directive

Prime Directive

Before we start the first activity, I always show this flip chart. Always, and I always read it out loud. If I have the feeling something conflicts with Prime Directive of Retrospectives, there is a major issue. An issue I need to discuss with the manager or with the team, depending on the maturity level of the team.


One Word

Ask people to describe the last iteration with just one word. Simple and effective, everyone has to speak out. You could ask people to explain their one word. Ask the team if they a pattern or something they want to discuss.


Draw The Sprint

A bit the same like the previous one. However, you ask the people to draw the iteration on a sticky note. Make sure you got stickies. Ask them to explain their drawing. The title of the flip chart is “Draw The Sprint”, hard to read. Maybe it was a bit too creative 😉



Activity from the book Agile Retrospectives: Making Good Teams Great.

Explain the first categories:

  1. Explorer, exciting to be in the retro and eager to discover and learn new things.
  2. Shopper, happy to be in the retro and open to learn new things.
  3. Vacationer, glad to be away from his desk.
  4. Prisoner, totally doesn’t like the retro and it is punishment (s)he needs to be here.

Ask people to write down their feeling on a sticky note. An E, S, V or P will do. Ask them to fold the papers. As the facilitator, mark the score on the flip chart. Make sure you put the sticky notes back in your pocket, keep it anonymous and throw them away afterwards.

Discuss the results, in case you got all prisoners; I would advise you to improvise and talk about why they feel like a prisoner.



Ask people to put a sticky note on the weather that represents for them the last iteration. The drawing bottom right is not sunny side up… but the sun.

Discuss the results and especially when there are some people feeling Sunny and some are feeling like Rain.


How Do You Feel

Ask people to put a sticky note on how they feel, or how they experienced the last iteration.

Some people will ask what does this emoticon mean? Just say whatever you think it means.

Ask them to explain why they put a sticky note on a certain emoticon. Therefore, it doesn’t matter what they think the emoticon is; they need to explain it anyways.


How satisfied are you about

Ask people to write down how they feel about team. Again make sure you do it anonymous. Mark the score, and discuss the results. You can use of course change the description or rank other things you want the team to rank.


Lego Looking Back

No further explanation needed I guess… make sure you got enough Lego 🙂


Improve Cards

Ask people to select an Improv Card that represents how they feel about the last iteration.

You can use any set of cards, as long as it triggers the ideas of people.


Your Superpower

This is an activity you can use in a retro with Superheroes as theme. The first question is, what is your superpower? Which skill or competence do you bring with you to the team?

Ask the people to write their superpower on a sticky note and in short explain it when necessary.



Ask people how they felt about last sprint or a maybe a specific topic.

Winter refers to cozy, cold, inside, slow. Spring is related to new, grow, fresh, light. Summer stands for happy, hot, outside, cheerful and Autumn refers to change, colorful, windy and getting darker.


Diamond or Charcoal

Ask people how they felt about last sprint or a maybe a specific topic.

Did they think it was perfect, a Diamant, or far from perfect, charcoal?

Gather The Data

In this stage you create a shared pool of data. Try to get facts on the table, not opinions. If you discuss a specific topic, make sure the data is related to the topic. I often combine Gather The Data with the next step Generate Insights.

Visualization Example Description

Celebration Grid

This is a practice from Management 3.0, the Celebration Grid.

It is what you celebrate, do you celebrate failure or success? Neither, you should celebrate learning. The green areas are the areas you celebrate, and there is nothing wrong to celebrate now and then you use best practices.

Ask the team members to write down the things happened in the last iteration and put them on the flipchart. Explain to them the category is not even that important, as long as the item is on the flip chart.

Be warned, this activity works great with some teams, but some teams also have no idea what to write down when they see the Celebration Grid or where to put their sticky note.


Glad, Sad, Mad and Kudo

Straightforward activity. What made people feel Glad, Sad or Mad the last iteration? Which events?

Additionally, put a set of Kudo cards on the table and challenge the people to give each other a Kudo card. As always, lead by example and give the first Kudo card yourself. This could also be the start of your team Kudo Card wall.


Four Emoticons

Ask people to write down things that happened and to put them on the flip chart where they think the item should be.

The most interesting sticky notes are when people categorize the same events/facts in different areas.


Health Check

This is a more complex activity. The activity is described here, it is inspired by Spotify.

I do this activity every three/four months.  I call it the Improvement Score Board.  Spotify calls it the Squad Health Check.



A tool to get insights on several areas at once. In this case, we talked about topics described on the flip chart. However, feel free to pick your own topics.

Make forms where you explain in more detail what the topics are, ask people to give scores on the form. In this case 0..10. Collect the forms and mark the scores on the graph or ask people to do it themselves. Depends maybe on the topics you want to discuss.

Discuss the results with the team.


Lean Coffee

Organize a lean coffee to collect data during the retrospective. The lean coffee is explained on the flip chart or you can read more about it here.

This is a free format discussion, so you just have to see which topics the team will bring up.


Liked, Learned, Lacked and Longer For

Another straightforward to collect data. Ask people to write down the things that happened during the last iteration and put them in the specific category. The categories are Liked, Learned, Lacked and Longed For.

Ask the team to group the cards them, don’t do it yourself. Make your life easy as facilitator.


Wow, Wondering or Worried

This activity is related to Scrum and can be used to evaluate how happy the team is about the different Scrum elements.

Three flip charts related to the roles, artifacts, and events of Scrum.

Just ask them to put sticky notes on the flip chart how they feel about the different items.

Next step is to discuss the outcome. Why do they think Wow it is great, or Wondering if it is OK, or are Worried about something?

You can use the three W of course for every item you would like to review with the team.


Five Dysfunctions of a Team

Yes, indeed a typo in the title of the flip chart.

An example how you can discuss and make visual how the team thinks about the five dysfunctions of a team. First, create the team Radar, and next step is to discuss the score using also the pyramid.

I used the questions from the book to collect the data. I would advise you to read the book first before playing this activity.


What happened?

I can’t make it more straight forward, just ask people to write down what happened in the iteration, ask them to group the things and discuss them.



Another activity to collect data. What do you think was super? What do you think was strange? What do you think was bad? What didn’t you dare to do?

Yes, I know Batman is written with an t.

This is basically the same activity as for example Liked, Learned, Longed For, but by using different terms, pictures you challenge the team and keep it fun.


Well & Worries

A simple activity where people pair up and write down what went well and what worried them.

Make groups of two people and ask them to fill in this form: What Went Well – What Worries You – Form – A3.

After the first step, one person of every group goes to a next group, one team members stays with the form. By rotating people, they will see items of the other groups and this will generate new insights.

After the second step, discuss the results with the whole team.


We Do & We Value

In this case I reviewed the Definition Of Done. I first asked the people to pair with someone else. Rank the items of the DoD in order which one we always do. The second-ranking was which DoD items do we  value most.

Next step was splitting the team, every team again creating the both rankings. The final step was to make a final ranking. The pair who was closest by the final ranking won a small price.I used this form to collect the data: We Do – We Value form.

The last step was to discuss the ranking. Are there items that we can skip, or items that we value but don’t give enough focus?


Well, Learned, Different and Puzzle

An activity like Liked, Learned, Lacked and Longer For of Superhero. By using different words and different drawing you challenge and surprise people again.

Generate Insights

In this stage, you try to discover root causes, patterns, create shared awareness. I often combine Gather the Data with Generate Insights. Therefore, I only have one example in this category.

Visualization Example Description


As it says on the flipchart :).

Ask people to build something with Lego bricks, which represents a possible next step for the team. This will make people think about issues and possible solutions.

Discuss the creations, ask people to explain their solution.

Decide What To Do

Finding root causes is already difficult but defining actionable items is even more difficult for some team members. Read my blog post about how to create actionable items. I don’t have that many different activities for this stage. It is the role of the facilitator to challenge the team to come up with actionable items.

Visualization Example Description

Next Action

Just write the what, who and when on a sticky note and put it on the paper. If possible you can group them per theme or goal.


Who What When

Almost the same as the previous activity. However, this time without goals. Write down who will do the action, what the action is, and when the action needs to be done.

Identify action is one thing, make sure they are visible for the team and the team is disciplined to execute the actions.


SMART Actions

Another flip chart that describes how the team can define their actions. Just another format.

In this case, you can use the template at the bottom of the flip chart to help the team define SMART actions.


The final stage of a retrospective, you review the retro, show appreciation to each other, and make also apply a short retro on the retro itself. Some of the closing retrospectives can also be used as starting activity.

Visualization Example Description

Energy Level Next Sprint

Ask the people to put a sticky note on the energy level that represents their eagerness for the next iteration. If the energy levels are low… there is work to do.



Ask the attendees to put a sticky note on the drawing that represents the value of the retrospective for them. If they all say it was low… there is again work to do.


Kudo Card Wall

Ask people to write a Kudo card. This could be the start of a Kudo card Wall in your team. Lead by Example, make sure you also give one or more Kudo cards.


One Final Word

Ask attendees to write just one final word on a sticky note. Ask them to explain the word. Ask them to write a word related to retro, you could also look forward and them to write a word related to the future.

Be careful, the retro is done but this could start a new discussion.


Lego Feedback

Ask the team to be creative with Lego bricks and build something that provides feedback to you. The colors will show how much they valued the retro.


Retro Dart

Ask the attendees to play “darts” with sticky note. A quick way of getting feedback. Depending on the score… there is again work to do.



An activity from the book of Esther and Diana. What is the Return Of Time Invested in the retro. Explain it should be about how they feel at this moment. The actions are not executed, but how do they feel at this moment about the time invested?


Team Super Powers

Ask the team to write down what they think is the superpower of the team. A positive closing of the retrospective.


Wow or Happy

You can ask the team to write what surprised them during the retro and/or what made them feel good. You can also just ask the team to put a sticky note on one of the emoticons when they leave the room.

A quick way of getting feedback about a topic. You can use this also at the end of a meeting.



Create your own twitter wall. Ask the attendees to write in maximum 140 characters what they would like to say about the retrospective.


Simple Question

Ask people to answer one of the question, one thing they learned or a thank you to someone. A positive closure of the retrospective. By having two questions you give people the opportunity to chose, but you could also decide to just have one question of course.

To close this blog post some general tips about using flip charts during the retrospective.

Don’t use regular white board markers to create your flipcharts. Buy quality markers, from example Neuland. As my dad as carpenter always says, when having the right tools, the work is already half done.

Always use sticky notes on the flip charts. This will make it very easy to reuse the flipcharts. You will build up your own personal library of activities. There is nothing wrong using the same activity, but not every retrospective the same activity.

Just start experimenting, just do it. The first flip chart you will draw will maybe look bad, but you will improve every retrospective.