Sudokuban is a Kanban in practice example activity that takes about 20-25 minutes to run. This is the slidepack that goes with the game to briefly introduce Kanban before the game and then give some more in depth information afterwards. The benefit of a Sudoku based game is that it mimics the software development process more closely - ie requires in depth, concentrated effort, where pairing could hamper the concentration. The sudoku game pack comprises of 12 sudoku puzzles, setup partly in progress in flow with low WIP limits. Quality issues are embedded into the pack to ensure that failure occurs immediately and WIP constraints get met to force the change in behaviour. Expedites are added part way in (two closely together) to form behaviour around handling them. Team will generally learn: 1) How to use WIP limits 2) How to swarm to remove blockers 3) How to handle expedites 4) To re-prioritise according to value 5) The value of someone still looking out for the team's flow Conducted at Sydney's AgileTour 2013.

1. Renee Troughton

2. Familiar?
4 activities
4 artifacts
3 roles
Sprint
Planning
Product
Backlog
Scrum Master
Daily Scrum
Sprint
Backlog
Product
Owner
Sprint Review
Sprint
Burndown
Scrum Team
Retrospective
Product
Burnup

3. The growth of Agile-esk
methods
Cynefin
Radical Management
Stoos
NVC
Rightshifting
Lean
Scrum
Beyond Budgeting
Lean
Startup
SAFe
Kanban
eXtreme
Programming
FDD
DSDM
Crystal

4. Disruptive vs evolutionary
SAFe
Scrum
Lean
Startup
Kanban
eXtreme
Programming

5. The basics
Visualise
& Manage
Flow
Make
Policies
Explicit
Limit
Work In
Progress
Pull
Work
Implement
Feedback
Mechanisms
Improve
Collaboratively
with metrics

6. Sudoku basics

7. Sudokuban rules
1. Up to 5 teams can be around the room. Each team has to have:
1 Scrum Master / Visual Leader
3 Sudoku Experts
1 Quality Assurance
1 Reporter
Observers or timers are allowed
2. Teams must not break their work in progress limits, unless to handle
expedites appropriately
3. The objective of the game is to be the team that has achieved the most
value by the end of the timebox

8. Sudokuban round 1
Mini retrospective
1.What worked well?
2.What to do differently?
Choose new WIP limits

9. Sudokuban round 2
Mini retrospective
1.What worked well?
2.What to do differently?
3.What still puzzles you?

10. Visualise Flow
Doing Visualised Flow
Being Agile
1. Understand the steps that every User
Story will need to go through to get
“done”
1. The User Story Wall is an accurate
reflection of work status at any point in
time
2. Setup a wall with these flow states and
the Sprint Backlog
2. User Stories are moving like a leaf in a
stream and are not getting stuck on
rocks
3. Break it flow into two subflows – “in
progress” and “done”
3. The team are watching all User Stories
4. Move cards real-time
4. Information is not hidden
Sprint
Backlog
Analysis
Dev
Test
Deploying
Done

11. Manage Flow
Doing Managed Flow
1. Watch for constraints arising and
proactively course correct
2. Adjust resources or WIP limits if
needed
Being Agile
1. Do away with estimation if work is
all the same size and the cycle
time and lead time is known for
the class of service
3. Track throughput using a
Cumulative Flow Diagram
2. Can do away with Sprints, but still
need to have some of the
cadence activities
4. Understand your cycle time and
lead time and work these down
3. Impact to the flow is known when
“rush work” is done
5. Have an approach for handling
the unknowns, eg. Production
support issues
4. Metrics are gathered for
suspected problem areas and
used as a means for decision
making
5. The team as a whole take
responsibility for reducing the
cycle and lead time

12. Make policies explicit
Doing Explicit Policies
1. Write up known constraints (either
self-imposed or imposed from
others)
2. Use this area as a discussion
opportunity to challenge the
constraints with the imposer
3. Gather metrics if necessary on the
impact of the constraint
Being Agile
1. Management and other teams are
open to being challenged on
policies where their value is in
question
2. How information moves and is
deliberately restricted is visually
represented on the User Story
Wall and anyone within the team
can walk external people through
it

13. Pull work
Doing Pulling work
Being Agile
1. Pull work if you are able to
actively work on it AND if your
Work In Progress limits allow it
1. The team work together to remove
constraints when they cannot pull
anymore work
2. Always pull the highest priority
work
2. By not pushing work it means that
the team works at a sustainable
pace
Sprint
Backlog
Analysis
Dev
Test
4
6
2
Deploying
Done

14. Limit Work In Progress
Doing Limit WIP
Being Agile
1. Set limits to the number of stories
that can be in flow states after the
Sprint Backlog and before
Done/Completed – ie Analysis,
Development, Test
1. Limiting work in progress reduces
context switching
2. Initially set to people handling that
flow state x 2
3. And ensures that roadblocks are
a key focus area
3. Only allow that number of stories
or less in that flow state at a time
4. Reducing the WIP Limit will show
the constrained areas
Sprint
Backlog
2. It also focusses on doing more
with less
Analysis
Dev
Test
4
6
2
Deploying
Done

15. Want more?

16. Renee Troughton
agileforest.com
leanpub.comAgileForest
renee@unbounddna.com
@agilerenee
theagile
revolution.com
unbounddna.com