Saturday, February 2, 2013

ScrumBan?

You are a team lead, responsible for ensuring that you and your team deliver on what you've signed up for. Usually something where you want to "make a dent in the universe".

So how to ensure that you're team is making good progress with their work?
How do you track this progress with greater granularity?
How do you make sure that the team is working together in a tighter fashion, raising blocking issues in a timely fashion so that action can be taken etc?

Enter ScrumBan. Progeny of Scrum and Kanban.
Or atleast that's the claim.

If one were to search information on Scrumban, as both in Scrum and Kanban, there are as many definitions as there are search results. Clearly, ultimately, the definition is in the "eye of the beholder".

That said, here are some of my initial learnings as I begin to educate myself on this methodology.

  • You can go overboard with all of this and create a beautiful bureaucratic system that rivals anything the dreaded (to the Agile folks) Waterfallers ever created
  • Keep the process simple, lighweight, and most importantly meaningful to the team
  • Keep teams small. Small teams can execute faster, turn on a dime when needed (ie Agile?)
  • Ultimately its about FLOW (capitalized for effect, not an acronym). ie Get work going through the pipeline with the highest velocity possible (maximize for throughput?)
  • It's different for every team and project on the planet. To say that this particular process worked on a previous project/team, and therefore should work on the current, is an invitation to the team spinning its wheels for a long time until they figure out the bogus'ness of this idea
  • EXPERIMENT, EXPERIMENT, EXPERIMENT
  • That is, start with the basic principles built on Scrum and Kanban (which are?, for an article at a later time), and figure out what's working and what's not for the team, over time.
Things to look into for a future blog:
  • Kanban uses the principle of limiting WIP (Work In Progress) at each stage of the workflow. WIP is usually at some level well below maximum capacity of the team.
  • What specifically are best practices of Scrum that makes sense to combine with Kanban? Because as always, you can go overboard with each, causing the team to crash into endless meaningless process debates, vs getting real work done.
Some interesting reference material: