Transforming the Scrum of Scrums and Delegating Release Co-ordination

“The agile manager’s scariest move; handing over responsibility”

Once we* had our Delivery Teams regularly delivering increments of valuable working software; the management team made the tough call of pushing the responsibility for co-ordination of releases to the Delivery Teams. This blog post follows this decision through its successes and failures and explains how we adapted to the feedback we received and issues that we identified.

*The Royal we: Management Team, Transformation Team, and Coaching Staff.

Attempt 1 – Complete freedom

A meeting was arranged by the management team to announced to the Scrum Masters (and a few other stakeholders) that as part of the ongoing transition the Scrum Masters must step up and take ownership and responsible for co-ordinating our quarterly releases. After this meeting the management team deliberately sat back and let the Scrum Masters sort it out themselves.

The Scrum Masters held a brief meeting to decide how they would handle the situation. They quickly selected two Scrum Masters to lead the co-ordination effort. One of them took the lead and did a great job of co-ordinating the release, which went out on time and to the quality we had aimed for. There was plenty of room for improvement but no major disasters.  

While the Scrum Masters were comfortable with this change, the management team quickly lost visibility of any issues that were occurring and at the same time were getting feedback from many staff members about a lack of communication between the Delivery Teams.

Another couple of issues popped up, which told us another approach was needed for the next release: 

1. The Scrum Master who lead the co-ordination of the previous release was promoted into the management team. 
2. The other Scrum Master who had been involved was currently swamped with practice improvement work. We were not sure who would step up to the take the reins.

Attempt 2 – PMO established Scrum of Scrums

With issues around lack of visibility, low communication between teams and concerns about how repeatable our previous success was, the management team decided that they needed to act.

At this point in time the culture had moved from ‘responsibilities being assigned to individuals’ towards ‘responsibilities being assigned to teams’. Looking at our current issues the decision was made by the management team to rotate the responsibility for Release Co-ordination between Delivery Teams each release, along with establishing a Scrum of Scrums as a status reporting, cross team communication and impediment removal approach.

To get things moving quickly our PMO manager booked a weekly meeting with the Scrum Masters, during which they were asked what the status was of each release that was in progress (we have 1 or 2 maintenance releases and 1 feature release in progress at any one time). The Scrum Masters saw it as the PMO meeting and were fearful of raising issues at the meeting, as those issues would then be forwarded onto the management team. The Scrum Masters thought that any issues that were raised made them look bad, meanwhile the management team was hanging out to know the real status of the releases, so that they could help wherever was needed. This fear or lack of a ‘Safe to Fail’ environment was addresses separately (and is perhaps the topic of another blog).

With the PMO established Scrum of Scrum operating, the management team continued to receive feedback that there was not enough team to team communication, however we did start to get some issues raises and did get some feeling for how well the releases were going (and they were going well). We were still concerned that the level of ownership of Release Co-ordination was not as high as we needed it to be.

Attempt 3 – Scrum Master established Scrum of Scrums

With Attempt 2 still not providing the results we wanted, we decided to intervene by re-invigorating the ‘SOS’ (this unfortunately meeting name was one of the first things to go).

To kick off the change our two Engineering Managers (who have responsibilities around People and Practices) each talked one-on-one with the Scrum Masters that reported to them. 

They asked about the Scrum Masters view of the SOS meetings and set out some clear expectations around team to team communication, Scrum Master to team communication, the raising of issues, ownership of release co-ordination and running the Scrum of Scrums. Lastly they were told that a meeting would soon be organised with all of the Scrum Masters where they would have to work out how they would re-invigorate the Scrum of Scrums.

I facilitated the meeting with the Scrum Masters and the Engineering Managers in attendance. We started with one of the Engineering managers setting down the expectations regarding the Scrum of Scrums:

• Raise team specific risks, so that the other teams are aware and can assist.
• Explain what each team is doing, so that the other teams are aware and can assist.
• As a group uncover big risks and either deal with them or escalate them.
• As a group review and understand commitments especially those with specific dates.

Once those expectations were clear we got down to the business of the Scrum Masters deciding what information they needed to be able to meet those expectations, how the meeting would be organised, when it would occur and who should attend.

In summary they decided upon:

• All Scrum Masters and the PMO manager would meet weekly on a Monday after all of the Stand Ups were completed. No other people had to attend, however back up Scrum Masters and the Lead Architect was optionally invited.
• Using a large highly visible planning board, showing all teams, all key user stories, dates, etc.
• A simple agenda: Each Scrum Master presents in the order shown on the board, and then any issues/news is discussed as a group.
• Each Scrum Master was responsible for keeping their team’s row up to date.
• One volunteer would create the first Scrum of Scrums board.

Continuation / Tuning

The first meeting went reasonable smoothly, a due date was clarified, a risk was discovered and they discovered two teams that needed to co-ordination on a user story. A few tweaks to the board where suggesting, including using a consistent colour coding scheme.

The next few meetings were tentative affairs as each Scrum Master was ‘feeling out’ how they should behave in this new situation.

The fifth meeting seemed like they were starting to get off track and just running through the motions of an ineffective status update meeting.

The sixth meeting had some minor cross team concerns discussed. A couple of teams had let their information get out of date, with only one user stories up for the current sprint. The major issue was that we were fast approaching a critical release date, and there was no communication around the status of features that had been committed in the release. It seems like the Scrum Masters were not considering the whole release as much as was hoped by the management team. This prompted a lot of one-on-one discussions and feedback sessions, which thankfully all hit the mark.

Seventh meeting: Great, they are really getting it, taking ownership, asking questions, self-organising. The teams that last week only had one card had added all of their planned user stories and provided more detail in their summaries; this triggered conversations and overall seemed successful.

The Eighth meeting was held part way through the first sprint of our new Release cycle. The board had the next 4 to 5 sprints filled in for most teams (only at a high level for sprints 2 to 5). As a group they spotted three key issues and quickly resolved them. It looks like the Scrum of Scrums is working and is here to stay.