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

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.

2

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
0

Agile, Basic Scrum, Scrum
There thousands of teams out there, that are using Scrum. But I assert that only a small fraction of them is really “living” Scrum and therefore successful. You can spot great Scrum teams based on the following list:
1 – Continuous Learning
A lot of agile teams become lazy over time. Especially, if it seems that everything is running fine. They are laying back and the continuous improvement process gets stuck. They stay in there cosy and warm comfort zone and nobody wants to take the next step. This leads to a decreasing quality of the team’s results and the advantages of an agile process vanishes. If a Sprint Planning looks the same after practicing it for half a year, the teams is NOT agile. In an ideal case, the Scrum process completely changes during the course of a year. keep reading
1

Scrum
It’ about time to give the Product Owner a chance to fight back. With the help of Heiko Weltin I created a list as a base for the revenge. I hope you’ll like it:
  1. Create your product backlog without any prioritization. In the end you need all of the features before you can bring the product to the market.
  2. Only create the headline of your user stories and don’t add any additional content, even if the team asks. You can’t prepare everything for the team.
  3. Only use two types of priorities: “Urgent” and “Can be done later”. Anything else would be a waste of time.
  4. Always promise release dates and scope to your customer without talking to your development team upfront. You are a skilled estimator.
  5. Always add one task to a user story that keeps the team from finishing it. The Definition Of Ready (DOR) is for wimps. keep reading
5

Basic Scrum, Scrum
It’s about time to nag the product owner, isn’t it. Fortunately, there are plenty ways to do this. To help you in your quest to do so I created a list of 10 proofed ways to drive your Product Owner crazy:
  1. Five minutes before the Sprint Review is the right time to tell your Product Owner that your team wasn’t able to finish anything. It is even more fun, if this was a planned release. Transparency is for milquetoasts.
  2. Don’t invite the Product Owner to any Scrum meeting. He is a chicken and you are the pigs, right.
  3. Ignore the Sprint backlog and work on the features you like the most. Who cares about the Product Owner’s vision?
  4. Assign all tasks that were created during your retrospective to your Product Owner. He is the root of all evil and responsible for all the problems in the project.
  5. Don’t attend the Sprint Review. You already know how your product looks like. keep reading
2

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
5

PREVIOUS POSTSPage 1 of 3NO NEW POSTS