Stop Scaling Agile And Start Untangling Dependencies

As an Agile organization grows, it goes through growing pains. With many Scrum teams working on the same product, we might experience a slowdown, decreased velocity, as well as increased waste. The teams get tangled in dependencies, complicated integration testing, and other bottlenecks. As a result, stories are carried over, releases delayed, teams feel powerless in their constant waiting.

The process of managing dependencies is called "scaling", and many companies adopt scaling techniques and methodologies hoping to get dependencies under control.

But... You knew there would be a "but", didn't you? The truth is, Agile scaling does not remove dependencies, it only "manages" them. Which means a framework like SAFE can identify and track dependencies, perhaps even reduce some of the uncertainty around them, but it wouldn't be able to eliminate them altogether.

That's why the true agility starts with unscaling. First, eliminate dependencies across teams, functional areas and individuals. Address them one by one and maybe you won't need to scale at all.

Here's a few primary reasons your team is tangled in the dependency web.

Our team only develops front-end, there's a different team who owns the back-end. We always wait on each other.

To be successful and truly agile, the teams should be aligned with the business feature sets (vertical split) instead of functional areas like UI, database, testing or test automation (horizontal). Having fully cross-functional teams reduces integration points and as a result, amount of dependencies the teams have to deal with. Each team should have the skills, knowledge and access necessary to execute every single task required to complete the sprint.

Needless to say, the user stories should be defined as user oriented end-to-end requirements, and not technical tasks like "add a table to the DB".

Steve wrote this module years ago, only he knows how it works.

Almost every group has its Steve. In many cases Steve is the person who's been with the company the longest, often he's also the engineer who had designed and written the original system. Steve the Specialist is the only person who has the skill set required to handle certain modules. Other people might be not interested or intimidated to learn, and Steve might be not willing to leave his comfort zone. Some people call the risk of having such a key player on the team the "bus factor" or "lottery factor".

The solution is two fold. First, the team members should be cross-trained to support the module in question. Second, the Specialist should be coached to trust others and stop treating the module as their precious baby that nobody is allowed to touch.

We are waiting for all teams to finish development to test all of our components together end to end.

This is probably the biggest dependency-related issue. Each team needs to integrate with other teams and they can't complete their sprint work until the integration testing is completed.

You can track dependencies and carefully queue each item to sprints in certain order through painful and laborious process, or you can refactor software into service-oriented architecture and build and test each component separately. SOA produces externalized APIs that serve as a contract between components and teams. During the sprint the team develops an emulator that sends or receives messages based on the published interface, exactly as the actual system would do. This approach allows teams to isolate functional pieces into components that can be thoroughly tested independently of other modules.

The code changes are very complex. Grace will have to do the code review, but right now she is busy.

First of all, the team should own its own development standards and practice peer code reviews as much as possible. But even if push comes to shove and the team needs help of a more senior engineer or an architect to confirm their design, they shouldn't wait until the end of the sprint. Involve architecture teams in the design of the user stories. Present your ideas on design and test strategies, get feedback and make sure you cover all the bases up front.

We have to wait for the support team to finish the User Acceptance Test before we can close the user story.

As with the architects, involve stakeholders and customers in the test planning up front. The testing should be done by the team itself based on their knowledge of the system, users and their workflows. This way the team can establish their own "Definition of Done" in which they don't depend on external resources to close the stories. If the team needs to bring an SME, do it in the beginning of the sprint to collaborate on a better test strategy. Another idea might be to invite the stakeholders to the team's Demo session to make them familiar with the new features.

Review and adapt, identify dependencies and eliminate them, one by one!

Please like and share with your network! Comment, share your thoughts and send me your questions, follow me on LinkedIn and Twitter to read my articles on practical Agile.