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, 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 😉

0

Scrum Games
Welcome to yet another Scrum Blog on the web. In this blog I want to talk about my experience with Scrum and other agile processes and techniques. In this first article I want to talk about the “Ball Point Game”… On Monday and Tuesday this week I had my Certified Scrum Master training in munich. Our trainer was Simon Roberts who did a great job. During the training we played the “Ball Point Game” which was originally created by Boris Gloger. They also played the game at the Scrum Gathering in Munich last week. To play the game you need at least 20 balls (we had 50), e.g. tennis balls and form a circle with your team. The objective of the game is that everyone of the team touches the ball at least once and to pass as many balls as possible. The rules of the game are:
  1. Each ball must have “air” time, so giving the ball from hand to hand is not allowed
  2. It is not allowed to pass the ball to the direct neighbour
  3. Every team member has to touch the ball at least once
  4. At the end of a round the ball has to get back to the one who brought it into the game
  5. The whole process is time boxed (2 minutes “sprint”, 1 minute review)
The game should start with a 2 minute discussion on how to start. After that 5 iterations are started (see 5.) and after the 5 iterations the results of the iterations should be discussed. As you can imagine our first round wasn’t really exciting. We were able to pass 3 balls before the first sprint ended 😉 In our first sprint review we decided to change the process and were able to pass 28 balls, then 42 and the last two sprints 53. To create some pressure Simon told us between the 4th and the 5th sprint that he had a team that were able to pass 85 balls which was a lie 😉 But the result was that we tried harder but couldn’t improve our velocity. The ball point game gave us a great impression how velocity increases sprint after sprint in agile scrum teams. We also found out that we lost more balls if we tried to get faster to reach a higher velocity, which especially happend after Simon told us about the 85 balls 😉 I think I’ll use this game in my next project as Scrum Master.
2