The Three Little Pigs Retrospective
In SCRUM methodology a retrospective is one of the most feared, and sometimes most awkward parts of the process. But it doesn't have to be that way. A retro should never be a confession! There are ways to make the experience more fun and interactive. One method that we use at Amsterdam Standard is the Three Little Pigs Retro.
Yes, just like the fairy tale.
Who are the 3 pigs?
In the fairy tale, 3 pigs tried to defend themselves from the big bad wolf. One built a house out of straw, which wasn't rigid and hardly an inconvenience for the wolf to demolish.
The next pig made a house out of sticks, which was far more rigid but had a lot of room for improvements. However the last pig, took the time to build a house out of bricks.
The wolf huffed and puffed, but wasn't able to topple the house.
Figure out what you want to test.
How to prepare?
When doing a retrospective with developers, first choose a bunch of components, or pages, or processes that we want to analyze during the meeting. For example make cards called "Homepage", "Login System", "Modals". Keep the cards short, a dozen is already a lot. You can always repeat the retro next week if you want more topics to be discussed.
Display the topics (cards) to the entire team before the meeting. Let them get accustomed to the topics and be better prepared for the retro. Create a Miro board, or a FigJam, or just a simple whiteboard, define the topics, and make 3 columns for voting: straw (red), stick (blue), brick (green).
Then the Voting begins
Pick one of the chosen topics and encourage each member of the retro meeting to cast a vote:
Ask simple questions: "is the invoicing system built well? is the code readable, is it easy to work on?"
Vote for Straw House if it was most probably built quickly, without proper thought and is most probably on the verge of collapse. Something that is begging to be refactored.
Or is it a Stick House?, which means it was built OK, and it works fine, but there is a lot of improvement, or automation, or abstraction that can be performed here.
Maybe it's a Brick House?, which means this is an example piece of code. Fully tested, documented, easy to read, the perfect guide to follow for other components.
Understanding the results
In this example we see that in general the developers have agreed that the homepage slider is in a good state. But be curious about that one vote in the red. Let the developers discuss this one red result. If its something that can be easily fixed then a task can be created. If its just someone not agreeing well then ... you should define some code standard.
The invoicing system on the other hand looks to be at a critical point. If devs are alerting about this section, review their fears, see what the issue is and plan an epic to improve, refactor or update this section. The sooner you find out what's going wrong the better. You wouldn't want a sudden crash in the invoicing system on a weekend? right?
What insight do we get from this activity?
"You get an aerial view of the state of your app."
After you tally the votes you can see how the actual developers feel about a section / part of code. You can localise potential places that should be repaired or refactored in the near future and where you have a solid base. If developers are signalling that a certain area of the code base is a pain, or constantly overlooked, it might be time to repair, rebuild or rethink that area. Ignoring this will increase tech debt, and will make maintenance worse if nothing is done.
If something is in the stick house, you can consider improving it, but its not that hot of a topic.
In sections where the brick house is dominant, you can zoom in to see what works, why this area of code is considered a good example, and strive to follow this suit in future components.
Is this only for devs?
Absolutely not!
The magic of a retrospective is that you can take into consideration anything you want. I've seen this being used for testing UX processes, or deciding which UI pages need to be refreshed.
But you can also use it in yearly assessments of company operations. For example if a specific marketing technique is worth the hassle, if there are company processes that could be simpler, easier.
If not the 3 little pigs retro there are also some other variants of retrospective in the world. Those that are designed for fresh new teams that don't know each other, or 1:1 retros. The idea is to try attractive ways to get feedback from your teams. You devs, designers or managers all have opinions, and sometimes its hard to articulate things that could be improved. A retro can help solve this.
