What is Dependency Poker?

Dependency Poker is a technique - a serious card game -that can help software development teams manage and minimize dependencies and mitigate risks associated with them. It involves a group discussion and clustering that helps the team identify, manage and solve dependencies between software components, features, and teams. To effectively carry out this process, teams need two kinds of cards: dependency cards and strategy cards. By analyzing the dependencies and selecting appropriate strategies to address them, organizations can optimize toward business agility, as they can more quickly and effectively respond to changes in the market and customer needs. This can lead to better outcomes, including increased customer satisfaction, reduced costs, and improved overall performance.

Dependency Poker Rules in a Nutshell 

1. Explain the dependency -type and breaker cards to the team by having each member grab a card and explain it with an example.

2. Place all dependency-type cards on the backlog item with the highest order, which is not refined yet, to gain a comprehensive understanding of the dependencies involved.

3. Work together to remove irrelevant or resolved cards, using consensus-based decision-making to ensure a shared understanding among team members.

4. Cluster the dependencies together, identifying clusters of dependencies rather than categorizing them based on types, to better understand how they are interconnected and develop strategies to manage them effectively.

5. Find, discuss, and commit to one or more strategies to handle the dependencies, using strategy cards and dot voting to identify the best options, and document the chosen options for further analysis.

How to prepare Dependency Poker?

Create and sort your Product Backlog

Before you can start with Dendency Poker, you have to create your backlog, which involves filling and sorting the backlog. This step is crucial as it helps the team to understand the work that needs to be done and establish priorities for the work.

1. Fill your backlog: The first step is to identify the work items that need to be accomplished for the project or sprint. These work items are typically represented as epics, user stories, use cases, or tasks.

2. Sort your backlog: Once all the work items have been identified, they need to be sorted based on their priority. The most important work items are placed at the top of the backlog, and the least important ones are placed at the bottom.

Sorting the backlog can be done in different ways. Some teams use the MoSCoW prioritization method, where work items are labeled as Must-Have, Should-Have, Could-Have, or Won't-Have. Other teams use the High/Medium/Low priority labels, or numerical scores to represent priority.

By filling and sorting the backlog, the team can gain a clear understanding of the work that needs to be done and the order in which it needs to be done. This step also helps the team to identify any gaps or missing pieces in the project or sprint scope and ensure that all necessary work items are included.

Create or find the right set of Cards

Your team needs to find or create the right cards to represent the different types of dependencies that were discussed in the first step. These cards can be created by the team, or they can be obtained from an existing source.

Backlog Refinement Cards

Backlog Refinement Cards can play a vital role in dealing with dependencies in the Dependency Poker process. They help to prioritize and clarify the tasks that need to be accomplished for a project or sprint, thereby allowing teams to gain a comprehensive understanding of the dependencies involved. By refining the backlog using these cards, teams can identify the work items with the highest dependencies, thus enabling focused efforts on these items first. Additionally, these cards facilitate a shared understanding among team members, promoting a consensus-based decision-making approach. As a result, these cards enable effective strategies to manage and mitigate dependencies, thereby contributing to the overall success of the software development project. The use of Backlog Refinement Cards is an integral part of the Dependency Poker process, ensuring clarity, focus, and effective management of dependencies.

Strategy Cards

The second set of cards needed for Dependency Poker are the strategy cards. These cards are used in the second step of the process to find strategies to deal with the identified dependency clusters. The strategy cards represent different strategies for managing dependencies and mitigating risks. Each team member takes a strategy card and explains the strategy it represents, providing an example to illustrate it. This step helps the team to find effective solutions for managing dependencies and reducing the potential risks associated with them.

Overall, the combination of dependency cards and strategy cards in Dependency Poker can help teams to effectively identify and manage dependencies, mitigate risks, and ensure the successful delivery of software development projects.

Strategic Domain-Driven Design

Strategic Domain-Driven Design (DDD) is a methodology that can help teams reduce and manage dependencies between different parts of a software system and between different teams by promoting collaboration and communication. By organizing code around well-defined business concepts, teams can ensure that each part of the system is responsible for a specific set of behaviors and interactions, which can reduce the risk of "spaghetti code" and minimize the need for teams to communicate and coordinate with each other. Additionally, Strategic DDD provides several domain-driven design strategies, such as Shared Kernel, Customer-Supplier, and Anticorruption Layer, that can help teams manage dependencies between different parts of the system and between different teams more effectively. Ultimately, Strategic DDD can lead to a more cohesive and effective software development process.

What are the "Steps" of Dependency Poker?

Explain the Cards to your Team

Before you can start with your first session with the team, you have to explain  Dependency Poker dependency types cards to your team. This step is important because it helps the team to understand the different types of dependencies that can exist between features or components and the potential risks and challenges associated with them. In this step, each team member will grab a dependency-type card and explain it to the other team members, providing an example to illustrate it.

Place all cards on the Backlog Item with the highest order

When using Dependency Poker, the first step after choosing a backlog item is to place all of the identified dependency cards on that item. This step is important because it helps the team to get a comprehensive understanding of the dependencies that are involved in the development of that particular backlog item.

It's better to start with all of the dependency cards because it provides a starting point for the team to work with. If there are no cards on the item, the team may not be aware of all the dependencies involved, which could lead to incomplete planning and unexpected issues during development.

By putting all cards on items, the team is also able to identify any inner resistance to dependencies. Sometimes, team members may have differing opinions about what is and isn't the exact dependency, and putting cards on items can help to surface these differing opinions so that they can be addressed and resolved.

Removing Cards

When the team starts with all of the dependency cards, they can then work together to remove the cards that are not relevant or that have been resolved already. This process of removing cards fosters collaboration because team members can discuss and evaluate each dependency card in greater detail. This can help to identify any potential risks or dependencies that may have been overlooked or underestimated.

Overall, starting with all of the dependency cards is a crucial step in the Dependency Poker process because it helps the team to get a comprehensive understanding of the dependencies involved in the development of a particular backlog item, and it fosters collaboration among team members.

In Dependency Poker, the consensus is recommended for removing cards from the backlog item. This means that all team members should agree on whether or not to remove a particular card before it is actually removed.

The reason for this is that dependencies can be complex and can have different implications for different parts of the system. Therefore, it is important to have a shared understanding and agreement among the team members about the dependencies and their impact on the backlog item.

By using consensus to remove cards, the team ensures that all members have had an opportunity to share their perspectives and contribute to the decision-making process. This can help to prevent misunderstandings and miscommunications that could arise if some team members are excluded from the decision-making process.

Consensus-based decision-making can also lead to more buy-in and ownership of the decision among team members since everyone has had an opportunity to participate in the process. This can help to build trust and foster a sense of teamwork among the group.

Overall, using consensus to remove cards in Dependency Poker helps to ensure that the team has a shared understanding of the dependencies involved in the development of the backlog item and promotes collaboration among team members.

Cluster your Dependencies

Once the team has identified the different types of dependencies using Dependency Cards or a, the next step in Dependency Poker is to cluster the dependencies together. It is important to note that different team members may have different views on dependencies, based on their unique perspectives and experiences. 

The focus during this step is on identifying clusters of dependencies, rather than simply categorizing them based on their types. For example, a cluster of dependencies could be identified as "frontend dependencies" or "database dependencies," depending on how they relate to each other and impact the development process.

By clustering the dependencies, the team can gain a better understanding of how they are interconnected and develop strategies to manage them more effectively. This step can help identify potential risks and dependencies that may have been overlooked or underestimated, and ensure that the team is working together to address them.

Finding, defining and commiting on Strategies

After identifying and clustering dependencies in Dependency Poker, the next step is to find, discuss, and commit to one or more strategies to handle the dependencies.

To do this, every participant in the game should receive a set of strategy cards. Each strategy card represents a possible approach for handling dependencies. The participants should then throw all possible strategy cards on the cluster of dependencies and discuss which strategies are most appropriate and effective.

The goal of this step is to arrive at a shared understanding of the dependencies and agree on a strategy or set of strategies that the team will commit to in order to address the dependencies. It is important to encourage open and honest discussion during this step to ensure that all team members have a chance to share their opinions and ideas.

Once the team has agreed on a strategy or set of strategies, they should commit to implementing them. Dot voting can be used to help identify the best options, and the team should document these options for further analysis after the planning poker session. By committing to these strategies and documenting them, the team can ensure that they are making progress toward resolving the identified dependencies and continuously improving their development process.

Overall, the strategy-finding step in Dependency Poker is designed to ensure that the team has a shared understanding of the dependencies involved in the development process and agrees on a plan for addressing them. This can help to improve collaboration, reduce project risks, and increase the likelihood of successful outcomes.

After the Dependency Poker Session

Updating the Dependencies in a Dependency Board

After the Dependency Poker game has been played, and the team has identified and clustered dependencies and agreed on a strategy or set of strategies for handling them, the final step is to update the backlog items.

The refined backlog items, along with their dependencies and the agreed-upon strategies, should be displayed on a dependency board. The dependency board is a visual representation of the development process that helps to keep the team focused on the dependencies and strategies they have identified.

Updating your Backlog

The dependencies and strategies should also be documented in the backlog items themselves. This ensures that everyone involved in the development process, including new team members or stakeholders, is aware of the dependencies and strategies that have been identified and agreed upon.

Documenting dependencies and strategies in the backlog items also helps the team to track their progress in addressing dependencies over time. This can help the team to stay focused on their goals and ensure that they are making progress towards addressing the dependencies.

Overall, displaying the refined backlog items on a dependency board and documenting the dependencies and strategies in the backlog items is an important final step in the Dependency Poker process. It helps the team to stay focused and accountable for addressing dependencies, which can ultimately lead to a more successful development process.

Identify patterns and optimize

After the Dependency Poker game, the last phase is to analyze the dependencies and identify any patterns that emerged. This analysis is crucial for understanding the root causes of the dependencies and determining whether they can be solved through better architecture, new team topologies, or other support from the organization.

By examining the patterns that have emerged, the team can begin to make informed decisions about how to approach these dependencies. For example, if there is a pattern of dependencies between certain teams or components, it may be necessary to reorganize the teams or refactor the architecture to reduce these dependencies.

It's also important to have an open and honest discussion about any challenges or limitations that may prevent the team from implementing these solutions. By working collaboratively and taking a data-driven approach, the team can identify the most effective strategies for addressing the identified dependencies and ultimately improve the overall efficiency and effectiveness of the development process.