“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:
- The Scrum Master who
lead the co-ordination of the previous release was promoted into the management
team.
- 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.
