Good Contents Are Everywhere, But Here, We Deliver The Best of The Best.Please Hold on!
Data is Loading...
Your address will show here +12 34 56 78
Agile, Basic Scrum, Retrospective
The problem with Scrum (or any other agile framework) is that it won’t solve any of your problems. It’s like your evil mother in law, pointing at all the things that are not working or look strange, e.g. not being able to deliver something valuable at the end of a sprint. Scrum will make all your dirty little secrets visible, and that’s it. Now it’s up to you to tidy them up. Nobody else will do it, but you. If you ignore it, nothing will change, and none of your problems will vanish. Sorry, but continuous improvement is at the core of agile.

Fortunately, Scrum will support you to experiment, by providing a safe to fail framework, where you can try new experiments and immediately check if they had the desired effect. Retrospectives are giving you the time and space to inspect and adapt. It is also, fortunately, that there are plenty of books and blog posts, where you can find millions of ideas about what you can try next. Also, the agile community is there to help. That’s excellent news, isn’t it?

But if you are still waiting for your manager, your organization, your colleague or the cleaning lady to do the first step, you’ll wait forever. Change starts with you. Be the change you’d like to see. Lead, by changing the way you work and inspire others. I know that it takes some courage to do so, but that’s why courage is one of the values of the Scrum framework, right? Don’t ask for approval! Just do it and apologize later (if needed). Thank you.

Agile, Retrospective, Scrum Games

Do you want to pimp your retrospectives in 2017? Here are some quick and simple ideas to improve your them.

1 – Bring food

It is always a great idea to bring food to your retrospectives. It can be such simple things like some salt sticks or cookies. You will see: This simple trick will set a great tone for the rest of the retrospective. You can read more about it here.

2 – Set a goal for the two month

Most retrospectives start on a clean greenfield without taking the results from the last retrospectives into account. Instead, set a goal for the next two or three month, e.g. improve code quality and focus on this goal in the upcoming retrospectives. This way, your retrospectives have a clear purpose, and you only discuss topic related issues. Additionally, you can build on the outcomes from the last retrospectives instead of starting from a clean greenfield. You can read more about if here.

3 – Experiment

We all work in a complex adaptive system, which means, that it is unpredictable. You’ll never know if the tasks you defined in your last retrospective will have the expected outcome. That’s why I prefer to talk about experiments instead of tasks. When you start an experiment, you want to proof that your hypothesis (our expected outcome) is true. If not, you just try another experiment, until the issue is solved. Additionally, it invites the team to be bold and try something new. 

4 – Discuss your improvements in the planning

One of the biggest problems with retrospectives is that the defined experiments are not executed because the team forgot about them or just didn’t have the time. To avoid this problem, put your experiment into the backlog for the next planning and handle it like any other backlog item, including the task breakdown in planning two. Now your experiment is part of the sprint backlog and can be easily tracked and won’t be forgotten.

5 – Focus on ONE thing

Another mistake that is made quite often is that the team wants to execute more experiments than they are able to. Instead, focus on exactly one experiment. This helps you to ensure, that there is enough capacity to execute the experiment. Nothing is more annoying than a list of experiments that nobody worked on. Pro tip: Don’t throw away your other brilliant experiment ideas, but put them in an experiment backlog. If there is some capacity left, you might start one of these, too. Furthermore, you can shorten your next retrospective by just selecting the next experiment with the highest probability of success from that backlog.

I hope you like these little improvements. I’d like to hear from you if you tried them out. Happy retrospecting 😉


The speedboat retrospective is one of my favorite visualization techniques I use in retrospectives. The origin of this technique goes back to Luke Hohmann, who presented it as one of the innovation games in his book “Innovation Games”. The idea is to draw a speedboat on a flipchart and ask the team: “If our team is this speedboat: What anchors are holding us back and keeping us from getting faster/better.” Then the team collects all their ideas on Post-Its, puts them below the boat and draw a line from the boat to the anchor. keep reading

Agile, Retrospective, Scrum
The new year has just started, and it’s time for the next steps to rile your teammates. So let’s have a look at one of the activities in Scrum that can be easily sabotaged: the retrospective. Here are ten proofed ways to wreck any retrospective:
  1. Keep the retrospective as short as possible. No need to invest too much time in this meaningless gathering.
  2. Only focus on negative events and ignore any positive things. This is the only valid path to improvement.
  3. Handle a retrospective as any other meeting. Sit around a table and just talk.
  4. Ignore the complexity of the system around you. There is always a cause and effect.
  5. Always use crappy material such as cheap post-its that quickly fall from the walls or old pens that hardly write. keep reading

Last week I talked about “Spicing up you retrospective” at the ALE2012. I did a similar talk in June at the ACE!Conference in Krakow. But after the talk in Krakow, I had a chat with Bob Marshall and he pointed out that fun isn’t the (only) answer to make retrospectives better. He also pointed me to a blog post where he wrote about these issues. So, the following article is mainly based on his ideas.
Retrospective Challenges
For me, there are two main retrospective challenges:
  • Create a motivating environment and keep the people them engaged
  • Work on the identified items
On first sight it seems that these two challenges may be caused by:
  • Repetition –> Boring Retros
  • Same problems –> No effect
  • No responsibility
  • Tasks are not visible
  • Tasks are too big
But these are only the things you see on the surface, if you dig deeper you’ll find the real root causes.
Inject Purpose
IMHO, the root cause is a missing purpose. Any retrospective without a purpose is a complete waste of time. (the same applies for any other meeting). It doesn’t make sense to change your retrospectives regularly and introduce new ideas as long as there is no purpose behind. But how can you inject purpose into your retrospectives? The answer is: by using hypotheses. To do so, I adapted the original retrospective flow by Diana Larsen and Esther Derby the following way: keep reading

Retrospective, Scrum

More and more agile teams have the problem, that they are not collocated. If you work in a distributed team, you know how difficult it is to stay in contact. It gets even worse, when you have a big time shift between the teams. But in such situations it is even more important to do a team wide retrospective. That’s why I created a checklist for retrospectives in distributed teams.