Something is amiss in our cross team communications.

Our teams use an invitation vs. imposition approach to process.  Meaning teams can decide what process works well for them within the guardrails of the Agile Principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.

We recently had a high priority cross team initiative bubble its way to the top of the backlog for three different teams.  We decided to experiment with a Project Inception where we invited representatives from the three teams to a 1 hour meeting to hear from the PO why this is an important initiative for the business to deliver by X date, the architect reviewed the overall design and the teams asked questions and discussed which teams were doing which pieces.  The teams were asked "should we have a Scrum of Scrums for these three teams"  They answered no, lets communicate by email.

So what happened?   As the first important milestone (checkpoint meeting to validate the approach will work in the time frames needed) approached, it was not clear what the inputs would be and how the decision would be made.  So an email thread was started and ended with a functional manager taking all the inputs and creating a spreadsheet of milestones and target dates.

Teams did not pay a lot of attention to the milestone dates or to the content of the milestones.  Totally makes sense for engineers to focus on the work captured in JIRA and in the current sprint.  Teams started to express concerns for what the other teams are committed to.   Why wouldn't they as there was no insight into how other teams were progressing.

With the best of intentions the servant leaders in the organization were actually enabling the teams to NOT communicate the appropriate level of detail around the work at hand.  Teams focused on the work in their backlogs and sprints and left the cross team dependencies to be tracked and worried about by architects, managers, and scrum masters.

This is not a great model to scale, and it causes inefficient and extra communication.  A scrum of scrums allows for a light weight way to have the right conversations with the right people and removes the layer of  abstraction added when we start talking milestones that comprise multiple JIRA stories.  The devil is in the details here, and the people doing the work are best suited to discuss these details.

We will start a scrum of scrums next week.