Purpose

Only one thing can be the most important. If we want to align a workshop well, aligning it for one thing, and nothing else, is the easiest. A workshop has limited time, so the scope must be limited. Decide what the most important outcome is for the workshop, and design it fully for that outcome.

Participation

Everyone is important in a workshop. If the purpose is learning, each participant needs to get a chance to grow. For workshops aimed at creating or exploring, the views from everyone are even more crucial. It is important to have a structure that works for extroverted and for introverted people. One way to do that is by using exercises that let people think on a topic in multiple ways, some of those can be found among the liberating structures.

Structure

Guiding towards the purpose, and enabling participation, is done through structure. This post is about creating structure in a workshop

Time

For a workshop to work as planned, you need to be able to complete all steps. Some workshops can bring value when half-finished, but most need the conclusion and some make things worse if left half done.

Information

The workshop needs full focus. If the participants lack information, the facilitator has to have it at hand; otherwise the schedule will be disrupted. Try to anticipate what will be needed, or plan for breaks long enough so that missing information can be found.

Trust

The last, but not least, part is trust. The environment has to be psychologically safe, and the facilitator must be trusted by the participants. Trust can be cognitive or emotional. The important part is to have a mandate to lead the workshop, and that everyone else feels safe to participate. You can read more about psychological safety here.

TLDR; One way to construct a workshop is to think of it as a series of data transformations.
Each step has to filter or transform the input in a way that it matches the input of the next exercise, until we have reached the requested result. This helps in controlling the format, and quality, of the results, without controlling its content.

The last part of this text contains an example featuring a retrospective. Below that, the post ends in flowchart illustrations.

Planning a workshop or a retrospective is a lot like software architecture.

Most software is about collecting, transforming and presenting data. To help us mentally model data we have type systems. A lot of languages have types, otherwise they are there, just implicit. We can introduce the same tools when designing a workshop. That perspective can bring value even to experienced facilitators. We never want to control the content of the output, but we want to be able to control its format, i.e. the data type.

Basic structure

In Agile retrospectives the five parts of a retro is suggested to be set the stage, gather data, generate insights, decide what to do and close the retrospective. If you plan another workshop you can use the same steps or define your own structure. Start with considering what data needs to flow between each step.

Plan each step

Now we find exercises that fit the input and the output of each step. Sometimes one exercise is not enough to go from the input to the output of each part. Then we need to find two exercises, where the second one transform the output of the first to the output of the entire block.

Often it is a pair of one exercise that create more data, and another that filter it down again. If you have plenty of time you can chain more exercises together the same way.

Practical advice

Artifacts

Plan for the artifacts carrying the data between each step. It can be sticky notes that move from one board to another, or text that is copied from a digital board to a text chat for a breakout room. Focus on how they connect the exercises.

Level of detail

You can direct the workshop by being more or less specific in your types. The amount of items moving from one exercise to another can be fixed, or flexible, depending on what comes up. If you filter things down to one item you get focus. If you allow the team to choose more than one there is more work in making sure to get a result in the end. The output “something that blocks me in my work” is wider than “something that make me code slower”. That way you can give the entire workshop a direction.

Cut it short

You can also use this to cut parts of a workshop if you are short on time. Have alternative, faster, ways to go from one state in the data to another, if you have to.

An example retrospective

The rest of this post is a concrete example using a sample retrospective as illustration. Explaining each exercise is out of scope of this text, they are just placeholders. The types of data going between the exercises are also part of the example. A lot of retrospectives will have similar data types, but they don’t have to.

Set the stage

This setting the stage is a part of a regular retrospective with an established team. So the input data can be transformed into the output with a round robin of a simple question like “What did you have for breakfast?”. If it is setting the stage for a retrospective regarding a gigantic delivery that crashed horribly, or for the first retrospective for a newly formed team, you might need multiple exercises.

Gather data

For our gather data-step we add two exercises. The first step is the Sailboat exercise that outputs things that drive the team, and things that hinders it. The hindering part is input into another exercise that sort things by impact on the team, and how much influence the team has over it. Our “high impact - high influence”-quadrant become input to generate insights.

Data that goes from the first to the second exercise could be:

• Not enough chocolate
• Road outside is loud
• Code is messy
• It is winter
• Ugly plants
• stand-up boring

The team places the boring stand-up in the top right corner, so that it is the input for the next step. (The messy code had high impact, but felt a bit out of their control at the time.)

Generate insight

Here we want to take circumstances that impede the team, that they also have impact over, and turn that into something concrete that can be countered.

A middle step of deeper understanding for the things can help. The 5 why-exercise take circumstances and try to explain them. That can then be input to a force field analysis to find what drives, and what prevents that thing.

The 5 why find that the boring stand-up is caused by people always saying the same things.

The force field analysis shows that the boring stand-ups are worse when:

• the development is moving too slow
• people being too general in their descriptions of their work
• people not helping each other when stuck

Factors that make stand-ups feel more valuable are:

• smaller sizes of tasks
• they end up in conversations afterward

Decide what to do

When deciding what to do we need suggestions and than filter them down. So the first activity, 1,2,4,all, generate suggestions, and vote with dots then pick the best to try.

The team generates suggestions:

1. Not do stand-ups.
2. Try to aim for half day sizes for all tasks.
3. Always have a voluntary “problem solving”-meeting after the stand-up.
4. Have stand-ups twice a day.
5. Not be allowed to say the same thing today as you said yesterday.
6. Always do pair programming.

Voting with dots had a tie between 3, 5 and 6. The team decided to merge them and the experiment to run was: “If someone work on the same thing for more than a day, they either have to get help in a separate meeting afterwards, or pair-program until the task is done.”

Close the retrospective

In this step we offload things that the team experienced during the retro, to return them to the rest of the day with closed loops. We also gather feedback for the next retro. Liked, learned, lacked and longed for is an exercise that do that.

Illustrations

This is the overview of the retrospective.

And this is the same, but with the exercises included.

IQ is a measurement widely used, though problematic, due to its history and how it has been used. (I recommend this series by RadioLab)

For a group working together the same phenomenon is called “collective intelligence factor”. Just like individual intelligence, it aims to describe why some teams have consistent better performance, independent of the nature of the task. Research by Woolley et al. shows that there are two major factors that contribute to how intelligent a group of people is.

1. Correctly reading the emotional state of others
2. Equal contribution in conversations and turn taking

Compare this with aspects of ensemble programming.

1. Regular retrospectives create a place for learning about others experiences. Retrospectives are a great way to improve your work, and one aspect is practising empathy. It creates a forum for sharing your perspective, including how you feel. An ensemble session ending with a short retro builds a feedback system for the team interactions.

2. Talking on a timer creates a framework for distributing contribution. We are not very good at judging how talking time is actually distributed. Strict ensemble working, with a timer, helps us get input from everyone. It could also help us get a better sense of what equal talking time feels like.

The interactions of a team is more important for the result than their individual intelligence. That is good news. It is hard (or even impossible, depending on definition) to improve ones intelligence. The dynamics of a team, and how we read and regard others emotions, can develop.

If you want to improve the general performance of a team, help them:

1. Take note of each others emotions.
2. Get the input from everyone.

One way to do this is through ensemble working, ending it with a short retrospective.

For tailored clothes we take measurements. The model is chosen based on the body type of the person. When picking a color the complexion is taken into account. And last, but not least, the clothes are fitted before completed.

When it comes to processes we often ask for a copy of the suit. In his paper “Standing on the shoulders of giants” Goldratt states “What we have to bear in mind is that the application makes assumptions (sometimes hidden assumptions) about the environment. We should not expect an application to work in environments for which its assumptions are not valid. We can save a lot of effort and frustration if we bother to explicitly verbalize these assumptions.” This is from a discussion on the Toyota Production System. Other companies tried to copy it, but never did as well as Toyota.

Toyota Production System is like the suit. Making the assumptions explicit is as having measurements added to prefabricated items of clothing. But you can only get the best results with something carefully tailored. That is why I think that learning how to evolve an organisation and its processes is far more important than adapting the correct pattern or method. Get your organisation “tailor-skills”, practise measuring and fitting.

An organisation can use retrospectives, system wide measurements and the “thinking processes” that Goldratt developed as measuring tape and a dressmakers ruler. By looking at what others do we can get a starting point, a base pattern for a cut we like. But just copying what someone else is doing will never bring excellence.

Just as a piece of clothing will always look best on the person it is tailored for, only the organisation that invented a method can get the most out of it. So get the skills to tailor your own organisational model!

ps. When your body changes a tailor can help with altering the clothes. An organisation with skills for adapting processes is prepared for change.

TL;DR; Your retros will be more productive if you do them right. Read Agile retrospectives, making good teams great and/or get someone who facilitates your retrospective.

Retrospectives are fundamental to a successful team. With continuous improvement we can go wherever we want. But there are meetings, labeled retrospectives, that just don’t cut it. So when someone says “we did retros, but it did not work for us” I get really suspicious. If you don’t think your team need retros, did you try a good retrospective?

A good retrospective gathers input from everyone

Some people think by talking (and gesturing). That can not be done with everyone listening. Others need to gather their own thoughts in quiet. So a good retrospective has a structure that enables everyone to contribute, without taking forever.

A good retrospective brings out new thoughts

If what you do could have been replaced with a newsletter, a suggestion box and a poll, it is not a retrospective. The different parts of a retro are combined to do data transformation. Each step then pulls new input from the participants. The result is one thought built on another, forming collective insights.

A good retrospective demands full focus

No multitasking or daydreaming. Check in, making sure we are all present. Then facilitate so that everyone feels how their time is valued. That creates focus.

A good retrospective set priorities

One experiment at the time. If everything is important, nothing is important. Make sure that everyone feels heard. Have a fair process for picking the next experiment. That creates commitment.

A good retrospective is fun and engaging

We work best when in a good mood. Creativity and collaboration sometimes need a push. The retro should be a treat, not a chore.

A good retrospective gets better

Retrospectives also need to improve and change. Sometimes we end up just going through the motions when something gets too familiar. So a good retrospective also gathers data on the retro itself, and changes to always serve the team the best.

A good retrospective gets better with a great team

“We are too good to need retrospectives” is the same as “I am too fit to work out.” Teams that struggle have a lot to win from a retrospective, since you often can find high-impact experiments to try. But teams that work smoothly, will be able to use the retrospective to gain even more momentum.