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 😉


Agile, Retrospective, Scrum

In the normal case, every retrospective starts with gathering the data from the last sprint. Often enough it happens, that the team discusses the same topics again and again and it feels like not moving anywhere. But still, we insist on starting every retrospective from scratch.

Instead, it could make sense to focus on one and only one topic for a predefined time frame and make this topic the central theme for the upcoming retrospectives. Just imagine, that the team has quality issues with their current product already for quite some time and everything they tried so far, was only a drop in the ocean. Now, the team decides to define the topic of improving the product quality as their main theme for the next three month. This means that every retrospective in the next month will explicitly care for getting rid of these issues.

It makes sense, to do a short rating of the theme at the beginning of such a timeframe to get a feeling where the team is currently at (e.g. between 1 and 10). Based on this rating, the team defines a goal they want to reach in the next month. Only after that goal has been reached, the team will focus on another topic. It’s a bit like a task force approach.

At the beginning of a themed retrospective, the experiments of the last one are validated. The team checks, if the defined experiments were successful and the initial hypothesis was true. If yes, they can focus on the next issues. If no, they can define the next experiments to tackle it, by considering the potential root causes for the fail (Generate Insights).

The advantages of such an approach are the clear focus on a certain topic and the prevention to talk about the same things again and again. At the same time, you get the purpose back into your retrospectives, because everybody knows, what goal you want to reach by doing them.

What do you think? Could this be a helpful approach for you and your team? Please, leave a comment.


Agile, Agile Coaching, food for thought
You may have seen this: A company decided to become agile and introduced an agile framework e.g. Scrum. The management hopes for higher product quality, a better TTM (Time To Market), an improved risk management, finally a project that is on time and budget and more. Although they implemented Scrum by the book, after about half a year, they realize, that none of the promises came true. The Scrum Master is searching desperately for another, a better tool he can try next, but none of them has the desired effect. Step by step the team is falling back into their old habits and in the end they say: Scrum does not work. And they are right! Only by putting a new shiny saddle on your dead horse, you won’t get it running again. To understand what happened one has to know, how Scrum was created. 
Success is never because of the process but always about the people – Marc Löffler
keep reading

Agile, Kanban
In the past I observed more than one Scrum team, that moved to Kanban. The reasons for that were manifold, but seldom the right ones. Here is a short list:
  • “All these Scrum meetings take too much of our time.”
  • “This Scrum thingy doesn’t really work for us, let’s try Kanban.”
  • “In Kanban you only need a board with the columns ToDo, Doing, Done and you can start. Isn’t that awesome?”
  • “These bi-weekly retrospectives are annoying. I like our process as it is.”
  • “We are not able to deliver a potentially shippable product at the end of our Sprint. In Kanban there is no such rule…”
  • “We have to adapt our planning continuously; this is not needed in Kanban.”
  • etc…
keep reading

Agile, Basic Scrum, Scrum
Once I had the pleasure to work in a company, that decided to introduce a global development process. This global process was introduced at each subsidiary, that took part in the development of new products. It didn’t matter if it was a pure software product or simply a piece of hardware without a single piece of electronics. One size fits all. Of course, it was possible to tailor the process to your needs, but in the end, you had to follow about 90% of the process elements. This lead to insanely long product development cycles. Even quite small products ran at least six months, because of the overhead the process introduced. Additionally, the higher complexity of software projects was completely ignored. As you may have guessed, after reading these lines, I believe this is a very bad idea. Every process that ignores its context is foredoomed. keep reading