Collaboration gaps enhanced by a game? Yes, we can.

Today I want to share some of the outcomes coming from a new agile game I am working on (can you believe it?).

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 "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 future too). Some number: 6 initiatives, 6 sprints +100 components to build. This game is for TEAMS, and will involve between 18 and 30 "builders".

In a dedicated article I will go in detail with the game. For now let me only say that it has been successfully presented at Play14 in London, and we have already played few engaging sessions in some meetups and in real companies. In these sessions I have collected few interesting learning on team dynamics and I was really impressed on 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 2 sprints and some points immediately emerged.

3 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.

The Sprint 2 was much better. Now all of teams was able to deliver something, and only one team miss dependencies.

Unfortunately integration was still completely missing and actually nothing worked.

I would like to highlight the reduction of the velocity in 2 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 start analyse the goal in details try to figure out how to achieve it and above all mixing their own mission with the one of the whole projects (the only real!).

They started doing a more effective conversations (the game use a full team retro and a Scrum of Scrum 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"team of teams", and a collaboration model started appearing: they found how to interact (respecting the rules of the game) and above all define a way to help each other.

So we moved to the next sprints

Below the image of sprint 3 and 4.

Here you can see the magic happening.

In Sprint 3 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 was not impacting them. Other 3 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 2 were actually missed), they missed the short term goal, but the status of project was much more stable than in previous sprints.

On Sprint 4 they received a new short term goal, in addition to the previous one, so they need to work to achieve both. Unfortunately for a single missing dependency they were not able to achieve the goals and they all suffered a terrible death at the end of Sprint 4 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 well knows by all teams, but actually few of them have a clear idea of how much collaboration can impact in 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 consumption of their own backlosg. 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 ability of team to build stuff), but about planning and is absolutely unique in his 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.

Corrado De Sanctis is Agile Coach and has been involving in some of the largest enterprise transformations at international level in different industries. Project Manager with almost 20 years of experience, he has been promoting Agile since 2012 and has different certifications at team and enterprise level. Corrado is a known member of Agile community in London where he manages "Lean, Agile Delivery and Coaching Network" and "Digital Transformation in London" meetup groups (+2500 members) and he is speaker on Agile topics. In his "short" free time, he uses to practice triathlon.

Tag: #seriousgame, #agile, #digital, #dependencies, #integration, #collaboration, #team, #play14, #dsbuilders