Build Your Own Scaling Framework

Being an Agile Coach & Trainer for Prowareness, I use different types of games, tools and practices every week during meetings, workshops and trainings. Some of these I’ve invented myself, but most already existed and have only been changed slightly to a format that suits me best. The upcoming period I want to share some of these games, tools and practices. I will share the what-why-how-when and what worked well and what didn’t. By sharing my experiences I hope to inspire you to give these tools and practices a try for yourself, improve it and hopefully share the perfected version in return.

What is ‘Build Your Own Scaling Framework’ about?

Over the past years ‘scaling’ became the most hyped and diversely interpreted, word in the context of agile. Many organisations have started ‘implementing’ a scaling framework. And most of these organisations have failed in achieving the desired change. From my own experience there’s a clear pattern present within these failures.

During an interactive game the participants jointly discover the best approach to build a scaling framework. Keywords are:

  • Fun
  • Teamwork
  • Sprints
  • Role-playing
  • Card decks
  • Join – Play – Discover

What’s the source?

The game was invented by Jack Kloprogge en Barry Overeem.

Duration

1 hour, which is divided into the following blocks:

  • Instructions (5 minutes)
  • Sprint 1 – Selecting the principles (15 minutes)
  • Sprint 2 – Selecting the practices (15 minutes)
  • Sprint 3 – Building the framework (15 minutes)
  • Debrief (10 minutes)

How I’ve used it

I’ve played the game during Scrum Day Europe. We’ve split the group of 20 participants into 4 teams. During three sprints of 10 – 15 minutes every team managed to build their own (basic) scaling framework.

What you need

  • The agile principles written down a small cards
  • Posters of some scaling frameworks (optional)
  • Markers and pens
  • Adhesive tape for sticking up the principles and practices
  • Flipchart sheets
  • Sticky notes
  • Laptop and beamer to show the instructions
  • You don’t need any chairs or tables, just give every team a flip over to use

The Case

The picture below contains a description of the case. It’s about a fast growing start-up that struggles with the common challenges:

  • How to build a product with 15 teams?
  • How to maintain creativity?
  • How to manage the rapid growth of the company? 

Case Description

The rules of the game

The game is pretty straightforward. Teams of approximate 5 persons appoint their own CEO. This is the person that represents the case and reviews the team’s progress. After explaining the case, the team starts building the framework doing three sprints, every sprints includes a demo to their own CEO. During a central debrief the lesson’s learned are shared.

Rules of the Game

Sprint 1 – Selecting the Principles

The first sprint is about studying the case and the 12 agile principles from the manifesto. The team discusses them within their team and selects the 3 principles they find most important given the case description. The sprint should include a demo to the CEO.

Sprint 1

Sprint 2 – Selecting the Practices

The second sprint is about selecting the practices. With practices roles, artifacts and events are meant. Given the three selected practices the team brainstorms about all the relevant practices they think are necessary to add to the scaling framework. The standard material for the game includes some posters of existing scaling frameworks. If the team finds them useful as inspiration for coming up with practices, it’s perfectly fine to use these posters. But for less experienced teams, these posters can also become a distraction. The result of the sprint is some kind of story map.

Sprint 2

Sprint 3 – Build the Scaling Framework

The final sprint is about building the actual scaling framework. The goal is to create the blueprint of a scaling framework that matches the case description and can be pitched to the CEO. The team may use all the available materials and tools to create the framework, e.g. flip over, post-its, markers, tape. The sprint ends with a final demo to the CEO.

Sprint 3

Debrief

The game ends with a central debrief during which the lessons learned are shared and discussed.

Hereby my takeaway is:

Not paying attention to the principles behind Agile, and prioritising practices over principles is one of the main causes of Agile failure. You can do all the practices perfectly, and still fail at Agile. You might be ‘doing’ Agile, while the real success will come with ‘being’ Agile. Organisations should stop looking for recipes and copy the most visible and obvious practices without connecting them to the underlying values and principles. While Agile practices are important, practices alone often lead to Agile failure. Agile principles and changing the culture are generally the most difficult, but they are what make agile sustainable in the long run and will truly expose the possible benefits.

Therefore my message is:

Debrief

Pictures or it didn’t happen

PicMonkey Collage

I hope this blog post inspires you to give this workshop a try yourself. If so, I would really like to hear your experiences! And of course, helping you out by facilitating this workshop is always negotiable.