This is a real-life story. It’s a story about addressing the concerns of senior managers who are wary of their delivery teams making their own independent decisions. It’s a common tale that many delivery teams face, and one where, as servant-leaders, scrum master and agile coaches need to support their teams in navigating.
This story is set in late 2015 amongst four delivery teams in one of the UK’s most established broadsheet newspapers organisations. To meet the end-of-year deadline, the teams had been working their socks-off to build a new publishing platform and migrate to a new front-end service for the newspaper’s readers.
Since much of the platform had been released and was being used for the first time, the teams were rapidly moving from build-and-deliver release cycles to a more responsive support operation.
Previously, when the teams were building and releasing, their iterations were synchronised into two-weekly sprints. However, when an increasing number of journalists were using the platform in unexpected ways, teams needed to respond to urgent support requests more frequently than the two-week sprint cycle would allow.
This meant the two week sprint planning sessions became a bit of a farce because the backlog the teams were selecting from didn’t reflect the uncertainty of supporting a new platform. Multiples times a day the teams were breaking the sprint backlog forecast to deal with rapidly emerging issues.
Being the people actually doing the work, as oppose to the more distant leadership team, most of the teams recognised they should probably switch their work practices from Scrum to Kanban. They wanted to see if the Kanban approach would cater for different urgencies and uncertainties of work.
Note: this isn’t a story about the Kanban process, or the pros and cons compared to Scrum; that is covered well enough elsewhere. It’s story about how the relationship between delivery teams and the leadership team, the autonomy the latter should allow the former, and what a servant-leader needs to do to protect the team.
Now back to the story….
During one of the teams’ retrospectives, one team decided now was the time to switch. This was not prompted by the team’s scrum master, and was not discussed with the leadership team. It was an independent team decision.
As well as discussing the way the team would make the switch, the team had to handle the fact that Kanban did not conform to the leadership team’s expectations. The CTO and his Head of Delivery were concerned it would negatively impact delivery and on how the team reported.
With the support of the scrum master, the team did several things to relieve the concerns of the leadership team:
- Since the scrum master spent more time with the Head of Delivery the scrum master was able to help the delivery team recognise and empathise with the concerns of the leadership team.
- One such concern was a fear that the team would not report and deliver on a fortnightly basis what they planned and worked on. Therefore, via the scrum master, the team had to explain that the nature of their work was changing to a more reactive sense-and-respond operation; less work would be predict-and-control.
- They explained that the scrum master would still complete the team’s weekly reports and track issues using the recognised red-amber-green status mechanism.
- The team informed the leadership team that it was only a trial, not an irreversible commitment.
- And since it was a trial, the scrum master discussed with the leadership team the fact that they needed to give the delivery team the time to learn from mistakes.
- Finally, since the leadership team had endorsed agile ways of working, the scrum master helped them understand that the switch to Kanban was in keeping with two of the Agile Manifesto values:
- Individuals and interactions over processes and tools
- Responding to change over following a plan
So those were the discussions the team had with the leadership team. What actions did they actually take?
Acknowledging where the leadership team was coming from, recognising the need to change the processes incrementally, and knowing that quality must be maintained, the team decided on these actions:
- The team still chose to use story points and their velocity to forecast what could be delivered every fortnight. Since a lot of the work was unpredictable, only a portion of the velocity was available for this forecasted work.
- The team still had a fixed cadence for some ceremonies such as release management, retrospectives and reporting.
- Ad hoc individual story planning and story reviews were introduced. Thus creating a more responsive flow of work.
- The team ran workshops to discuss and agree on the first set of Kanban columns and WIP limits. Therefore they began to anticipate where the flow of work should be constrained.
- Since it was too early to figure out what they’d be, exit criteria would be introduced later.
How does the story end?
Here’s what happened after a couple of iterations
- The team wasn’t loading work into the sprint backlog which they knew they couldn’t deliver. This gave the business a more realistic picture of the team’s capacity and encouraged the business to recognise the switch to a support operation. Although they found it hard, the business understood less new features could be delivered.
- Since the team was continuing to story point work, and measure their velocity, artefacts such as the product burn-up chart was still a very useful discussion tool.
- The team was still able to report on their fortnightly delivery forecast. The leadership team understood the team’s changes did not affect the quality of work and it was not detrimental to the rate of delivery
So, this story has a happy ending.
The team successfully found a way to understand and address the concerns of senior managers. Those managers understood the value of giving team autonomy over their own processes. And, with scrum master guidance, the team independently found a way of working which was more appropriate to their new responsibilities to look after the platform’s users.
What’s your story? Do you have similar challenges in your teams and departments?