Sudokuban&agile values
•Transferir como PPTX, PDF•
4 gostaram•805 visualizações
This document discusses an activity called Sudokuban which uses the concepts of Kanban to play a game of Sudoku. It explains the basic rules of Sudokuban which involve forming teams of Scrum Masters, experts and observers to complete Sudoku puzzles within time limits while not exceeding work in progress limits. Mini retrospectives are held between rounds to reflect on what worked and ways to improve. The purpose of the activity is to help participants experience Kanban concepts like visualizing and limiting work in progress in a fun and engaging way.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Destaque
Destaque (20)
Semelhante a Sudokuban&agile values
Semelhante a Sudokuban&agile values (20)
Mais de Renee Troughton
Mais de Renee Troughton (17)
Último
Último (20)
Sudokuban&agile values
- 2. Familiar? 4 activities 4 artifacts 3 roles Sprint Planning Daily Scrum Sprint Review Retrospective Product Backlog Sprint Backlog Sprint Burndown Product Burnup Scrum Master Product Owner Scrum Team
- 3. The growth of Agile-esk methods Scrum Kanban eXtreme Programming Lean Startup SAFe FDD DSDM Crystal Cynefin Radical Management Stoos NVC Rightshifting Lean Beyond Budgeting
- 4. Disruptive vs evolutionary Scrum Kanban eXtreme Programming Lean Startup SAFe
- 5. The basics Visualise & Manage Flow Make Policies Explicit Limit Work In Progress Pull Work Implement Feedback Mechanisms Improve Collaboratively with metrics
- 7. Sudokuban rules 1. Up to 5 teams can be around the room. Each team has to have: 1 Scrum Master / Visual Leader Sudoku Experts Quality Assurance 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 The Rules10 mins
- 8. Sudokuban round 1 Mini retrospective 1.What worked well? 2.What to do differently? Choose new WIP limits The Rules10 mins
- 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” 2. Setup a wall with flow states 3. Break it flow into two subflows – “in progress” and “done” 4. Move cards real-time 1. The User Story Wall is an accurate reflection of work status at any point in time 2. The team are watching all User Stories 3. Information is not hidden Sprint Backlog Analysis Dev DoneTest Deploying
- 11. Manage Flow Doing Managed Flow Being Agile 1. Watch for constraints arising and proactively course correct 2. Adjust number of specialists or WIP limits if needed 3. Track throughput using a Cumulative Flow Diagram 4. Understand your cycle time and lead time and work these down 5. Have an approach for handling the unknowns, eg. Production support issues 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 2. Can do away with Sprints, but still need to have some of the cadence activities 3. Impact to the flow is known when “rush work” is done 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 Being Agile 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 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 2. Always pull the highest priority work 1. The team work together to remove constraints when they cannot pull anymore work 2. By not pushing work it means that the team works at a sustainable pace Sprint Backlog Analysis Dev DoneTest Deploying 4 6 2
- 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 2. Initially set to people handling that flow state x 2 3. Only allow that number of stories or less in that flow state at a time 1. Limiting work in progress reduces context switching 2. It also focusses on doing more with less 3. And ensures that roadblocks are a key focus area 4. Reducing the WIP Limit will show the constrained areas Sprint Backlog Analysis Dev DoneTest Deploying 4 6 2
- 15. Want more?
- 17. The Agile Values Marshmallow Game
- 18. What are we doing today?
- 19. Group up!
- 20. Materials
- 22. Constraints
- 23. The Rules 1. Build the Tallest Freestanding Structure: The winning team is the one that has the tallest structure measured from the table top surface to the top of the marshmallow. That means the structure cannot be suspended from a higher structure, like a chair, ceiling or light. 2. The entire marshmallow must be on top: The entire marshmallow needs to be on the top of the structure. Cutting or eating part of the marshmallow disqualifies the team. 3. Use as much or as little of the kit: The team can use as many as a few of the 20 spaghetti sticks, as much or as little of the string or tape. The team cannot use the paper bag as part of their structure. 4. Break up the spaghetti, string or tape: Team are free to break up the spaghetti, cut up the tape and string to create new structures. 5. The challenge lasts 18 mins: Teams cannot hold on to the structure when the time runs out. Those touching or supporting the structure at the end of the exercise will be disqualified. 6. Adhere to your constraints: If you receive constraint cards, you cannot use them for your structure nor can you progress building your structure until all your constraints have been met.
- 26. Constraint cards Team 1 Team 2 Team 3 Team 4 Assign the following roles among the team: Project Manager, architect, builders, QA Assign the following roles among the team: Project Manager, architect, builders, QA Provide details of the proposed structure (incl diagrams) The client/product owner is available to you as needed. Create an agreement for how you will work with your client/customer. It must cover: • How you will work with them and keep them informed • A defined process for handling change • An agreed pricing model Create an agreement for how you will work with your client/customer. It must cover: • How you will work with them and keep them informed • A defined process for handling change • An agreed pricing model Create a detailed project plan as to how and when you will be involving the client in signoffs. • Only your project manager can create the plan • Review the plan with the client Provide details of the proposed structure (incl diagrams) Provide details of the proposed structure (incl diagrams)
- 27. The Agile Manifesto Values
Notas do Editor
- More details about this game and the cards for it can be found at: http://www.unbounddna.com/resources/agile-games/sudokuban-a-kanban-in-action-puzzle-game/
- Limit WIP – Stop starting, start finishing Limit 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
- This game was co-developed between Renee and Tyson Nutt. An official publication of it has not yet been made but hopefully it will be turning up onto Tasty Cupcakes and onto http://www.unbounddna.com soon! If you are interested, there is also a distributed version of this game which has a learning outcome of the impact of distribution of team on outcome effectiveness. More details on this can be found at: http://agileforest.com/2011/10/06/the-distributed-marshmallow-challenge/
- Building towers of awesomeness…. But with a little bit of Agile involved
- Handout equipment to each team when formed.
- Need scissors as well for the string, maybe paper bag to put everything in. For facilitator: need measuring tape and stopwatch
- Facilitator needs to make it clear that they are the client/product owner
- Time 10 mins then start this countdown
- These are the constraint cards for printing and handing out.