Can online agile workshops be just “like the real thing”?

One of the most effective ways to demonstrate tricky real-world concepts is to run a game that strips away any complexity and concentrates on demonstrating the concept in an unambiguous and obvious way. As agile coaches, scrum masters and change agents, we often struggle with convincing people about agile mindset concepts, so there’s nothing better than getting out the lego, or a set of coins or playing cards and running a game round a table with one or more teams to really hammer home a salient point.

Unfortunately, the current pandemic has made it impossible to run such workshops and games face-to-face. And, of course, this “new normal” where people increasingly work from home or remotely, is not just about the pandemic; more and more companies have offshore teams, offices in multiple locations and more and more people working from home for at least some days of the working week. It is looking ever more likely that remote working will only increase after the pandemic as more companies realise the benefits to themselves and their employees.

Technologies such as Zoom and Miro have made it possible to move many meetings online, but, having attended and facilitated many such meetings, it soon becomes clear that the engagement is nothing like it would be in a face-to-face setting. There are many reasons for this, not least the fact that the body language we rely on in meetings is missing; you can guage everybody’s reaction with a quick glance round a room, but not when you have to scan 20 small windows, some of which may not even be showing video. Sharing a screen can end up like watching a Powerpoint presentation, and the temptation to drift off and disengage can be strong when other tabs or devices are needily flashing notifications. And , of course, unlike facae-to-face meetings, we can’t have a “no laptops in meetings” rule — the meeting is haepening on the laptop, and the temptation to use it to do other work is often overwhelming.

And those awkward silences — do they just seem longer on Zoom or Teams?

So, we decided to see if we could do something about it. Could we build online workshops that fully engage the participants just like “the real thing”

In collaboration with Matt Phillip, we built the No Estimates game. This was already a really engaging board game, so it gave us a great start. The game is a a simple Kanban game that demonstrates the futility of estimating. Participants play in teams and simply have to estimate how long it will take them to complete a backlog of work, given — unike in real life — the exact number of items to complete, the exact amount of effort for each item, and the exact amount of effort available. Like real life, however, there are dependencies, urgent items, blockages, deployment failures, and even an evil PO called Vince who throws the odd spanner in the works.

Still, teams have way more information that they would have in real life, and it is assumed they can give accurate estimates in real life, so this should be easy, right?

Well, no. Teams always get it wrong, and this game not only demonstrates this, and the reasons for it, it also shows better and more scientific methods of forecasting to arrive at the answer to the perennial question “when will my stuff be completed?” (see Learnings below for more expanation)

We’ve run this game many times, including at the Agile 20 Reflect festival with a numer of participants who had never previously met, and the level of engagement is always amazing; as a faciltator, jumping between Zoom breakout rooms, I can see teams working as if they’d been together for years; there is banter and discussion, and it really feels like they are round a table playing the game (the participants also say this…). In the Agile 20 Reflect game, I suspect there was much more engagement than if we’d placed them physically in a room — somehow, the awkwardness of a first meeting was swept away as they concentrated on playing the game on their browser in front of them.

So how come — why was there more engagement?

1. It’s real-time and local; everyone in the game is acutely aware of the state of the game as it right there on their browser. When a player adds effort to a card, it immediately shows up on everyone else’s browser. If a card is blocked it goes red and everyone knows it’s blocked. Seeing and playing the game locally on your own browser is so much more involving than seeing it on a shared screen.
2. There is active participation; players are always actively doing something; they have no choice but to perform tasks — adding effort to items, pulling in new cards, etc. — and discuss what to do next. Its very difficult to drift off if you are interacting with the game at very frequent intervals.
3. It encourages — well, forces — focus; it is very easy to popup up a message to make a point. Every few rounds of the game, we can pop up a retro window, for instance, so teams can reflect and adapt. At the end of every round we pop up an Event card with information and actions to be performed along with the current cards and value delivered. All this helps to keep the players engaged and focussed; it’s not possible to drift off if your team mates are clamouring for you to work on a task on the board…
4. Using real data makes the story real; we can generate all kinds of data and show it to the participants as and when it is pertinent; it is much more powerful to say “this is your cycle time so far” than “here is a stock image of a typical cycle time”. Also, as the game is software, we can do this in real-time, as and when we need to. We can even generate complex calculations such as monte carlo simulations with100,000 runs at the touch of a button.

In some respects, the online game is actually better than the face-to-face version. Any random elements, like throwing a dice to see if something is blocked, can simply be programmed into the code , and are therefor immediate. Cards move columns automatically when complete. The rules can also be more strictly applied; if you are not allowed to add effort for some reason — you don’t have the skills, or it’s the worng column, for instance, you simply cannot bend the rules in the online version! The game can even be paused and continued at a later date if required.

At the Agile 20 Reflect game, we had participants from the UK, India, Canada, Germany, Australia, the US and the Ukraine. Such a gathering would never normally happen — it would even be highly unlikely at a face-to-face conference — and this is a further benefit of these online workshops. People from all over the world can attend and collaborate; ideal for large companies to bring together offshore teams or overseas offices. What better way for the remote company outposts to feel included and engaged. Watching the participants in this game, it was apparent that geographical location was forgotten about within seconds of starting the game.

Learnings

As fascinating as all this is, and however engaging and fun games like this are, they are only useful if they give valuable learnings. As already mentioned, we can use the actual game data to generate illustrations of these learnings, and this helps to make the debrief at the end of the game relevant and interesting.

As an example, here are some of the learnings from the Agile 20 Reflect game.

One interesting comparison between 2 of the teams was how they defined and refined their estimates based on new information.

As you can see, one team initially estimated (left column) low — 25 days, whereas the other went high — 45 days. When they re-estimated after delivering some items, they both ended up nearer the actual figure which was 35 for both teams. Interesting, right? Both teams had exactly the same information, and played exactly the same game. They both took the same amount of time for the work, but both initially estimated incorrectly, one too low, one too high.

Another finding that always surprises the teams is the correlaton between the amount of work required on an item, and how long it takes. Surely the bigger the card, the longer it takes? This is rarely the case, in the game, or real life. Here is the correlation between effort needed and time taken for one team.

As you can see, the correlation is by no means perfect (1), and this is very often the case. We have even seen negative correlations, where smaller cards take longer!

One common estimation mistake is to try and make an estimate more scientific by using data to generate a mean and standard deviation confidence interval. However, unless the data is normally distributed, this is statistically invalid, and prone to error. Here are the distributions of days to complete work items from 2 of the teams:

As you can see, after 25 cards, the distributions are far from normal; one team is more Poisson, if anything. So, we can’t use mean and standard deviation. What we can do, however, is use the data we have to run a monte carlo simulation. Here’s an example for one team were we’ve done 1,000 runs of the data to come up with a forecast on when we would complete 100 cards.

As you can see, we have a 50% chance of completing 100 cards in 144 days, and a 99% of completing in 169 days. This gives stakeholders a much clearer picture of when they can expect their features to be ready, and they can make more considered opinions of launch dates — 144 days is possible, for instance, but risky…

There are many other ways to present the data from the game, and this makes for lively and interesting discussion at the end of the game.

Running The Game

We are happy to run this game (and others — see below) as a remote workshop, or to teach you how to facilitate it yourself. We have run it with over 80 participants in 8 teams, but it can be as large or small as you need. It’s even possible to use it for a single team (without dependencies, obviously) if necessary.

As hinted at earlier, this game work best when the UX is really thought through so that it is as familiar and engaging as possible. With this in mind the game is highly configurable — you can change the teams, for instance or the blocking and deployent failure rates — to best suit your organisation. You can even change the currency to make it locally relevant. (We are working on different language versions — let us know if you need this…)

We are also happy to discuss implementing changes to better suit your organisation to really give participants the best experience, be it branding and badging or making structural changes (e.g. different Kanban columns and roles) to better reflect how your organisation carries out it’s activities.

Other Games and Activities

We have developed, or are building a number of similar games to demonstrate various concepts, including:

1. The Coin Game — a simple game to demonstrate value-driven delivery and why this reduces risk whle maximizing value delivery to the customer.
2. The Interdependent Teams Game — a simultation to explore the best way to handle work in interdependent teams with surprising results!
3. The Pipeline Game— a game to explore whether we can maximise customer value delivery by concentrating on delivering quality, or by learing quickly.
4. The Pairing Simulation — an exploration of how knowledge sharing through pairing is an effective development strategy

There are others on the Agile Simulations web site, and we are constantly looking out for new ideas — contact us for more details. All games are available to play with demo data, but you can purchase a licence to open up up all the configuration and customisation features to maximize participation and engagement, and to persist data for trending and comparisons.