Agile has a significant benefit that just about everyone can agree on: speed. In fact, faster product delivery was the most popular reason for adopting agile this year, according to the VersionOne 12th Annual State of Agile report. Agile can produce results much more quickly than the waterfall project approach, and speed to delivery is a critically important capability in today’s fast-moving business environment. So when dependencies get in the way of that speed, it can be frustrating for everyone involved.
The simplest way to think about a dependency is as a bottleneck — one that gets in the way of decision-making, progress or speed. Dependencies occur whenever a team doesn’t have everything it needs to deliver incremental value, whether it be a service, component or decision. Dependencies often exist to keep people accountable. As such, they are unavoidable when implementing Agile at scale. There are, however, dependencies that tend to manifest themselves in larger businesses that can be broken. Eliminating or managing the following five dependencies will position your teams to deliver on the promise of Agile:
THE FINANCE DEPENDENCY
The single biggest challenge with scaling Agile in a large enterprise organization is the dependency between change and finance. Change wants to use all available resources to start projects, explore new technology and run pilots…only to be hit by the annual budgeting process. Finance wants to understand what will be undertaken during the financial year, how much it will cost and when it will be delivered — essentially killing anything “agile” about the process. Finance shouldn’t constrict change, but this dependency is almost impossible to break completely in the modern world, where businesses are beholden to their balance sheets and shareholders. You can, however, implement other funding options to help improve the process:
Stage-Gate
Funding is released over time, only when a project has reached a predefined point or gate.
Time-Bound
Rather than budgeting over a year, teams request funding more frequently, e.g., per quarter.
Product- or Team-Based
This approach funds teams rather than projects. Each team is given an amount for the year with no definitive goals.
Continuous
Teams are able to pull funding whenever required.
Each of these funding methods has its pros and cons. While no one method completely eliminates the finance dependency, you can reduce its effects on speed.
THE DEVOPS DEPENDENCY
More than 70 percent of organizations have a DevOps initiative underway or planned for the next 12 months. An increasingly popular way to structure engineering teams, DevOps combines development and operations into a single team. With this approach, the people who are responsible for creating and developing the product are also responsible for the monitoring, operations and tech debt.
It might sound simple, but that’s only because we now live in a world in which the two are inseparable. Whereas technology used to exist to support operations, it is now such an integral part of almost every industry that separating development and operations no longer makes sense.
The biggest stumbling blocks to breaking this dependency are:
Team Size
Teams should be right sized to handle development and operational commitments. If you have too few resources, your team won’t have enough time for development. If you have too many, there won’t be enough interesting work to go around, which leads to the next consideration….
Engineer Ego
More senior engineers sometimes feel that routine tech debt maintenance work is beneath them, and only want to work on the most interesting projects.
Combining DevOps with an additional organizational transformation, as we’ll outline below, can help you address these challenges.
The architecture dependency
As with DevOps, Agile works best when the resources on any given team are interchangeable. Creating smaller, more autonomous teams with a singular focus allows them to be responsible for the end-to-end product and greatly reduces dependencies. You may hear this referred to in a variety of ways — product teams, tribes, scrum, etc. — but the goal is always the same: to breaking something large into smaller pieces. Teams can address any instances of “engineer ego” themselves, assigning the right level of work to the right person.
THE DECISION DEPENDENCY
Not all decisions and dependencies can be broken simply by making teams more independent. Change and leadership are here to stay, and those who are empowered to make decisions can often become a dependency. When just a few people are responsible for decision-making for many teams, there are a few approaches that can help ensure that work moves forward in a timely manner:
Empower More People
If a particular individual or department doesn’t have the bandwidth to make decisions in a timely manner, power needs to be delegated to more people.
Standardize the Process
Adding an online form or standardized email template that teams can complete is a great way to make teams responsible for driving decision-making. Assigning SLAs and priorities to requests also helps teams better define their timelines.
Schedule Regular Meetings
A standard weekly meeting or open house on the dependent team’s calendar gives others the opportunity to make requests and ask questions.
THE CODE DEPENDENCY
Organizations are built on multiple frameworks, libraries and languages, whether it’s JavaScript, C#, Java, PHP, Python, HTML5 etc. Some of these are internal and can be controlled within the business, but others are third-party dependent. All, however, present an opportunity to break dependencies.
Internal
When code is written and owned by the organization, dependencies can be broken by reducing the number of languages and creating standards for those that do exist. This can be a significant undertaking, but a common language and set of standards can break teams’ dependencies on each other. It also makes the business less dependent on individual engineers, who can themselves become the dependency on something they have written.
Third Party
Large portions of applications are created using external libraries of code that solve common problems. You can inject this code into your own internal library or externally reference it.
Although more time-consuming, injecting the code into your own allows you to break several dependencies:
1. You are no longer reliant on an external server connection that could be slow or go down at any time.
2. If the code is updated or changed, it won’t have an immediate or potentially negative impact on your application.
3. The time it takes to understand and inject the code increases your engineers’ understanding of it and reduces the dependency on external, unknown individuals.
Every organization is different, and every Agile implementation is different. Take a look around your business and ask yourself, “Where could we move faster?” You’re likely to find a dependency waiting to be broken.
