I often had the problem that when I finally realized that the meeting agenda didn’t meet the actual issues, the meeting itself was long time done. This raises the problem that people aren’t forthcoming at putting across issues they would like to cover or discuss in the meeting. I ended up doing a very natural thing - I tried to listen to the issues of my colleagues even more in order to further improve the content of the meeting.

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.

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.

In an iterative, continuous development process, manual tasks must be reduced to guarantee a high level of quality over time. Testing the artifact is one of those tasks.