Keep use case flow within the team.
There are four prior posts in this series on dependency breaking:
- Introduction: Presented the case for removing dependencies to support the Agile mindset and drive control into the Agile team.
- Task Level Part 1: Supplied a simple pattern that keeps tasks within the team—the cross-functional feature team.
- Task Level Part 2a: Provided context for common anti-patterns that impede a team from finishing what they start.
- Task Level Part 2b: Outlined how vertically sliced stories and swarming can combat the desire to start something new versus finishing what was started.
In this post, we turn the focus to breaking feature-level dependencies. Feature-level dependencies occur when two features depend on each other to complete a use case flow. Like other dependencies, feature-level dependencies can bring significant waste to your delivery teams, impeding their ability to effectively and efficiently deliver value. Breaking feature-level dependencies will calm the chaos.
This fifth post in the series describes how to break feature-level dependencies between teams.
Use Case Flows Create Dependencies Between Features
As a means of conveying how dependencies emerge between features, consider the product story map in Figure A for a hypothetical expense reimbursement system.
There is an inherent dependency between the four primary activities of expense reimbursement shown in the example story map. Expenses must be managed before they can be submitted, expense submission must occur before approval, and only approved expenses will be reimbursed. As a result, the features that enable each activity also have dependencies that are driven by various use cases.
As an example of how dependencies exist between the features, assume the product owner decides that the top two use cases to deliver first are base path use cases for reimbursing billable and non-billable expenses. These use case paths through the features are shown in Figure B.
Each step in the use case is dependent on the prior step. This drives dependency between the features associated with each step in the use case. For instance, billable expenses cannot be submitted for approval and reimbursement until they have been entered into the system.
Assume two teams are working on the product. How should the teams pull the features into their sprint backlog to reduce dependency? Teams could pull work based on feature specialization or they could pull work based on use cases. From a dependency perspective, team specialization on a feature area increases dependencies. When teams own work across use cases, dependencies are reduced, and the team is in control of delivering end-to-end value. These two patterns are outlined below.
Anti-pattern: Team Feature Specialization
A common anti-pattern that many teams fall prey to is focusing on or aligning to particular feature areas. The expected benefit of this approach is that a team develops a deep understanding of a particular feature and is better able to enhance and support it over time. The other expected benefit is that many teams can work simultaneously on their individual feature specialties to deliver an end-to-end use case faster.
Figure C illustrates a possible application of this approach.
In Figure C, Team 1 has focused on features related to entering and submitting expenses. Team 2 has focused on features related to approving expenses and sending checks to the employee for reimbursement.
As a result, Team 2 depends on Team 1 to complete either use case. Unless the entire use case is completed, the user outcomes cannot be achieved. Neither team owns the end-to-end value flow.
From the original post in the series, we know that dependencies introduce significant waste and complexity. Dependencies increase the effort to deliver the end-to-end use case and slow down overall value delivery for the product.
Aside from dependencies, having a team focus on select features reduces knowledge proliferation across teams. You will have more flexibility and less risk when more than one team understands a feature and how to enhance and support it. Feature specialization works counter to these benefits.
Given the inherent dependency waste and knowledge risks, teams having a feature specialization is not the preferred method.
Corrective Pattern: Teams Work on Features Across a Use Case
When teams care less about owning a particular feature and more about delivering an end-to-end use case across multiple features, they will gain control. A team gains control by removing dependencies and increasing team capability to easily enhance and support a large portion of their product feature set. Figure D outlines this approach.
While it may take longer for one team to deliver an end-to-end use case using this approach, the systemic benefits are worth it. Teams will deliver with less effort, will gain future flexibility to work across multiple features, and will likely take less time to deliver all scope for a particular release backlog.
Conclusion
Keeping control within a team is critical for the expedient delivery of value. Reducing feature-level dependencies between teams when delivering value across a use case accomplishes this goal. As a side benefit, teams get a wide range of experience across many features of the product and reduce knowledge silos.
Stay tuned for the next post in the series—breaking organizational entity dependencies.
Other Posts in the Series
Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.
His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.