You're navigating multiple agile teams on interconnected systems. How do you ensure seamless dependencies?

For cross-team efforts related to integrating two or more systems, it's important to identify the boundaries and specify the interfaces of communication right in the beginning. What I've learned is that what seems to be common sense for a team, might not hold true for another team, so finding a common ground that works for both usually means going simple and not to overengineer the solution right off the bat. I've seen projects fail to meet budget and timeline constraints because they were pursuing the "best possible solution", whereas a solution that was "just good enough" would have made the cross-team effort be successful.

Fortunately our business and IT teams were experienced in scaled agile processes and ceremonies like Program Increment planning ensured that different scrum teams were engaged early and dependencies known.

Setup a cross-sync team meeting with the purpose of talking through and recording solutions to interdependencies of identified processes and deliverables for the project. Send out the meeting notes and log in the project plan what needs to happen with durations and owners.

Be intentional. Dependencies are something that can trip up a project if not identified up front. Discussing the deliverables starts the dialogue to discover where one team needs another team to do a certain piece of work before they can start on their piece. Identifying where the intersections are builds a dependency map for the project, the key just like any agile project, the dependency map must be updated regularly to handle new information, changes, and impediments. I worked on a project where the exercise was ran once at the beginning of the quarter, it was a success and produced a map of where the dependencies would occur, but the project had huge bumps along the way because we never revisited it, don’t make the same mistakes.

Try to remove dependencies as good as possible. In case you detect teams have dependencies on the long run try to re-structure your team organization to keep dependencies within a delivery team. Best would be to create feature teams that can deliver without relying on each other, rather than having component teams.

This is a great solution that mostly benefits management. Your teams are focused their work, and while its good for them to be able to see the 30,000 ft view, they aren't going to reference that very often. However, you as the manager will find this view very useful, especially when juggling several dependencies. This will serve as a great tool to identify blockers and know where and when to prod your teams on their progress.

In one of my previous experiences, we followed SAFe as an enterprise methodology when large number of teams are involved to coordinate cross-functional teams dependencies for the bulk of Projects and releases. This process brings in sync all the teams and not just identify the multiple teams involved to rigoursly plan, identify and commit to the dependencies and allow a clear roadmap for each minor and major releases. Transperancy and visibility makes the teams work coherently towards the goals marching towards the Programs incremental progress

Continuous integration is essential for faster, more efficient deliveries and improved code quality. By structuring the development process into multiple levels, we can enhance code validation at every stage. Consider 3 levels: L1 – Integrated directly with the development environment, leveraging tools like JUnit, SonarLint, and JCov within the IDE. L2 – At the PR stage, execute tools like JCov and SonarQube before merging, enforcing quality gates to ensure only code that meets criteria is integrated. L3 – During nightly builds, run automated integration tests on the target platform to validate build integrity and mitigate potential quality issues or blockers.

This is hugely impactful to cross-team coordination, especially around the efficiency of cross-team work. Teams that hold on to their work until it is "complete" not only create dependency blockers, they also increase integration risk once their share is complete. When doing cross-team work each team has to view the other as their customer/client. This will shift the mentality of the team toward creating iterative value-add "releases" for their client (the other teams) instead of focusing only on the finished product.

Talking about CI it is crucial to also continuously improve your pipeline the more matured and scaled your system becomes. I often experienced that companies save cost at infrastructure and CI/CD pipelines. However, the more your system evolves the more you also have the need to adjust your infrastructure to integrate software.

To ensure seamless dependencies across interconnected agile teams: Risk Identification and Mitigation: Proactively identifying potential risks related to dependencies and creating mitigation plans helps in avoiding delays and issues. Regular risk assessment meetings ensure that new risks are identified and addressed promptly. Contingency Planning: Developing contingency plans for critical dependencies ensures that teams are prepared to handle unexpected issues without significant disruption to the project timeline.

In my experience with the scaled agile framework, we begin by identifying risks during the pre-game phase, creating a risk registry that categorizes them from high to low. These risks are then discussed during the PI planning meeting with all teams, where we develop a detailed mitigation plan. If a POC is required to evaluate specific risks, it is prioritized in the first game sprint to ensure stakeholders are fully aware of the risks and their impact. Any necessary adjustments to the plan are made early to prevent PI failures.

In my experience working with scaled agile teams, we maintain a team size of no more than seven members. Each team has its own Scrum Master and internal Product Owner. The Scrum Master collaborates with other Scrum Masters to align on dependencies and manage risks, while the internal Product Owner interfaces with the team, Product Owners from other teams, and the Chief Product Owner to ensure alignment of sprint and program increment content, enabling real-time decision-making.