Author Archive: Toby Baier

Multi Team Retrospectives

If you “scale agile”, doing sprint retrospectives within development teams might not be enough. We at Adobe Hamburg Shared Cloud are 8 development teams with 42 developers in total. These teams need to work together on a product which is a Platform as a Service for other Adobe products. And since sprint retrospectives work great on team level, we also established them as an “all team” activity on a quarterly cadence. Here is how we like to do it:

Set the Stage (15 minutes)

We do this all together, standing in our largest room: either setting a specific topic, taking a stand, doing a quick Improv Theater exercise, or else getting into the mood. Last activity we did was a temperature reading, creating a histogram of how people think we are doing concerning technical debt.

Gather Data (30 – 60 minutes)

This is done in smaller groups. Usually we ask everyone to build groups of 4 with people not from your own team, then do whatever “gather data” activity they like best (probably 4L, Mad Sad Glad or alike), decide upon 3 main findings.

Liberating Structure 1-2-4-all in action

Sometimes the topic is just “how does our collaboration work for you”, sometimes it is much more specific like “what is your main problem with technical debt”. Then we all get back together, and each sub group presents their 3 main findings.

A much faster way to do this is a liberating structure called 1-2-4-all: first you have 2 minutes to think for yourself about the question. Then you find a partner and discuss with him for another 2 minutes, deciding which topic is most important. Then each pair finds another pair, making it 4 people to discuss their findings and agreeing on one thing, which then is written on a large post-it and presented to the whole group (“all”).

Generate Insights (60 minutes)

Again, this part starts in smaller groups. This time groups form around one of the findings from Gather Data they are interested in working on. They first do a deep dive into the reasons for the finding they work on, probably with asking 5 whys or creating a Cause-Effect-Diagram. In this phase, it is very helpful to have quite a few facilitators helping all the small groups in their work, since as in any retrospective, I consider this the most demanding part to do.

When done, the groups are asked to create an action proposal, leading from problem-space into solution-space. This is expected to be a flip chart with a catchy title, some explanation of the insights, and a concise proposal for action.

Decide what to do (20 minutes)

Sample proposal poster, proposing better proposal posters 😉

Now it is time to vote! All small groups quickly present their proposal poster. Each poster has three areas for votes:

  • Agreement (“Go for it”)
  • Engagement (“Count me in”)
  • Veto (“We need to talk about this”)

Everyone is asked to vote on each poster, whether they agree with the proposal, even want to participate in whatever action is proposed, or vote against doing it. The latter two options are only allowed with your name on it, since the poster designers need to know who to talk to. This way, follow up working groups are composed out of all the people who put their names either into “Engagement” or “Veto”. Proposals without any veto can go into action by all engaged people instantly.

Close the retrospective

After such a long retrospective it’s good to have a short closing. Feedback door works great, and if you do the retrospective on a Friday afternoon, some beers also help to keep people discussing the results a bit longer!

Escape from boring teamwork exercises

Why waste time on a game?

How do you get your team to actually behave like a team instead of a bunch of individuals working separately from each other? While most teams we have worked with have a good degree of teamwork, most of the times there is quite some room for improvement. A fun way to make a team feel what it is like to excel in teamwork is a game, which you can play in an extra session, maybe 60 – 90 minutes of team time: “Escape – The Curse of the temple” by Queen Games is a cooperative and messy game which you can leverage to increase collaboration and coordination in your team! Have fun learning about

  • why taking time for meaningful communication (often disregarded as “meeting overhead”),
  • planning cooperation by getting an overview of a complex situation together, and
  • actual teamwork in terms of “doing things together” instead of just following a similar goal

helps to speed up and reach your goals faster (or actually: at all!).

About the game

The game is cooperative, that means: the players need to “escape” from a temple they have to explore while playing, and they can only win if every player escapes from the temple within 10 minutes. Sounds like a quick game, but you’ll be very exhausted afterwards, because – and that’s the messy part – the game is not played in rounds: each player rolls their dice at the same time, over and over again, as often and quickly as they want to! While they discover new “rooms” all the time on their way to the exit, in some rooms the team can activate gems… and they need to, otherwise they won’t be able to get out.

If you as the facilitator don’t know the game, please take time with friends or family to try and learn beforehand, it is important that you know the rules. The games home page offers PDF versions of the rules in many languages.

How to use Escape in Team Learning

Escape can be played with up to 5 players, but you should plan to have 6 to 10 players for your session. The idea is to let half of the team play, and the other half observes how they play, draw a “burn up chart” for rooms explored (the exit is in the last five rooms, so they need to explore a lot) and “burn down graph” for gems activated (without activating almost all gems, they won’t be able to use the exit). It is key to let observers note actual quotes from the players, since game play is very hectic and quick, they’ll most likely not remember exactly what they did or said. In all of my sessions, the first attempt of the game failed – the team died, and that’s good! Not for spirit, but for learning. Most often, lack of clear communication, lack of explicit collaboration and lack of effective re-planning leads to teams dying in the temple. So, after the first game, let the observers give feedback to the players. Take at least 10 minutes to analyze why the team failed, and speak out precise situations like “when Ken was here, he said ‘I need masks’ but no one responded”, more than general “you did not collaborate”.

Then do another round, switching observers with players. Now that everyone knows what to look after and how to behave, the team will have a better chance of winning. Again, take your time to analyze what happened this time.

Extending the rules to learn about team dependencies

If you have time for a third round, you can take it to another level: let both parts of the team play at the same time (you need 2 games then, obviously, and 2 facilitators help a lot, too). We did that in separate rooms because the game play can get quite noisy. We modified the rules, so that collaboration with other teams (the feared dependencies) is modeled in, too.

There are rooms in this game where the team can decide to activate 1, 2, or 3 gems. With two teams playing simultaneously, the new rule is that

  • the “1 gem” option can only be solved by the team themselves,
  • the “2 gems” option can only be solved by going to the other team and asking for the required 7 torches (in this case) from players in that team in the same room, and
  • the “3 gems” option can only be solved by both teams adding up the 10 required torches from both teams.

If a team chooses to ask for help from the other team, and the other team agrees to help, then the other team can only do that with players who are on the same room tile at that time. That does not need to be a “3 gem room”, any room that they are all in is okay.

Added learning with this modification is that team dependencies, while they should be avoided where possible, can lead to better results if handled collaboratively and cooperatively.

Thanks to Malte Sussdorf, who introduced us to using this game in team building at RFG 2016, and to Florian Noeding, who developed the “dependencies” extension with me!

Find your focus principle

This article is about an activity you can do with a team to find spots for improvement regarding agility. As an extra, during this activity there is a chance to deepen knowledge about the Agile Manifesto. Read it, try it, and please share whether your outcome was worth it!

What you need

  1. The 12 principles of the Agile Manifesto printed out on cards (feel free to use this template: AgilePrinciples.pdf) *
  2. A flip chart or wall, if you can’t stick the cards to a wall just use the floor
  3. About 30 minutes with your team for this activity

How to play

The goal is to have a distinctly ordered list of the agile principles. The most important part is to ask the best question, which we found to be “how big is our demand of improvement regarding this principle?”, because it makes people think about their situation and yields actionable insights. DSC00895

  1. Start with a random principle, discuss what it means and how big your demand may be, and place it somewhere in the middle.
  2. Pick the next principle, discuss what it means and sort it relatively to the other principles. Use bubble sort or any other algorithm, I tend to propose a position depending on the discussion and move from there by comparison.
  3. Repeat at 2. until all cards are sorted.

Now that all cards are set, consider the card on top: this is the most needed and most urgent principle you should work on, so prepare to get into “generate insights”:

  • DSC00906does everyone still agree?
  • how do you feel about it?
  • what are the reasons there is the biggest demand for change here?
  • should you compare to the second or third most important issue again?
  • if someone would now rather choose the second position, why?

Put up the result up in the team space. This way, everyone can always re-check and start a conversation about them. You can also get it back into another retrospective to see what changed after measures for the first insight were done. As with any retrospective, it is very important to follow up on measures.


In this activity, you sort the principles along one dimension, the question “how big is our demand of improvement regarding this principle”. You could add another dimension “urgency” or “effort”, so that as a result you get a map of principles with most demanded and urgent or easy to fix principles on the top right. But then, how do you estimate effort without even thinking about measures first, and why should urgency be so much different to demand? This modification didn’t help us, but maybe it helps you.

A better modification might be to sort only the top three principles. Compare each picked principle with the current top three, and if it does not yield more demand of improvement, don’t spend your time deciding whether it is on position 10 or 11. You might lose some insights on what people actually think about these principles, probably also letting down on the educational aspect of the activity. Still, having focus on the top principles should be fine.


Retr-O-MatNo team is perfect, we all know that. And it’s nothing to be ashamed of. We all strive for better agility, because we believe that iterative software delivery in close contact with the customer is a better way of building actually valuable software than waterfallishly keeping progress (or lack thereof) secret until the time frame for learning how to do it better is long gone. In agile teams we do retrospectives in regular intervals to identify measures on how to improve our team performance.

It is important to not do the same retrospective over and over again. It is very valuable to try different formats every now and then, to let the team take different view points and identify different impediments. Diversity is your friend! An excellent resource to find new things to do at retrospectives is the Retromat by Corinna Baldauf. It not only helps to be inspired for new activities to try in retrospectives, it even let’s you design whole plans for retrospectives and share these with your colleagues.

Agile ManifestoThis article describes the “Find your focus principle” activity. The goal is to identify a teams weakest spot regarding the principles of the agile manifesto. A sub goal is to make the team aware of these principles. While the 4 values of the agile manifesto are quite present and understood by most of the people I worked with, the 12 principles seem to be a list of things one might consider once in a while. Some people call these principles “the better manifesto” (although being part of the original one), so take your time to consider them.

This activity covers the “gather data” part of a retrospective and shouldn’t take longer than 30 minutes. You can combine it with any activity for setting the stage, generating insights, deciding what to do, and closing the retrospective. If you need ideas on how to do that, either use the Retromat or read the book on Agile Retrospectives by Esther Derby and Diana Larsen.


* We found it useful to put a catch phrases on each card which is easier to read from a distance than the whole text of the principle. It is important to not confuse the tag line with the principle itself, it just makes the card easier to handle (read / talk about). Thanks a lot to the participants of the Retrospective Facilitators Gathering 2016 for feedback on the catch phrases!