Scaled agile and frameworks for managing Scrum across multiple teams have been trending for the past couple of years. Some of them with more adminitrative overhead than others. At Bankdata I am involved in an experiment seeking to handle dependencies between teams working together on a larger initiative.

Setting the scene

We have several existing Scrum teams that need to coordinate work towards a shared vision over a longer period. As an agile organisation we want to keep teams:

1. as stable as possible
2. as high performing as possible
3. as independant backlogs as possible

In addition we have a need for introducing as few new events and structures as possible.

In my Scrum Day 2017 presentation I introduced our early experiments in handling cross-team work through instances of Nexus Integration Team structure. Since then, we have worked more intensely on a framework for larger initiatives with cross-team character based on the Nexus framework.

Don’t scale – descale

With a large initiative going through my part of the organisation, I have worked closely with my peers on descaling the initiative. In this case, descaling is the task of separating the work conducted by each individual team in such a manner that they are able to work as independant Scrum teams with their own backlogs. While this is the optimal case, it has proven impossible in some cases due to either business complexity or system architecture. With a minimum of over head and administration, we have configured an instance of the Nexus Integration Team, called Program Integration Team (PIT), with the purpose of facilitating:

• communication between teams and stakeholders
• identification and handling of dependencies between teams
• initiative wide stakeholder management
• impediment and risk management
• initiative wide forecasting

Program Integration Team (PIT)

PIT currently consists of the following resident competencies:

• Program Manager: reporting, risk management and dependency management
• Chief Product Owner: overview and insight in business needs cross backlogs
• Chief IT Architect: maintainability, decoupling of functionality, sparring with teams
• Chief Business Architect: business responsibility and overview of UX and customer journey cross backlogs

In addition each Scrum team has defined the following competencies:

• Team Business Architect: business responsibility and overview of UX and customer journey in own backlog
• Team IT Architect: system responsibility and alignment with overall IT architecture in own backlog

Feedback loops

Remembering that each Scrum team in the initiative maintains its traditional feedback loops presented by Scrum, we have added the following experimental meeting structure to ensure feedback on both initiative wide dependencies, business complexity and system architecture:

• Daily Standup meetings internally in PIT
• Weekly meetings with Team and Chief Business Architects
• Weekly meetings with Team and Chief IT architects
• Bi-weekly meetings with Program Manager, Agile Coach and Scrum Masters
• Bi-weekly meetings with Chief Product Owner, Program Manager and Product Owners
• Monthly meetings with Chief Business Architect, Chief IT Architect, Team Business Architect, Team IT Architect, Agile Coach, Program Manager, Chief Product Owner, Product Owners and Scrum Masters
• Quaterly big room planning meetings with Scrum Teams, PIT and relevant stakeholders

That sounds heavy

It sure does. We experiment in finding new ways of working without tampering too much with the agile values and the Scrum framework. We are well aware that we are adding a small portion of lard on top of our teams, but we have good intentions. We believe that, especially, the facilitation of dependencies between teams will pay off in the longer run.