There are lots of ways to help introduce the concepts of Scrum to teams and to give them a chance to put their new knowledge into practice.
I wanted to try something a little different. I wanted it to feel like a real project, so I didn’t want it to be too short. Lots of coaches use Lego, but I have never found Lego games particularly enjoyable, and I really didn’t want to have to take bulky props with me on the plane.
In order to make it feel more real, I decided to make the simulation project something that the team would find useful, so I decided to use the Inception Deck as an example. I first heard about Inception Decks in Jonathan Rasmusson’s book, The Agile Samurai, but over the years, I have evolved it a bit.
The Inception Deck is a set of up to 13 discrete ideas, models and techniques that inform a team about some element of their project or product. Taken together, they are a powerful way to explore what the project is for and how they might deliver it; and communicate this with their stakeholders.
As the artefacts are all able to be described on a single page (or slide), they also require no special equipment (except for a blank Product Box).
This was an ideal choice for the Scrum Simulation.
I wrote each Inception Deck artefact as a User Story on an Index Card, with space on the back for the acceptance criteria, and gave them to the Product Owner to prioritise. This was our product backlog.
We had two half days, so I timeboxed the events accordingly with the first half day being one Sprint of two ‘days’. The second half-day was the second and final Sprint.
We ran two (short) retrospectives and made them different to highlight that there are lots of ways to facilitate the events. One the second Sprint Planning event, we introduced estimation and relative sizing.
This exercise went well, and even when it didn’t go well, it created opportunities to discuss and revisit the core agile concepts. For instance, at one point some team members were standing doing nothing, waiting to be told what to do next. This was a chance to talk about pull, team autonomy and self-organisation.
An interesting insight emerged from the Product Box exercise. This is where users imagine the system is a physical product, and. They design a box advertising what’s inside and why a customer should choose it.
On their box, they had described the system as “Friendly” and had written the system name twice – once in English and again in the local language. Now, we knew there was a multi-lingual requirement, but the way that they had described it made me think that it was much more significant than would be implied by the non-functional requirement in a requirements specification; particularly one that was written in English.
In fact, developing it in the local language first is far more likely to help it be perceived as a friendly system compared to developing in English first (which would have been the assumption to start with).
The Product Owner was really important in this exercise (just as they are in real Scrum) and it was really encouraging to see him engage with the team and really start to get a deeper understanding of his role. He was setting acceptance criteria and challenging the teams to focus on the core need, and not to over-engineer their products.
This is exactly how Product Owners should behave! It also allowed me to introduce the concept of refactoring and creating additional stories that take completed functionality and improve it. This ‘make it better’ story was then able to be prioritised against work that hadn’t been started.
The team ended up not only with experience of Scrum, and all the events, but also with a complete Inception Deck and some additional insights into their project.