I had the honor of participating this year in the Agile Tour Aix-Marseille (2016) as a speaker. Unsurprisingly, these are 2 sessions around the Kanban that I proposed:
- a beginner level: the Ball Flow Game (Karl Scotland)
- one at the practical level: the workshop Kanban values (mike burrows) - that I had featured at Mix-IT a few months earlier
Luckily, they were both selected! A very enriching experience for me and I hope for the participants as well! I will describe in this article the Ball Flow Game to which I added some modifications! 😉
Good reading !
Description
After a very Kanban Pizza Game, I now often introduce Kanban with the Ball Flow Game. It's a workshop that I find fun, powerful and simple to implement! In fact, it is a variant of Ball Point Game into which we have injected the notion of flow. I wanted to add a part to it to structure continuous improvement through assumptions. I will describe here the framework of the workshop without going into the details of the results obtained during the session.
If you're interested, you can find the instructions for the original Ball Flow Game here with the associated document here.
Materials and preparation
- Set of 20 balls (I use balls of the same color to be able to introduce a different type of ball if necessary but it is not mandatory)
- Stopwatch / Ball Flow Game excel sheet
- painter's tape
- Markers
- A4 sheets
- Test card printing
- 2 bags (for the balls)
I prepare upstream on a wall the following continuous improvement table (inspired by PopcornFlow) :
Reminder of the rules
Unlike the Ball Point Game, the objective of the participants is to complete a set of 20 balls as quickly as possible (instead of a maximum for 2 minutes).
We will then measure the overall time as well as the average processing time of a ball.
However, the constraints remain the same:
- There is only one great team
- The balls must have air time between people: no direct passage from hand to hand
- Everyone must touch the ball once to consider it dealt.
- No passes to your direct neighbour: we are mainly talking about neighbors on your left and on your right
- The entry point is also the exit point: the person who introduces the balls into the system is the one who must retrieve them at the end – the use of 2 bags is therefore recommended
Note: I am often asked if you can hit the balls multiple times. My answer is simple: “Yes you can. Now I remind you that the objective is to complete the set of balls as quickly as possible, so hitting them several times may affect your overall processing time. »
In the initial framework, participants perform 5 iterations with short moments of continuous improvement. This is where I wanted to make a variation. Instead of taking improvement actions hastily, participants will have to select their experiments based on hypotheses: a way to better structure the continuous improvement of the team.
Having never tested the workshop before, it was unclear if we would have time to do 5 iterations, but we will do as many as possible anyway! 😉
Start of activity
After presenting the framework of the activity, the objective and the constraints:
- I ask participants for a volunteer to play the role of PO (the entry and exit of the system! ;-))
- I impose a layout on them for the first iteration: form 2 lines, one in front of the other.
- I launch the iteration
After having processed the 20 balls, I write the results of the measurements on a table for everyone to see and I explain the next phase: the structuring of experiments.
Example
Nothing better than an example to help participants get into the process.
I place myself in front of the table of continuous improvement at the level of the Opportunities and I ask the group where they could improve:
- Baud rate
- Number of balls dropped
- transmission distance
- Group organizational structure
- Management of the output of elements (PO)
- …
I write each item on post-its that I stick in the column.
I then ask them what would be the element the simplest to implement and easily verifiable ? In other words, the one who would induce the less disruption compared to the current mode of operation. Let's go on the transmission distance.
We start writing the experiment using the test card (from Strategizer):
We believe that reducing the distance between us will reduce the number of lost balls and therefore our processing time
To check it, we will approach at arm's length
And measure the overall processing time and the number of lost balls
We will be right if the measured time is less than the previous time and the number of balls dropped is less than 2
We move it to the column In progress and the next iteration is launched taking into account the associated changes.
After the iteration, we review the test card and validate the results: generally this experiment works! 😉
Around the participants
I invite participants to form subgroups to complete test cards:
After a few minutes, we bring together all the test cards at the level of the column Hypotheses and each group comes to present its proposals. The exchanges are important here: they allow everyone to see that a proposal that seems obvious at first glance can ultimately be challenged when confronted with other perspectives.
It is important to keep all the proposals, even those that are not immediately selected: they may become relevant later.
It often happens to have proposals for structural changes to the organization of the group. I then insist on selecting the simplest proposals to implement and making it possible to capitalize on the lessons learned from the previous iteration. Despite the intrinsic interest of these proposals, they are disruptive in nature and generate many changes at the same time, which makes capitalization difficult.
Have you ever come across improvement programs that changed everything rather than improving what already existed? How did you experience it? 😉
Note: To temper this subject, it is important to know that a system has an intrinsic optimization limit. If we want to exceed this ceiling, a change of structure can help us.
The process well understood by the participants, it is enough simply to reiterate the iterations of play and continuous improvement.
Some additional ideas
If you have time, you can have participants experiment with the following cases and discuss the impact on Lead Time:
- Work in Progress Limitation – If it does not emerge from the group naturally, pass only one ball and measure the time
- Classes of service – Punctual introduction of “urgent” type bullets into the system: they must have a shorter lead time than “standard” bullets and are arbitrarily introduced into the system. Since I am using the excel file only measuring 20 balls, I replace some original balls with an equivalent number of red balls to keep the correct count.
- Variability of work items – While keeping the count of 20, treat various objects such as water bottles, scarves, pens, Post-its, notebooks… in addition to balls. This sheds light on the continuous adaptation necessary to deal with high input variability.
Debriefing
I remind you that the objective of the workshop was to introduce Kanban through practice. It is therefore an opportunity to make participants gain height by sharing the associated theory with them.
I then present to them the 4 principles and 6 fundamental practices of Kanban by asking them each time to make the connection with an element of the workshop.
The 4 founding principles of Kanban
- Start where we are
- The first process (deliberately imposed to speed up implementation) and the first measure
- Agree to pursue incremental and evolutionary change
- Presentation of the framework of the workshop with the iterations
- Initially, respect roles, responsibilities and job titles
- Selection of the PO role at the start of the workshop
- Balls have to go through everyone which means everyone has an implied role
- Encourage acts of leadership at all levels
- Assumption-driven change was led by all team members, divided into groups. There was no sponsor imposing the changes.
The 6 fundamental practices of Kanban
- View the stream
- The flow is visible thanks to the balls
- Limit work in progress
- The limitation of the work in progress is experienced during the workshop. If it does not come from the group itself, I invite it to experiment with the treatment of a single bullet, which allows the notion to be introduced.
- Manage flow
- The measurement of the different times during the workshop
- Make the rules of the process explicit
- Moments of continuous improvement between iterations allow the group to define an explicit mode of operation for each
- Implement feedback loops
- Hypothesis reviews correspond to feedback loops
- Improve collaboratively, evolve experimentally
- The construction of experiments driven by the hypotheses is a collaborative work in sub-group
- The formal adoption of the change only appears after having validated it experimentally
Conclusion
I leave this event with very good memories: a top organization, a tiring but very rewarding day! The exchanges with the participants were very interesting and I hope I was able to combine the useful and the pleasant in the context of my sessions around Kanban.
The revisited Ball Flow Game seems in any case to have made a good impression, I would probably rework it to give it a little more fluidity. Christophe Keromen suggested that I use a model (whose name I forgot) describing different spaces of change - processes, people, structure and tools - which would allow participants to focus first on experiments related to process before tackling the structure.
A big thank you to the organization team for giving me this opportunity and of course to all the participants who had to support me during one, or even 2 sessions! 🙂
See you next year ? 😉
