Today’s blog post is from Ken Rubin, author of the Amazon bestseller, Essential Scrum. Here Ken offers us seven strategies for reducing or eliminating the impact of dependencies on large agile projects.
I’ve known and worked with Ken for over 20 years and learn something from him every time we interact. I’m sure you’ll find his thoughts interesting.
–Mike
Does your organization perform agile at scale, requiring the coordination of multiple collaborating entities to deliver value? If so, you know that to be successful at scale you must structure for the steady movement of work across the various collaborating entities. In other words, you need to achieve good flow by avoiding idle or blocked work. In this regard, dependencies are the number one killer of a company’s ability to structure for flow when performing agile at scale.
Structural and Instantiated Dependencies
A dependency is a relationship between two or more activities or resources that requires a level of coordination to achieve desired flow. Frequently organizations have structured themselves in a way that cross-entity dependencies are woven into the fabric of the organization. I refer to these types of dependencies as structural dependencies.
Let’s say UX designs are always done by the UX team and any time my team needs a design we must go to the UX team. In this scenario, my team has a structural dependency on the UX team.
If my team makes 50 separate requests of the UX team for different designs (“We need a design for the new sign-up screen!”), then each of those individual requests for a specific design represents an instantiated dependency.
For those with a technical background, think of the structural dependencies as representing object classes and instantiated dependencies as instances of those classes. So, the specific request to have the UX team design the new sign-up screen is an instance of the structural dependency that exists between my team and the UX team.
Now imagine if my team had UX skills on it and was no longer dependent on the UX team for design work. The result would be the elimination of the structural dependency between my team and the UX team. Eliminating a structural dependency has an amplifying effect because it also eliminates all future instantiated dependencies between my team and the UX team. In practice this means my team will never have to wait for the UX team to make us anything. The easiest dependency to manage is the one you don’t have!
Structural Dependencies Kill Flow
In my experience, the large number of structural dependencies in organizations is the primary cause of poor flow. We can use flow metrics such as flow efficiency (ratio of value-adding time to total elapsed time) and flow time (how long it takes to complete a work item) to quantify the impact of dependencies on flow.
In organizations that have done the modeling, we frequently confirm flow efficiency to be 10% or less. That means idle/blocked time represents 90% of the total time an item is considered In Progress! And only 10% of the total time is value-adding time. Even a modest (say 15%) improvement in flow efficiency has a large return on investment. Squeeze 15% of the waste out of the 90% idle/blocked time and you get a 13.5% overall improvement in flow efficiency. On a 15-week effort, a 13.5% improvement in flow efficiency would reduce flow time by just over two weeks and we would have the work item completed at 13 weeks instead of 15 weeks.
How do you squeeze out the waste and get the most significant improvement in flow at scale? Reduce the number of structural dependencies in the environment.
Remember, each structural dependency we eliminate means every future manifestation of that dependency (its instantiated dependencies) is also eliminated. You’ll notice I said reduce the number of structural dependencies. Organizations will not be able to eliminate all structural dependencies, so just set your sights on minimizing them.
Structural Dependency Improvement Framework
In my work with many large clients, I have developed and evolved a structural dependency improvement framework comprised of seven strategies.
These strategies can be classified as:
- Reducers – reduce the number of structural dependencies
- Enablers – enable organizations to adopt reducer strategies more easily
- Coordinator – establishes pre-defined coordination for those structural dependencies that can’t be eliminated
- Simplifier – makes it easier to deal with instantiated dependencies for those structural dependencies that can’t be eliminated
Here’s a quick summary of the strategies in this framework.
Reducer Strategies
- Create Feature Teams. Remember the earlier example when we moved UX skills onto my team? That’s an example of this strategy, which is by far the most common of the seven strategies. In fact, some people would claim that if an organization just created all feature teams, then there wouldn’t be a dependency problem.
Creating feature teams does substantially reduce the number of structural dependencies in the environment. However, there are impediments like insufficient skills capacity that will almost certainly prevent your organization from creating all feature teams. You should create feature teams wherever practical, and employ the other reducer strategies in the framework. - Organize into Coordinated Ecosystems. Here’s how I define a coordinated ecosystem:
An encapsulated, cross-organizational set of aligned resources created to deliver the outcomes of a durable, customer-focused product, value stream, business capability, or customer journey.
Coordinated ecosystems are an essential organizing unit for performing agile at scale. The alignment of resources within a single ecosystem—guided by a single product owner—substantially reduces structural dependencies and simplifies prioritization of each instantiated dependency. - Architect for Self Service. This means to enable a build-using coordination model. In this model, my team can complete its work without having to depend on your team because your team provides the mechanisms for my team to do the work ourselves.
Enabler Strategies (help facilitate the adoption of the reducer strategies)
- Strive for Cross-Functional and T-Shaped. The characteristic of being completely cross-functional (i.e., having all the skills to get the job done) is a requirement of both feature teams and coordinated ecosystems, and simplifies self-service approaches. T-Shaping the skills of people within a team reduces structural dependencies that exist within that team, in addition to making the team more resilient when something goes wrong.
- Establish Communities of Practice (sometimes referred to as centers of excellence, chapters, or guilds). Communities of Practice help overcome organizational resistance to establishing cross-functional teams and coordinated ecosystems by addressing concerns surrounding loss of conceptual integrity, reuse, shared learnings, etc.
Coordinator Strategy (since not all structural dependencies can be eliminated, we want to reduce the coordination effort of the remaining dependencies)
Establish Team-to-Team Working Agreements. These agreements pre-define how instantiated dependencies between the teams will be handled by addressing topics such as: intake process, decisioning process, interaction process, SLA (or cycle-time expectation), and deliverable-related metrics.
Simplifier Strategy
Balance System/Portfolio WIP. Basically, if we avoid overwhelming the teams with work, we reduce the number of dependencies they must deal with at any one time. We also reduce the number of different types of dependencies they must address at the same time. This strategy leverages the techniques of Agile Portfolio Management to balance WIP (work in progress) against the structural capacity of the organization.
Bringing It All Together
If you want to fight back against dependencies, it is important to combine the structural dependency framework strategies in a way that fits your organization. In most organizations where we apply it, we use all seven strategies to substantially improve flow when doing agile at scale.
If you would like to learn more about dependencies and the details of the structural dependency improvement framework, consider attending my class Dependencies Are Killing Your Agility: Learn to Fight Back!
