Workshop data types
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:
- Not do stand-ups.
- Try to aim for half day sizes for all tasks.
- Always have a voluntary “problem solving”-meeting after the stand-up.
- Have stand-ups twice a day.
- Not be allowed to say the same thing today as you said yesterday.
- 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.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about the difference a really good retrospective can make, to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.