We do a lot of training here at LitheSpeed, and our exercises are consistently among the most popular parts of our courses. We’ve had many requests over the years from participants, coaches and other trainers to use some of these exercises when instructing teams, and since we’ve garnered many of them from the community ourselves, we tend to readily accede.
Here is one simple but powerful exercise that can be used to demonstrate several aspects of flow, value and teamwork: The Dice Game.
Materials: Obtain 10-15 multisided dice per group of 5-7 people. Transparent dice and ones with un-inked numbers can help make the exercise more challenging (and realistic). You can get these at any store that specializes in board games.
Setup: We are building an application, and each die represents one feature (or User Story) that our customer values. We’ll compare several different ways to perform this work, including a waterfall delivery method, continuous flow/Kanban, and Scrum.
Time limit: 2 minutes per round
Roles:
- ScrumMaster: Ensure rules are followed, add up points
- Product Owner: Accept delivery to confirm receipt of points
- Team: Each person on the team will turn the dice in a certain way to represent a specialized activity, such as analysis, design, development and testing.
Define an activity for each participant except for the ScrumMaster and Product Owner. For instance:
- Analysis would be performed by turning a die and placing it on the table such that the number 1 is facing up.
- Design would be performed by turning a die and placing it on the table such that the number 2 is facing up.
- Development would be performed by turning a die and placing it on the table such that the number 3 is facing up.
- And so on, ending with the Product Owner, who turns the dice one more time to accept them.
Feature Scoring: Teams get 1 point for every die that has been completed (proceeded through all of the defined activities by turning the dice through each number). For instance, if you defined five activities (e.g. Analysis, Design, Development, Testing, Deployment), the die would have to be turned to 1, then 2, 3, 4 and 5 sequentially; when it reaches 5, it is Done and gets the point.
You can also choose to give more points by die complexity (e.g. 1 point for 4-6 sides, 2 points for 7-9 sides, 3 points for anything more complex). This makes the Product Owner role more meaningful and challenging.
Release Scoring: 10 points for every complete set of one die shape (e.g. all of the cubes, or all of the tetrahedrons). You can also use similarly colored dice to represent Releases.
Delivery Method Variations: Each team or table can represent a different method of delivery. We usually have everyone do this in parallel, working within the same two-minute timebox, and then we compare results at the end. Common variations include:
- Waterfall – Every person represents a different specialty (e.g. analysis, development, testing). Each person must flip every die before the next person may begin.
- Continuous Flow/Kanban – Every person represents a different specialty as above, but only has to flip one die before passing it along, resulting in a steady flow of value. If multiple rounds are performed, teams can look for bottlenecks (where a few dice pile up consistently in front of someone) and adjust the amount of dice allowed to be in one’s “outbox” as needed to reduce these bottlenecks. For instance, the person representing Design may be able to place 2 dice in Development’s queue, but no more, while Development may be allowed to place 3 dice in Testing’s queue.
- Scrum – The same activities must be performed to deliver a feature as above (e.g. turning each die through each defined number), but here teams are asked to design their own process, choosing how to address the “backlog” of dice and who will do what. It is allowed for a single person to flip a die through every stage, if desired; here, the metaphor would be that this person represents a cross-functional team by themselves. This variation works best across a few rounds, as teams can then inspect and adapt.
Debrief: Several learning points tend to surface during this exercise. The instructor can ask each group many different questions to help cement these points, such as:
- Did you feel like a team? (typically, Waterfall group: no, Kanban group: sort of, Scrum team: yes)
- What would happen if something happened to kill the project 75% of the way through? (Waterfall: disaster, Kanban & Scrum: we would already have the presumably highest value features built at that point)
- [For Kanban team] Did you see any bottlenecks forming? How would you deal with them? (people should help those performing downstream activities, requiring some skill overlap and sharing)
- [For Scrum team] Did you change your process midstream at all? How would you change things next time to be even better? Did you encounter any dice that could not be processed? (e.g. if you have tetrahedrons, but there are 5 or 6 steps total, they will be impossible to finish, representing a technically infeasible feature; most people won’t realize this until already well underway, demonstrating that actually doing something is a quick way to learn about how to do it properly, whereas vacuum-chamber analysis often misses such things initially)
Key Learning Points:
- Value is delivered more rapidly in small batches
- Steady delivery of features mitigates the risk of non-delivery
- Small batches reduce the impact of customer changes (you can demonstrate this by changing the activities or scoring mid-round at some point)
- Teamwork is more prevalent when activities are shared and when there is frequent interaction
- New skills can be built over time by frequent interaction between those performing neighboring activities, leading to more polyskilled team members and hence more fruitful collaboration
- Work in small batches is less complex (e.g. flipping one die is easy, but it’s harder to keep track of the state of 15 dice at once)
- Optimal release strategies can maximize the flow of value, hence the necessity of the Product Owner role
That’s it! We hope you find this useful in educating your teams, and if you have any great exercises that you’ve used yourself, we would be thrilled to hear about them. Until next time…
When leading development teams, I see most of the wasted activities happen during the development phase. If work is not ready before development begins, there can be delays waiting for clarifications from the business. If acceptance criteria is not clearly defined before development begins, work can go on and on as the team tries to appease the customer. What your agile team needs is a clear definition of "Ready to Work" and a clear definition of "Done with Work". Though definitions vary from team to team and organization to organization, it's imperative that you do it. It's also imperative the team writes the definitions, not someone in an ivory tower.As with all of our clients, my colleague Bob Payne and I stress the need to have a minimal agreement on both definitions before work is started. When defining both the entrance and exit criteria, all major parties within the team need to be involved, to lower risks that something will be missed.Below are examples of the definitions of ready and done. Notice that we consulted analysts, testers, and developers. For your team or organization, you may consult UX designers, DBAs, architects or others. Don't make your definitions overly onerous. Just create something that is just good enough and go from there.
Subscribe to the RSS feed