How Great Scrum Product Teams Use Kanban
If you're Scrum on a product team, and you don’t need Kanban, you’re probably not being Scrum. The alternative is you have another team managing your live issues. In which case, the team’s missing a great learning opportunity.
In the last few weeks, I’ve talked to quite a few startup Product teams attempting but struggling to use Scrum. So I wanted to take time out and describe some practical solutions to challenges these teams frequently bump up against as they start out.
First Are You Really Being Scrum
An enormous amount of product teams have taken on Scrum as their agile delivery framework. They love the idea of the frequent cadence of shipping value. They crave the benefits of the two continuous improvement feedback loops contained in Scrum; the first for the product (Sprint Review), the second for the process (Sprint Retrospective). However, Scrum has some attributes that can bite hard if you don’t know how to handle them. Being Scrum means you should have potentially shippable (to live) code at the end of every Sprint. If you do ship to live during or at of the Sprint there are consequences.
Once the software is live, you’ll get feedback, and some of which will be that your software doesn’t work, and you need to fix it now. Now, because people have begun to rely on it and to keep their trust, you need to fix things fast.
You Can’t Handle the Truth
Now that’s fine on a 12 month release cycle. You can put the team on fixing the live issues without immediately feeling the impact on the next release. With Scrum, you’ve got potentially shippable software at the end of every four weeks or less. That means the team that are trying to forecast and commit to a specific number of user stories they’ll complete in the next Sprint will struggle as Sprints are interrupted with live fix issues.
You've then lost the predictability that Scrum gives you. Here's a visual of what happens to your predictability if you get this wrong.
Separate the Turbulence
A way to handle the live incident turbulence that leads to unpredictability is to split the team in two. Talk to the team about having a group of people that handle the predictable work of burning down the Sprint backlog and a group, a shield team; that manage the unpredictable work coming in from user feedback out of the last Sprints. I’d recommend that the people rotate through the shield team each Sprint, that way every team member gets to own the live incidents and gets to know more of the product code base.
Flowing The Unpredictable Work
Work that is by its nature less predictable because it’s driven by external events (an example being the number of incidents hitting the shield team) doesn’t benefit from trying to use the cadence of Scrum to enforce predictability - it's out of the team's current control. This type of work benefits from using a flow-based approach encouraged by Kanban. Kanban doesn’t enforce a cadence or set of events. It focuses the shield team on principles:-
1. Visualise the work
2. Limit Work in Progress
3. Focus on Flow
2. Continuously improve
It’s less about predictability and more about pace and quality. Exactly what you want when shipping fixes to live fast.
For the feedback coming from the live release the shield team create a separate shield backlog. They’ll triage this backlog in real time and fix any issues that are taking down the service first. With the rest of the shield backlog the Product Owner will decide the issues that are significant enough to fix immediately, and the shield group will build and ship those items. The remaining non-critical feedback issues will be loaded and ordered into the regular Product Backlog and worked on in the normal Scrum cadence.
Try It, You Might Like It
If you’re running teams using Scrum and are starting to ship to live using that team take a look at how you’re managing the feedback. The Scrum Retrospective is an excellent time to look at how you’re managing the unpredictable work coming in from live and maybe try the shield group approach and see if it helps.
Keeping the same team building and fixing the product and splitting the team into a rotating set of two groups, one shielding the other from the highly variable work has proved very efficient for great teams I've learned from and been honoured to work with. We've reduced the lead times to user of both fixes and improved functionality. We’ve also improved predictability. The team has also felt continuously close to both the challenges of the customer and code base.
*Article image from Leap Australia CFD Blog