Your SlideShare is downloading. ×
0
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Sudokuban - A practical Kanban learning game
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sudokuban - A practical Kanban learning game

968

Published on

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 …

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.

Published in: Technology, Sports
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
968
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
37
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Limit WIP – Stop starting, start finishingLimit WIP & Pull work - Need to explain an expedite
  • A need can be met by multiple strategies. Understanding the need can help to ensure that we are not focussing on the wrong strategy.
  • A need can be met by multiple strategies. Understanding the need can help to ensure that we are not focussing on the wrong strategy.
  • Explain class of service
  • A need can be met by multiple strategies. Understanding the need can help to ensure that we are not focussing on the wrong strategy.
  • Image: http://cdn.drstevegreene.com/wp-content/uploads/2012/03/Traffic_light1.jpg
  • Transcript

    • 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

    ×