Scrumban

I got my Certified ScrumMaster (CSM) certificate back in 2004.  To say that the class was influential was an understatement - on the industry level, it provided a common language and set of rhythms for enabling the principles of the Agile Manifesto. For me, it was a way to bridge the fun, integrated team feel of a startup and the needs of a larger company.  It also provided a way to structure the communication between a client and a development team based on collaboration. Unfortunately, Scrum has a few weaknesses in an enterprise environment.  The main ones we've seen over the years include:

  • The "In Progress" status vastly oversimplifies things
  • Larger organizations tend to hire specialists, not generalists
  • Inexperienced and/or control-oriented project managers abuse the model, turning standups into status reports
  • The combination of external team dependencies, burn down charts and sprint commitments turns deadly quickly; the commitments aren't met due to external impediments, destroying morale
  • The focus on meeting commitments makes planning much more critical; we have seen several companies that adopted Scrum spending two entire days doing planning.

For the last few years now, we've been experimenting with Scrum combined with Kanban, aka Scrumban as a way to solve these problems; by and large it's been very helpful.  Some of the key improvements include:

  • Cycle time reports put management focus on process improvement.
  • Columns allow for much better tracking of external dependencies - for example, you can track the amount of time lost to a recalcitrant operations team.
  • Specialists and part-time work can be managed much easier
  • We keep the two week rhythms, but the planning and estimation is baked into the boards - no more multi-day planning meetings.

If you are interested in more information about Scrumban, I highly recommend this (free) eBook by Henrik Kniberg & Mattias Skarin.