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.


Business, Leadership
You are a manager and hate remote teamwork? Here are three ways to sabotage it:

Put teams in time zone as far away from each other as possible

If teams work in close time zones, they can use their working time to collaborate. But that is exactly, what you like to avoid. Therefore, make sure that the difference in time between all your teams is as big as possible. The best is to have a twelve-hour time difference so that one team is going to bed, while the other teams are starting to work. That way it always takes a day to get an answer to your emails which slows down communication. Scheduling a meeting, that fits for all parties is nearly impossible. Isn’t that great?

Don’t allow modern communication tools

Give your team the worst communication tools. If possible, even prohibit emails (while telling your teams, that they should make use of face to face conversations). If you already have some tools in place, make sure to limit them to audio only. Video or screen sharing is only allowed for higher management (yourself) or needs a complicated application process (signed on real paper by managers around the world). You know, because of security. Somebody could walk by a meeting room and see some confidential information. Scary…

Don’t let them meet in person

The worst thing that can happen is that the whole team meets in person from time to time. This would lead to a better understanding between all the team members and eventual to a better (remote) team performance. You don’t have any budget for that, have you? That was exactly the reason, why you created that remote team: to save some money. So you cannot afford any travel expenses for those cheap workforces (That’s at least what you tell them).

Do you have any other ideas to sabotage remote teamwork? Put your ideas into your comments.


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 Testing
Your test team works too effectively? Are bugs reported in no time? The communication between the testers and developers is perfect? All bug reports make sense? Then it is about time to sabotage the whole thing. In this blog post, you’ll learn 10 things to sabotage any successful test team so that finally everything gets back to normal…
  1. Eliminate any communication between developers and tester
The best thing you can do is to create some nice silos. Put all the testers in their own room/building/department. It’s even better to move them to a different country with a nice time zone (+/- 9 hours or more). That way you can ensure that the communication between the testers and the developers are effectively handicapped. Next step is to prohibit any communication via phone or chat and only rely on email and snail mail.
  1. Never supply enough testing devices with different configurations
Testers always complain that they do not have enough test equipment. Additionally, they want to have different configurations for their testing devices, e.g. different screen resolutions. But who the hell needs all this stuff? If the developers say, their stuff is running in all scenarios, you can truly take them at their word, right?
  1. Never ever make the original requirements transparent
The last thing a tester wants to see are boring requirements. Explorative testing is all you need to ensure the quality of the product. Requirements only puzzle the simple mind of a tester. They will find out on their own, how the product works.
  1. Inform the test department as late as possible (earliest 2 weeks before the release)
If you give testers to much time to test your product, they will find more bugs which have to be fixed, which will ultimately crush your deadline. We are all on the same page if we say, that nobody is eager to go there, right? So, the best way is to make the testing phase as short as possible. And if you are lucky, there are no testing “resources” available at that short notice, and you can fully rely on the tests the developers did.
  1. Never use dedicated testers
Lately, more and more people are asking for at least one dedicated tester in their teams. But who will pay for this? And to be honest, this little bit of testing can be done easily by the developers alongside their normal work. Developers anyway know best, how to test their stuff.
  1. Allow only manual nonreproducible tests
Reproducible tests lead to reproducible bug requests. It’s always better to just do some wild testing were nobody is able to tell you, what exactly lead to the strange bug they found. This ultimately leads to more difficult bug fixing, and this is exactly what we want.
  1. Never change an already existing test case
Writing tests is an intricate thing. Unfortunately, the software is changing all of the time, which means that you have to adapt those tests. What a waste of time! Instead, it is much easier to deactivate the (automated) test which also has the advantage that there are no more of these bugging error messages on the build server.
  1. Use intern for testing, only!
ISTQB® Certified Tester? Who needs something like that? They are way to expensive and the budget for the QA department is already consumed. It is much cheaper to hire some interns who will click through your software and be easily exchanged every six months. And there is another advantage: interns will never come up with such crazy, newfangled ideas like code reviews and other nonsense.
  1. Never tag any release
Just throw some build over the fence to your testers without knowing the exact version. Never tag or version anything. This makes it way more difficult to write reasonable bug reports. And if they report a bug, a developer can just say: “but it is working on my machine….” So much fun.
  1. Treat testers as incarnated evil, who only want to destroy your product
Testers are evil, who supposedly destroyed stuff already as a toddler. And they want to destroy your product, too. Avoid any contact with them and reduce your communication to a minimum. Refuse any help from them as they will use this knowledge to find even more effective ways to bring your product to its knees. I even heard about secret tester meetups and community of practices. I don’t want to know what is happening there.   If you have some other ideas how to sabotage your test team, let me know in the comments.