agile

In the basic retrospective formats like "What went well? What didn't?", everyone has the option to state things about the last sprint. Things that worked out well - the plus side - just as things that didn't work well - the negative side. Now there's usually only a single rule for almost any retrospective format: Public blame is not allowed.

This blame-free environment is also the crux: How would you be able to deliver a negative message without the option of blaming? Read on to get some tips of better message transportation in order to gain more.

It's important to split big chunks of work into smaller ones to handle risk and uncertainty. What should be done if a User Story can't be split, though?

Small User Stories are an important part of incremental and iterative software development. It's not always easy to split large Stories into smaller ones. Therefore, I would like to introduce 5 simple techniques for Story splitting.

We make estimates for the work planned. The team gets the estimates by playing planning poker. Our estimate drivers are complexity and uncertainty. So far, so normal. But what is this "uncertainty" and how does detail fit into the picture?

Having an agile mindset is part of the eMundo spirit. We have lots of agile projects, so basically everyone must know about this. Yet, sometimes, doing agile software development is harder than expected.

To get around this, we developed a game - "The Temple of Grog" - that tries to teach the contents of the agile manifesto without actually doing software development. This makes it much easier because of the domain being completely inconvenient to any single workshop participant.