A quick and easy demonstration/game to illustrate why an agile team needs to do refactoring and the related XP Practices in addition to Scrum. It never fails to create the A-HA moment for a team and team management as to why, when and how to do refactoring.
Scrum without XP will lead to technical debt and ultimately a legacy system.
Timing: 30-40 minutes including prep and debrief
Materials: Tools, supplies and environment
You will need an area/room where you can clear a game area we will call the gauntlet. Gauntlet area needs to be 15-30 feet long and 6-10 feet wide. Typically I find myself in a room where you just shove the tables and chairs out of the way to clear this space. Keep the chairs nearby as you will need them.
In addition to the space you will need :
Volunteers and Roles
You need 7-12 volunteers. Ask for volunteers with warning that it is a physical demonstration and there will be running. Do not volunteer unless comfortable with this.
Divide the volunteers into testers and developers using one of these formations depending on the number of volunteers
Divide devs into two even groups
Have everyone in the room clear a space for the gauntlet and place one dev group at each end of the gauntlet in front of a To do/ To Test kanban board
Populate the TO DO portion of the board with sticky notes as shown.
You will need around 20.
(These empty notes represent a task or story.)
Place the tester(s) at the mid point of the gauntlet in front of the done board/flip chart/easel.
Your gauntlet area should look something like this …
Timer volunteer – (Can be the facilitator if no-one else volunteers). This person will need to have an app or device that has a 30 second countdown timer.
Explain to participants that this is a simulation. The goal is not to “win” and game the system. The goal is to mimic what real life looks like.
Instruct participants to act like a dysfunctional team and not communicate with each other (otherwise they start gaming the system).
They should all be in their locations as below :-
Start the Game!
Sprint 0 – Practice
Run this 30 second iteration with taking the velocity. Correct any misunderstanding and assumptions that anyone may have.
(There is another reason for running a practice sprint is because without doing so, the velocity for the next sprint will go up even if you put more obstacles in. The reason I believe is because once they understand the game, they get better at it. So give them a grace understanding sprint.)
Sprint 1 – Calibration
The goal of this sprint is to find out what their Scrum velocity is. Let them run the gauntlet with no obstacles. At the end record the velocity which is how many tasks are in the Done areas.
e.g. Sprint 1 – 13
During the sprint the facilitator can play the role of a pushy manager and shout at the team. See below for examples of things to shout.
Ask the team if they feel puffed out / exhausted. Ask if they think they can sustain this pace?
Point out that in scrum they call an iteration a sprint for a reason… (joke)
Reset the boards for the next sprint.
Sprint 2 – Introduce technical debt
Describe to the room that what they have just seen is what happens in scrum. Management want you to run as fast as you can and get features in.
But what is happening while you are introducing new features to the code base you are also introducing technical debt. For every story completed you left behind debt.
Ask the room if in their environment they have technical debt. (Yet to have a no come back to this question.)
Now grab chairs from the sidelines and place them randomly in the gauntlet area to represent the technical debt. Place them purposefully to make running the gauntlet difficult.
Re-iterate to the runners that this is a simulation and the goal isn’t to game the system and win. Re-iterate that they are simulating a dysfunctional team and are not to communicate with each other (to collude).
Double re-iterate safety! No jumping the chairs. Please be sensible and careful!!!
Now run the second sprint. Again take on the role of pushy manager and include in your taunts : -
Take the velocity of the second sprint.
e.g. Sprint 2 – 10
Note – it actually takes putting quite a few chairs in the gauntlet to impact velocity in this sprint. I usually put in 10-15.
Sprint 2a – Legacy system (but don’t run this sprint as it’s too dangerous)
Have the runners reset their boards for the next sprint.
While they do this – place more chairs in the gauntlet while explaining to the room “for every story you get done, you are adding more technical debt”.
Make the gauntlet almost impossible. Now speak to the room about this is how you create a legacy system. You leave debt behind on top of debt.
Point out to the managers in the room that this is what it is like for a developer. To come in and face a messy codebase and be expected to add value to the system every sprint without ever having time to clean it up.
Ask the room if the gauntlet is now representative of their codebase and running it representative of their job.
Ask them what they think will happen to velocity for this sprint. Ask them what they think will happen if they keep going forward in this way.
Do not run an iteration under these conditions – it is now too dangerous. You will break things (just as you break the code when you try to add new features to a legacy system).
Instead we are going to find a solution…
Sprint 3 – Introduce refactoring and find what their sustainable pace is
The new rule for this iteration is – refactoring.
For each story that you work on you are allowed to do some refactoring – cleaning up of the codebase. This is represented by being able to move one chair out of the gauntlet for each story you are working on.
You will also no longer run – but walk. We need to find a sustainable pace and we need to move more purposefully and carefully.
Walk, don’t run.
During this sprint the facilitator can call out management stressors like :-
At the end of the sprint record the velocity and have everyone return to their seats for the post exercise discussion.
Management Abuse to shout at game players
Post Exercise Discussion
At this point your velocity will look something like :-
Now talk about what the numbers mean.
Sprint one represents what happens when companies take on Scrum. They become excited about the ability to get things done quickly. Because Scrum does not include any technical practices the usual pattern is to ignore them but now the Product Owner and business is used to a certain cadence of delivery. What they don’t realize though is that it is not sustainable and they are incurring a debt with compounding interest. i.e Technical Debt
Sprint two represents what happens over time as the debt starts to build up. You are ignoring the agile principle (behind the Agile Manifesto) of :-
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Sprint three represents Extreme Programming and sustainable pace. You are now writing code in a sustainable way where it is easy to add new features and the technical debt is kept in check. Refactoring is part of coding. You should not need to ask permission to do it, you must do it as part of writing code. But this may cause a change in your coding culture and processes. This is the next part of the discussion.
These are all distinct topics that are raised by the exercise and should be discussed. It would make this article a little too long if I include what to address to all of these here so I shall add links to blog articles as I write them. To start with however you can look at :-