Does your team struggle to get items to Done? Do they experience a high amount of spill-over into the next cycle because they are waiting on another team or another person? Do items sit in a blocked state and age out while waiting on other teams or people to complete work?
Dependencies are an epidemic in software development. There could be many reasons why - perhaps your organization has adopted an Agile framework, but you're not yet structured to support sustainable teams. You may have a strong reliance on vendors or specialists when you start your Agile journey. And, some large-scale systems changes require some level of dependencies. The reality is, dependencies are not going to go away. As you scale your Agile efforts, the dependencies scale as well. The good news is, there are strategies you can use to move your teams from managing dependencies to mitigating dependencies.
What the Scrum Guide says:
“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.” - K. Schwaber and J. Sutherland, Scrum Guide, 2013
That's typically not the reality for teams new to Scrum, or organizations new to Agile. While cross-functional teams are the cornerstone of Agile, it might take a very long time for your organization to evolve. If you want to fully realize the benefits of Scrum, don't just manage dependencies, ruthlessly mitigate them. Read on to learn how.
Thing we hear (or say):
- Organizational Design: My team is mostly back-end; we rely on another team for the <…> (fill in with any component of software – front end enhancements, database layer, integration, API)
- Immature Agility: My team is using Scrum, but many of the other teams we work with are using more traditional approaches, like Waterfall
- Not Cross-Functional: My team uses a <Vendor / expert / lead > for a specialized skill, and they are in a completely different time zone
- Complicated Architecture: We work with so many different <systems, tools, technologies> that it’s impossible to be truly cross-functional and loosely coupled
- What are your “reasons?”
The Good, the Bad, and the Ugly
As with all things Agile, there is no silver bullet, no one-size-fits-all solution. There are some things we can do, however, to mitigate dependencies. Some are quick fixes, and some require longer-term, more involved solutions. The solution to ruthlessly mitigating dependencies lies in empowering people and enabling flow.
Got ugly dependencies? Let’s talk about getting to good.
In the short term, communication and proactive planning is key. For a longer-term, more empowering state, consider cross-training, opening up permissions, organizational design changes, even hiring and team forming strategies. It takes effort from everyone to see successes on a wide scale.
Short Term: Scrum of Scrums
A common approach to mitigating dependencies as you scale Agile throughout your organization is to use a scaling pattern called a Scrum of Scrums. In a Scrum of Scrums, delegates from each team meet to coordinate efforts and dependencies. A valuable practice is to visualize the dependencies and candidly prioritize according to the value and impact of the work. No pet projects or side jobs are allowed – all the dependencies must be made visible and evaluated against other demands. Another common practice is to ensure the decision makers are involved, so that resolution of impediments is fast and the group is focused on solutions.
If you are a team on the receiving end of dependencies, this is a good first step to relieve the need to attend multiple team meetings. But it is only one step on your journey to less dependencies - there is so much more you can do.
Long Term: Enable Flow, Empower People
Scrum Master or Tech Manager
Overall, be curious and ask powerful questions about each dependency. Don't accept the status quo - dependency mitigation is a complex problem without a clear solution. Open up a dialogue with the Scrum team, the leaders, even the Stakeholders to examine your work from various standpoints.
- Get work to "Done." If you aren't getting to Done, first, analyze what might be causing the problem: Are items too big? Are dependencies recognized during the execution of the work and not before? If items are just too big to be completed and fully tested within the time box, you may need to focus coaching and training efforts on vertically slicing small work items – with an emphasis on small. If the problem really is a dependency with another team or a specialist not on your team, discuss some solutions with your team, the Product Owner, and business leaders so they are committed to the behavior changes that are required to get items to a releasable state independent of other teams.
- Get the team involved. If the flow of work in your team has the hiccups, perhaps indicated by a high spill-over rate, lots of starts and stops on work in progress, or aging items, consider a retrospective on how to smooth things out. No-one knows better than the developers the art of the possible when it comes to using technology to solve problems. They are also the closest to the work, and they will have good insight to bottlenecks caused by permissions, controls, and expert knowledge only held by a few people.
Product Owner or Business Owner
Communication and preparation are key. So is saying 'No.' One of the best things a Product Owner or Business Owner can do is to be proactive about planning dependencies, sequencing work, and negotiating scope. The leader's role in Agile to stay ahead of the team and to make difficult decisions every day is critical to the success of the team. (Read my 5 tips to Emotional EQ as a Product Owner.)
- Plan at least 2-3 cycles ahead so that developers can help identify dependencies early. That will allow you to work with any other teams and get on their backlog and ensure the value of the request is communicated. Consider using the various planning cycles in Agile to allow your team three 'touches' to decompose work, from vision and roadmap, to release planning, to refinement.
- Communicate the value, not priorities or deadlines. When teams have to balance multiple stakeholders with competing requests, we want to focus the conversations on the business value, not the deadline. Clarify for yourself and others: What is the business impact if this dependency is not resolved when we ask for it? What if it is not resolved at all? Is this dependency really critical to deliver something of value, or just preferable?
- Teams should not begin a work item with an external dependency unless the other team is at the Planning Meeting to make their commitment, or unless the dependency is resolved before the work starts. Be willing to sequence work that requires dependency from 3rd parties, so your team can build out their learning and skills to support more of the dependent work and lessen the reliance on others.
Developers:
The Developers are the first line of defense when it comes to dependency mitigation.
- T-shaped Skills: Start cross-training wherever and whenever possible, so that more of the team can do more of the work. Consider pairing in when a specialist is needed, by having that person join your team for a few weeks to share the knowledge and expertise.
- Accountability: Ensure that any refinement activities are hands-on, in the code, in the database. Take a personal interest in identifying where there is a reliance on other parties during refinement, instead of relying on others.
- Agile Engineering: Consider how technology can assist, such as automation, micro-services, or continual integration to release as frequently as possible. Refactor code so that your team can work independent of others. Ask for permissions or controls to be lessened instead of accepting aging constraints.
Agile Leaders:
Enable Flow, Empower People. The role of managers and leadership needs to evolve as well as the organizational structure to support the move to cross-functional, self-organizing teams. The criticality of this element can be overlooked while it seems all eyes are focused on development. But no-one else is as uniquely positioned to make system-wide changes that can free up resources and remove constraints.
- Enable Flow: Conduct lean analyses such as Value Stream Mapping to identify waste and delays. Your goal should be to evolve your organization into rational value streams and sustainable teams with a plan for less and less dependencies outside the value streams.
- Empower People: Create a Culture of Empowerment - are there single points of failure in your organization? Are there multiple levels of review? Is it a culture of centralized decision making or one of de-centralized, autonomy-driven decisions that creates bottlenecks and dependencies?
The difference between enablement and empowerment is that enablement focuses on the act of assisting, while empowerment is the granting of power to individuals or groups.
Empowering Product Owners and Business Owners to say “No” helps them limit work in progress, re-focus work on the highest, most valuable items, and eliminate the waste of coordinating complex, dependence-ridden efforts. Empowering Scrum Masters and Team Managers with more permissions and less reviews enables the flow of information and data. Empowering teams to say yes, and do more, helps the whole organization realize the full power and effectiveness of a unified and motivated workforce.
How are your teams finding ways to end dependencies?
Julee Everett with Kim Andrikaitis
Hone your craft; speak your truth; show your thanks