Corrado de Sanctis, Agile Coach, talks about the design his new game for enhancing collaboration in software development teams. The article contains some terminology specific to that field, which are defined in the Ludogopedia. I hope that these definitions will allow those of us who are not experts in Agile/Scrum/Lean to nevertheless read this article so that they can appreciate the game design.
A brief introduction to the game
The game is called DSbuilder and it is about building the Death Star in the Star Wars universe, just after the “Rogue one” movie. We have the plan of the weapon and we need to build it. Simple? Actually this is the most complex ever (in the future too). Some numbers: Six initiatives, Six sprints +100 components to build. This game is for TEAMS, and will involve between 18 and 30 “builders”.
This game has been successfully presented at Play14 in London, and we have already played a few engaging sessions in some meetups and in real companies. In these sessions I have collected a few interesting learnings on team dynamics and I was really impressed by how the game was able to expose them. This article is about these outcomes.
Start the activities
In the image below you can see the first two sprints and the points that immediately emerged.
Three teams were not able to deliver anything in Sprint 1 because they were so focused on the dependencies that they missed the timebox.
Two teams have been impacted by the above problem and, practically, even if something has been delivered, nothing was working because of the missing internal dependencies (the tapped cards).
One team was able to deliver something coherent with their own internal dependencies but failed integrating with others and nothing was working.
Sprint 2 was much better. Now all of the teams were able to deliver something, and only one team missed the dependencies.
Unfortunately integration was still completely missing and actually nothing worked.
I would like to highlight the reduction of the velocity in two teams. This was due to the lack of external dependencies not managed by other teams. You can see this very well counting the number of cards on the board.
At this point something happened
People started to analyse the goal in detail trying to figure out how to achieve it, and reflecting on how this might relate to their real-life work.
They started more effective conversations (the game uses a full team retro, a Scrum of Scrums and PO sync during the sprint, to facilitate collaboration), focused on the integration more than on the backlog consumption.
They started realising that they have to work together to effectively integrate.
They worked together as a “team of teams”, and a collaboration model started appearing. They found how to interact (respecting the rules of the game) and above all to define a way to help each other.
So we moved to the next sprints
Below is the image of sprints three and four.
Here you can see the magic happening.
In Sprint Three one team (the bottom one in the picture) was completely devoted to other initiatives’ backlog (no story in their own backlog) because they realised that short term goals were not impacting them. The other three teams worked in similar way, minimising activities on their own backlog. Everybody was focused on helping team 3 because they were impacting all other teams (you can verify this from the number of cards, more than twice as usual in points).
Even if they were able to solve most of the dependencies (only two were actually missed), they missed the short term goal, but the status of the project was much more stable than in previous sprints.
On Sprint Four they received a new short term goal, in addition to the previous one, so they needed to work to achieve both. Unfortunately because of a single missing dependency they were not able to achieve the goals and they all suffered a terrible death at the end of Sprint Four by the Emperor (using his evil powers).
Game over!
Conclusion
In this 100 minutes we were able to see in practice how collaboration is a concept that is well known by all teams, but actually few of them have a clear idea of how much collaboration can impact performance.
Another learning is that this complex project cannot be controlled at team level (confirming the system thinking view) but builders can win only if they worked all together for the effective common goal that is not the consumption of their own backlogs. It was absolutely clear that, even if each team could be able to complete their work, the fact of working together (scaling) with other teams introduced an unexpected level of complexity.
Also they have proven how sub-optimisation could help to achieve the effective result, even if this requires a further level of collaboration (sacrifice?).
The game is able to provide a backlog with dependencies (internal and external) and with integration requirements, very close to a real complex software project typical of large enterprises. This simulation has been considered by players pretty realistic of the effective difficulties found by teams working together. The game is not about building (I always trust the ability of a team to build stuff), but about planning and is absolutely unique in this genre.
The mechanic of the game is impacted by events, happening every sprint and the teams must be very careful to understand and adapt. The goal is not simply to complete the backlog in the given time; better, completing the backlog is not mandatory if the goal is achieved. And this is a lesson for business people too.
“To help people, teams and organisation in their agile journey”
- Applying Agile Practices to Create an Agile Serious Game - 24th September 2021
- Pizza KATA IIRetrospect is a Mindset and Not an Action - 8th July 2021
- Pizza KATA or “Change is a Mindset and not an Action” - 14th May 2021
1 Trackback / Pingback