Link to this game is here.
I work with many teams who want to reap the benefits of applying the Agile principles without feeling the compelling need to change themselves in order to follow specific methodology. Those teams are committed to quality, however, they want to do things their own way, specifically those teams want the following:
- Avoid organizational changes
- Maintain the current structure, title and role.
- A way to bridge to the new development paradigm.
- Learn and grow.
This game helps to visualize the team’s interactions for the purpose of enhancing these interactions for implementing the Agile principles.
How to apply this game?
I suggest that you use historical data to arrive at the parameters of the game, otherwise rely on expert judgement of team member. Some f the answers required to configure this game are:
- What are the product and/or components handled by the team?
- Who are the product owner/business analysts? Is every product specialized on one product?
- What are the portfolio requests which this team addresses? For example, New Feature, Architecture Improvement or Bug.
- What are the applicable Class of Services? For example, Regular, Expedited and Fixed Date.
- How often the product owner help is required by each stage?
- How skills are interchangeable and how they can be applied to various stages? For example, both Designers and Developers can do code review.
- What is the business value associated with various product portfolio?
- What are the stated or non-stated actions which the team members do based on the combination of Class-of-Service, Product and Portfolio? Should we make those actions explicit and well communicated?
Maximize the US$ value of each release which is created at predetermined intervals while adhering to individual constraints of each card.
How this game emphasizes the Agile principles?
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The game dynamics is to have the team members implement what it takes to facilitate the flow of cards (requirements) through the various stages. For me the focus on enabling the flow provides high priority to continuous customer delivery.
Business people and developers must work together daily throughout the project.
The participants of this game are product owners, designers, UX, devs and testers. They participate in various stages. The product owner is actively involved in each stage by having one rule of the game to continuously determine whether the product owner help is required.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The Pull system implemented by this game, requires the players to take initiative of pulling the work themselves. The player is responsible on:
– Maintaining the flow.
– Maximizing the business value based on decisions he makes on what to pull next, provided there are more than one pulling option.
– Participating in the work of multiple stages.
Working software is the primary measure of progress.
The defined metrics are:
Throughput: This is the number of cards released.
US$ business value of the release: Total of US$ of individual cards of a release.
Cost of the release: This is the man-hours of all players in addition to x man-hours to create the release.
Target vs Actual: It’s a common practice in software to have target date for various requirements with possible SLA implications.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This games establishes WIP limit per stage which balances the work load for the players who can participate in the stage work. As the WIP limit is observed, we would start recognizing issues as result of adding more work to the stage. Those issues should be resolved separately while maintaining the Pull system.
Metrics and reflections
The game collects data about every card, then metrics and Cumulative Flow Diagram (CFD) are produced with every release. Players meet and retrospect while supported by the metrics and their own experience in practicing the game. The players collectively agree on actions to improve their system which include:
– Tune the WIP limits
– Revise the policies of pulling cards
– Add new stages to improve quality
– Implement engineering practices
– Cross train of team member so that they can participate in multiple stages