Three piglets retrospective

The second retrospective for the retrospective challenge 2020 is the three piglets retrospective. This retrospective was hosted for a large project group, as well as for the team that I am the Scrum master in. The goal of the three piglets retrospective was to look at an upcoming deadline, and see how the group felt about the upcoming deadline.

three little piglets


The three piglets retrospective is based of the fable the three little pigs. The goal is to divide the last iteration, or time period in the three categories of the houses of the pigs. Check google for pictures of the houses, or let the best creative side of you draw the houses on a whiteboard.

The team then will put post its about the last iteration or time period in one of the three categories. Keep in mind, this doesn’t have to be about technology, it can be about anything. Stakeholder interaction, decisions by management, basically anything that impacted the team.

House of StonesEverything the team is extremely proud of, no chance the big bad wolf can blow away this house. Example: We are proud that the pipeline didn’t crash a single time this sprint, since we fixed it last sprint.
House of sticksSomething the team sees that can be improved, but is not in the danger zone. Example: We improved our test cases which helps us prevent bugs, but we do not have all cases tested we would like.
House of strawSomething the team is extremely worried about, any wolf can make this into a danger. Example: This legacy project is on the verge of collapsing, we need to spend some time on it!
three piglets retrospective

When the team members have no more post-its to add to the retrospective. It is is time for action points! The starting point for the action points can be: “How can we make sure our house of sticks and straw, turn into house of stones?“.


The three piglets retrospective is an variant one of the most basic retrospectives. If you need a basic retrospective without too much of a specific goal in mind, this is a safe bet. I have noticed that the fun factor definitely helps in making the team feel more at ease. Getting the team to laugh and have fun breaks the ice, and will result in a better retrospective.

To summarize the positive sides of this retrospective:

  • Generic retrospective that will fit in most cases
  • It has a high fun factor, which usually helps in making the team feel more at ease.


The downsides of the three piglets retrospective is the fact that it is a generic retrospective. It is a good solution for most retrospectives, but more specific retrospective forms might yield better results in some cases.

It is good to keep in mind that if you work with distributed teams across the world, not all team members might know the three piglets fable. I noticed during one retrospective with team members in Mumbai, that they where not familiar with the fable. If you need to explain the fable first, it might not be as effective as it would be with team members who knew the fable growing up.

To summarize the downsides of the three piglets retrospective:

  • Generic retrospective, more specific forms might yield better results.
  • Culture differences, not all team members outside of Europe might know this fable, and the retrospective might be less effective, if you need to explain the fable first.

Conclusion of the three piglets retrospective

I would recommend using the three piglets retrospective if you do not have a specific goal in mind for the retrospective, or if the team is in need for a good laugh. If you have a specific goal in mind, it might be better to pick one of the retrospectives that is suited for your desired goal.

4 lessons I learned as a starting Scrum master

I recently saw that I passed my 3 year mark as a certified Scrum master. This seemed a good moment for me to reflect on my experiences so far, and take a closer look at the lessons I learned as a starting Scrum master.

To give a little bit of context, I started as a part time Scrum master, part time developer at the company I currently work at. During the last 3 years a lot has changed, in terms of my own personal development, how the company handles agile and scrum and the teams I was scrum master for.

The following lessons learned as a Scrum master are what stuck to me as the most important lessons, or the most “aha” moments I had.

Lessons learned as a starting scrum master

Conflicts are not always bad

In the first team I was a Scrum master in, there where several conflicts. Without the experience I have now, I saw those conflicts as an impediment to immediately solve. If the team is not fighting about code standards, which libraries to pick or at what time the daily should be, they could be doing actual work. On my two day training for CSM1, the trainer talked about how conflicts are part of the development process as a team.

In my nature is being a peace keeper, but when I resolved conflicts before they really started, I took away the chance of the team to overcome them, learn from them and become closer as a team. This resulted in the team continuing to work as individuals, and never got close enough to really get into a mode where they could collaborate, without me as an conflict solver.

Sure, not all conflicts should be played out fully. some conflicts can be more harmful than the lesson they learn. You can compare it to being a parent (or so have I been told). Sure you want your children to learn from their mistakes. Letting young children go outside without their jacket, is something they can learn from. But you will not let them cross a busy road, on their own.

Am I a Scrum master or a developer with extras?

All the professionals around me at the time that where Scrum master where basically just senior developers with a bit more responsibility, especially with the part time roles of both Scrum master and developer. This lead me to believe that the role of a Scrum master was the “frontrunner of the team”. You should prepare all tickets technically, make sure the Scrum artefacts and ceremonies are done and will be held responsible if the team is not running.

The first times I started realizing I was just a senior developer with some extras, was during my Scrum master certification. But the truth is, my big “aha” moment came when I read Coaching Agile Teams by Lyssa Adkins. This lead me to re-evaluate how I saw my own position. As the biggest changes, let the development team really be in charge of the development part, so the ownership and feeling of commitment will grow. And focus more on other areas, for example making the whole organisation more agile, shifting my style from leading to coaching or giving workshops.

Adapt your style to the phase your team is in

At the time I was asked to become a Scrum master for a new team to be formed, I was a developer in a team that was in my eyes, really close to being a performing team. Years later I still feel like those where “the good old days” when I look back on being able to deliver value fast.

The team consisted of some very experienced developers, and found a mode of working which worked for them. The Scrum master at that moment could do a more loosely role, as the team was responsible enough to make sure we kept running.

At that moment when I switched to a new started team, I tried to copy what I saw from my Scrum master in the previous team. But that did not work as well. Who could have thought that the more loosely style would work for experienced developers with experience in Agile, and working together for 2 years, but did not work for a group of developers that have not worked together before, and have not worked with Agile either.

Tuckman stages of group development describes that there are 4 different stages for teams, that all require a different style of coaching. As a Scrum master in a Forming or Storming team, the style of a more strict Scrum master is will benefit the team more, while a Norming or Performing team can benefit from a more loose role,.

Being a part time developer does not work

I can be quite honest splitting up your time between a developer and a Scrum master does not work. If you truly feel that improving Agile and the team, or even your organisation is important, it will take all your time. The pitfall with being a developer on the side is, that I noticed that instead of doing gemba walks, listening to customers or experimenting with new approaches I coded.

This results into Scrum masters doing the bare minimum, to make sure they don’t lose any time that they could deliver features. While the true power of the Scrum master lies in getting the organization on board, making the team more empowered and look out for continuous improvements. And the trade-off to me was; Do I want to put minimal effort into the growth of the team to make sure I can develop 5 story points per sprint? OR do I want to make sure that because of my full commitment as a Scrum master, the team can do 5 extra points (and even more) without my input as a developer?

If after all of this you still have the feeling that the Scrum master position is not full time, I advice you to read this post: 42 Tasks for a Scrum masters job


The Scrum master role I saw when starting is quite a lot different from how I fulfil that role now. I would say my perspective has changed for the better, and all of these lessons learned as a Scrum master help me become a little bit better every day. The most important lessons for me where:

  • Don’t try to prevent all conflicts, let the team learn from them.
  • Take a good look at your own position. Don’t only follow the examples you have at work, but also look at outside sources how they fill the position.
  • There is no 1 solution that will fit all teams, adapt your style to the phase the team is in.
  • Be a Scrum master full time, you will be amazed at what you can do.

If you are interested in more of my blog posts, check out the challenge I set for myself in the Retrospective challenge 2020

This team / That team

The first retrospective in my retrospective challenge for 2020 is the This team / That team retrospective. This This team / That team retrospective was hosted for a larger project group, and the reason we did this retrospective was to focus on desired behaviour inside the project, and how to change unwanted or unpleasant behaviour into desired behaviour.


This retrospective form can best be explained by the catchphrase of this retrospective. “Don’t be this team, be that team!”. You need to split a whiteboard in 2 big columns, and write “this team” on top of the first, and “that team” on the second column.

This team / That team retrospective

The group needs to come op with things they would like to see in a team, and put that in the “that team” column, and all reasons why a team is not easy to work with, can be put in the “this team” column. Ask the group to go back to all teams they worked with in the past, and what made some teams awesome to work with, and some teams difficult.

The power of this retrospective is the positive aspect. For every “negative” thing someone puts on the board, you as the host can bend it into something positive. “So you would say X is something that would make this team unpleasant to work with, what would be the positive counterpart to make this team pleasant to work with?“. An example of this is, that one might not like to work with an extremely reactive team. and will create a post on the other column with “pro-active”.

When there are no further post-its to put on the whiteboard, it is time for action points. The focus on the action points will be “What things can we do the next iteration to be more That team?”.

This retrospective can also be executed in several other forms, one example is “this guy / that guy”.


This retrospective is great in making it a positive experience, if the group has a negative outlook on the last iteration or period, you can turn it around to how they would like to see it in the future. Especially for some group members that don’t have a positive outlook, this retrospective is a good fit. In summary the positive points are:

  • Great for having an positive experience
  • Good to address communication and behaviour type improvements
  • Is not per say focussed on the last iteration, so can be used in other contexts


In terms of getting really clear action points this retrospective is a bit more difficult. My experience is that a lot of these action points will be in the communication or attitude area, and less focussed on tech stuff. In my experience the action points will most often look like:

  • Acknowledge good behaviour
  • Be a good example, start with X behaviour

Which can make it more difficult in the next iteration to check of all action points, as there are no real acceptance criteria. I would advise to discuss the action points in the next retrospective, and let the team decide if they where executed to a level where the team is content with.


The This team / That team retrospective is a good fit if you want to focus on the positive, and feel like there are some opportunities in communication and attitude. If you need solid action points you can check off, this might not be the best fit.

What do you think of the This team / That team retrospective, and would you use it? Let me know in the comments.

Retrospective challenge 2020

At the start of every year, the question “do you have any new year resolutions?” is asked frequently. During my professional life as a scrum master, I notice my preparation of retrospectives could be improved. After some consideration I came up with the retrospective challenge 2020. As a result, I came up with the following experiment:

“If I write a blog post on the form of every retrospective I host, I will prepare them better”

An example of how me doing the retrospective challenge 2020 could look like

I notice that in all the retrospectives I host, My own team, other teams or larger project groups do not get equal preparations. I host, or co host the following kind of retrospectives:

  • Development teams (for my own team, or others)
  • Large project (company wide)
  • Departments

My reasoning is, if I write a blog post about the retrospective form, I need to prepare them better, because I want to write a good post, with a solid base.

My inspiration usually comes from, brainstorming with other scrum masters, Twitter, or creating a new form based on what the retrospective needs. This blog might be a good place to bundle all the forms I used, and came up with, to document the process, and hopefully re-use them in the proper situation later.

What can you expect from me in 2020?

For every retro I (co) host, I will write a blog post. This will result in +/- 20 blog posts in 2020. All the blog posts coming from the retrospective challenge 2020 can be find in the retrospective category:

Are there any retrospective forms you would like to see a blog post about, or do you have any work related new years resolutions of your own? Let me know in the comments!

Finding your priorities with the Eisenhower retrospective

If you are in need of an agile retrospective that will help you determining which issues are worth resolving, and which do not have any value? The Eisenhower retrospective can help you with that.

Eisenhower Matrix

First of all, let’s take a look on what the Eisenhower Matrix exactly is, before we dive into the retrospective. It is called after the former US president Dwight Eisenhower, and the goal is to score our actions into 2 categories: Urgent & Important. Our actions can be scored on whether they are important or not important, and if they are urgent or not urgent. The matrix looks as follows:

Afbeeldingsresultaat voor eisenhower matrix

When we scored our actions, they can be placed in 4 categories:


This is the magic zone, everything in this zone is urgent and important. Actions in this zone should be picked up as soon as possible, and have priority over the other ones.


Actions in this category are important, but not urgent. This means you want to do these action items, but instead of doing it right now, you should plan these action items.


Actions that are not important but are urgent, are actions that you should not do yourself. These are prime candidates to delegate to a competent co-worker. Are there any co-workers for who these actions are Important? If they are, great! Delegate it, but if they are not, it might be time to reconsider your priorities.


Actions in these categories are not important and not urgent. Why do we have actions here? In our personal life, these usually are things that are fun to do. If any work related actions end up here, it is best to eliminate those actions.

The retrospective

Since you now know what the Eisenhower matrix is, and how to use it to determine what to do with our actions. Lets take a look on how we can use it in a retrospective form.

Gathering insights

First of all, we need a retrospective form to gather action items to prioritize. There are several forms to do this, but they all point to the basics of a retrospective: What went well?, what didn’t work? What should we start doing? I usually use to find a form. You cannot go wrong with the starfish ( or the hot air balloon ( Once you gathered insights, we can move to the next step

Placing them on the Matrix

In preparation of this retrospective, print the matrix, or draw it on a whiteboard. As a next step, we want to cover the name of the zones (Do, Schedule, Delegate, Eliminate). Nobody wants to place their actions on the eliminate zone if they know if before hand 😉

When you have all the actions from the previous activity, gather the group around the matrix. Grab the actions, and let the entire group decide where should each action item go.

The reveal

It is time for the big reveal. When every action is placed, reveal the titles of the zones. Start with the eliminate zone. Apparently no one found these actions important and urgent, and we are going to eliminate these.

The delegate zone is not a category you want to focus on for this retrospective. Discuss the zone briefly, and move to plan. Any actions in plan, can be assigned for people to plan in the long term.

Finally, we are in the magic zone. The do zone. These are the real outcome of this retrospective. The entire group decided these actions where worth to act on now. Discuss each action one by one. If anyone speaks up about an action, assign them as the one to work on that action, if they feel this is important, they are more likely to do it.


The Eisenhower retrospective can be used to find priorities when they are not completely clear. Have you tried this retrospective? Let me know how it worked out!

Why you should put your code on an opensource platform

As a beginning developer it might be a bit frightening to put your code on an opensource platform like Github or Gitlab. You might have a feeling that it is not worth to share your home projects with other people, or might not have seen a reason if you are the only one working on a project.

In this blog post, I will provide what in my eyes are the major advantages of using an opensource platform for your personal projects.

Git experience

When I stared developing some hobby projects at home, I stored them on my local computer. If I ever wanted to “release” something I wrote, I had to FTP it into a webserver. This release-flow continued on some internships I did years ago. Until I started working at a company where they used Git to store and manage their code. A few years later, most respectable companies use version control one way or another.

If you have never worked with Git, or another version control system, you need to get a grasp of the concept. If you can start getting experience with Git during your home projects, it can be an big advantage if you want to start at a company where they use it primarily.

Second of all, you can use it to quickly try some ideas on your project, without having to worry on losing your previous progress. You can simply create a branch and try your idea. If it works, merge it into your master branch, or remove the branch if the idea is unsuccessful.

Sharing code

With you code shared on an opensource platform, it can be extremely easy to share your code. If you want some feedback, or have other questions for another developer, you can simply share the link to your project, or even to a file itself. No need to copy files, or worry that people have an outdated version of your files.

It is becoming more and more common to use a Github or Gitlab profile on your resume when doing an interview for a developer job. It is an easy way to show what you are capable of, and what projects you have done in the past.

Besides that it is also possible to see other projects, follow them, and learn from them. Is there a project that is similar to yours? Try to see how they resolve a problem.

Try builds

How do you know changes to your code did not break your project? You can try to make automated builds for your projects. A popular choice is Codeship or Travis. But there are more tools that do similar jobs.

With builds you can automate several steps to make sure your code still works as intended. Some popular steps in there are running unit tests, running a linter to make sure your code is according to coding standards, and even automatically check if some of your dependencies have vulnerabilities.

If you are interested in getting more in depth with builds, I plan to write a blog about starting with builds which will explain all about it.

Small warning

A small warning to this post is to watch out what you commit. A mistake is easily made, and there have been people who have committed production passwords/keys to publicly shared repositories.People with malicious intend can use them to their advantage. An example is this blogpost:


I hope to have given you several reasons to try out an opensource platform. Do you have some additional reasons to try an opensource platform, or other comments? Let me know.