The Scrum/Kanban Killer Kombo

Most projects require input from your infrastructure team, and this one team can be responsible for supporting possibly several on-going projects. How can Scrum Masters and Product Owners (PO’s) make sure this team are doing what is actually the most important thing as opposed to being reactive to whichever project shouts the loudest (especially if your organisation still hasn’t conceded to the fact that Project Managers do not have a role in Scrum)? On the flip side, how do they stay flexible enough to expedite emergency items?

A great combo that I have seen work really well is when the Infra team run off Kanban, and your project teams run off Scrum. When the Project Teams are in Sprint Planning, you should bring in a representative from Infrastructure so that a) they are familiar with the Infra requirement b) they can be notified of a ‘due by’ date that they can integrate into their Kanban backlog ‘stack rank’ and c) because the project’s scrum teams are sprinting, your Infra guys know when the release date, or dates will be, which may be their ultimate ‘due date’. It is really important that Scrum teams are honest with Infra about due dates because it will dictate to a large extent the stack rank of the Infra team’s Product Backlog. Other things that will play a part in the stack rank are technical dependencies, or expertise availability (someone may be on holiday). Other pre-requisites for the Scrum teams is that they are realistic with any due dates that they expect of the Infra team, and don’t put the team under unnecessary pressure to deliver a Product Backlog Item (PBI) in the first week of their sprint when in actual fact it is not really needed until the second (or third, or fourth!). They also need to make stories/requirements clear so that your Infra guys can come up with the best solutions. The Scrum teams should also keep the Infra guys well aware of any change in requirements so that they are not continuing to commit to delivering unnecessary and therefore wasteful items. To help prevent this, the Scrum Masters should attend the Infra stand ups as a chicken and keep an eye on their backlog items. They should listen to the conversations going on in the stand-up (yes, as technical as they may be, stay with it Scrum Masters!) and any concerns should be raised early.

The Kanban limited Work In Progress (WIP) work streams lends itself really well to infrastructure teams, because a lot of the tasks they do will be the same or similar variations of work they have done before. To get full buy in from the whole team, ask THEM what they think the work streams and their limits for each should be (as well as the Definition of Done for each). They can always change it later if it doesn’t work. You are still required to inspect and adapt with Kanban! In the past I have seen a flow similar to the below work really well:

Infrastructure Kanban WIP Work streams

  1. Backlog (always stack-ranked). Contains user stories with defined requirements and acceptance criteria
  2. Analysis. The design and approach is established by whoever picks up the story
  3. Analysis Review: The design and approach is peer reviewed
  4. Development. The code is implemented
  5. Test. Tests are run, bugs raised etc.
  6. Ready for release: If the code is to be released at the end of a Scrum team’s sprint
  7. Done. The Definitions of Done are met and the PBI goes on the ‘Wall of Done for all to admire.

Make sure you have regular retrospectives with the Kanban-ers because like XP, it is fast paced and therefore is very important to address issues and make any changes to avoid conflict, promote best practice and most importantly, prevent burnout.