You have individual, self-organizing Agile teams and they’re working effectively but struggling in certain areas. You’ve spread Agile methods out across your organization, but are seeing challenges emerging with cross-team collaboration. There’s opportunity, but you need to decide: “When do you take the effective Agile techniques you’re using at the team level and scale them up to other parts of the organization?” If you’ve considered the reasons not to scale, and pre-requisites to scale effectively, this blog will help you with the next step by describing four signs that mean you’re ready to consider scaling agility.
Keep in mind the latest State of Agile report indicates that cultural issues like the general resistance to change, inadequate management support and sponsorship and organizational culture at odds with Agile values, continue to be one of the leading “impediments” to adopting Agile and scaling it effectively. When scaling you need to provide an environment that addresses cultural issues and makes it possible for your teams to self-organize to accomplish your goals.
1. Too many interdependencies
One sign is that you’re struggling to break work into independent deliverables that one or two teams can complete within expected timelines. As a result, teams are too reliant on each other. This tends to slow progress and lead to missed commitments. Better engineering practices such as increased automation (automated testing, CI/CD, etc.) may help, but often do not address the issue.
You might hear team members say:
- “We need to move this story to the next sprint since we are waiting on Team XX to complete their work.”
- “We planned to complete this story in the next sprint, but we just heard Team XX won’t finish the API we need until 3 sprints later. We have to slip it.”
Misaligned priorities can lead to similar outcomes, so keep an eye out for that before you commit to scaling up your Agile techniques.
2. Teams are duplicating effort
Another good indicator is that teams are recreating the same tools—like APIs, libraries, user experience (UX) patters, and user interface (UI) elements—instead of creating them once and sharing them across all teams.
You might observe:
- Common functionality—like “logging out” or account management—is different depending on which team wrote the code.
- Different teams building similar APIs to accomplish the same purpose—like managing user data or handling incoming orders—but doing so in different ways. It’s difficult to tell which one to use.
3. Your product lacks cohesion
If your product lacks a uniform customer experience or doesn’t have a coherent architecture, it’s another good sign that you’re ready to scale. Lack of cohesion leads to multiple problems: it makes it confusing for customers to navigate the product and find the services they need and difficult for teams to maintain the underlying applications and add new functionality.
You might notice:
- One part of the application uses multi-step forms while another uses large single forms.
- Entry forms use “Last name” and reports use “Surname.”
- Different teams use different coding languages (e.g. Ruby, Java, Angular, etc.) without clear rationales for them.
- Teams that use the same languages reference different libraries.
- Teams that work on the same applications use different branching strategies (e.g. release branch, feature branch, trunk development, etc.) making integration and collaboration more difficult.
4. Efforts to increase effectiveness have not been sufficient
Finally, if you’ve tried other alternatives to increasing the effectiveness of your teams and have seen little benefit, it’s time to consider scaling. You may have reached a point of diminishing returns, where significant effort at the team level leads to minimal improvement. Improvements at the individual team level can only go so far before they begin to create local optimizations that slow the overall rate of delivery. When that happens, you should consider scaling to bring Agile techniques up to higher levels and increase your overall effectiveness.
Some Guidance
The Manifesto for Scaling Agility provides some values and principles to help guide your decisions; this one is particularly applicable: Shared vision over aligned processes.
Like the Manifesto for Agile Software Development, while there is value in the items on the right,
we value the items on the left more.
A shared vision guides us. You want the teams to discover the best ways of working together. Having a clear vision of what we want to achieve will help the teams recognize when their interdependencies reveal a need to grow and scale. Focusing on aligned processes can impose unnecessary dependencies and inhibit your teams from discovering more effective ways of working.
We hope you find this post useful as your organization decides whether to scale agility. In our next post, we’ll explore some anti-patterns we have seen in organizations that have scaled.
Get your fill on Agile scaling with our other posts in the series:
- “4 Reasons Why You Shouldn’t Scale Agility”
- “Agile Scaling: Debunking 3 Common Misconceptions”
- “How Do You Know When To Scale?”
- “6 Signs Your Agile Scaling Isn’t Working”
- “3 Keys to Agile Scaling: The View of Our Experts”