5 Minute DevOps: Scrum or Kanban?

https://www.flickr.com/photos/abragad/4104919275

Should we use Scrum? Kanban? Is Kanban for support and Scrum for development? Is Scrum for newbs and Kanban for elites? Are we mature enough for Kanban?

These questions are a symptom of the Agile Industrial Complex selling certifications and people following the rules to get certified. Scrum or Kanban? The reality is that Scrum is not training wheels and Kanban is not for elites. Scrum is not for product development and Kanban is not for support work. Both are standardized approaches that emphasize small batches of work, feedback loops, limiting WIP, and frequent delivery. Both are done wrong by most teams because they focus on the process instead of the outcomes.

Ultimately it’s irrelevant. Teams who are good at delivery never ask about Scrum or Kanban. Instead, they simply deliver small batches of high-quality work very frequently. This isn't rocket surgery and they didn’t get there by standardizing on 2-week sprints and reporting their velocity. They got there by focusing on the goals.

What are the goals? We need to have a systematic approach to improving the flow of delivery.

  • Automate our delivery process to remove variance.
  • Stabilize our quality signal and drive detection as far left as possible. This not only includes getting rapid test results but also includes getting feedback from the user to discover if we are delivering the right value.
  • Limit work in progress and finish things before beginning new work.
  • Drive down the size of stories to 1–2 days to improve quality and enable us to pivot rapidly to exploit new ideas that prove valuable.
  • Small changes need to be flowing into version control, built, tested, and delivered VERY frequently (hours, not days) and without humans touching anything.
  • Moderate new work intake to keep lead times low so that ideas do not become worthless while they wait on the backlog.
  • Find ways to increase efficiency to improve throughput.
  • Strive for transparency and trust in everything. Without good communication, we all fail.
  • Measure and improve the things that help our customers.

We need to move fast and fail small and we need to do all of this at a sustainable pace that prevents burnout.

When we focus on Scrum or Kanban, we are focusing on the purity of the process. Our customers don’t care about the purity of our process. Our customers want features to be delivered rapidly and they need those features to be stable, available, secure, and useful. We need to focus on the things that make that happen. Nothing else matters.

Developer, Value Stream Architect, and DevOps insurgent who optimizes for sleep. All opinions are my own. https://www.linkedin.com/in/bryan-finster/