Scrum or Kanban

I was asked this the other day by a scrum master at my current organization.  For disclosure, I’ve been involved with Agile delivery for about 8 years or so.  I started out with Scrum and have been involved with Scrum, XP and Kanban ever since.  I’ve been a developer, a delivery leader, a coach and a trainer over this period of time so hopefully you’ll see my opinion as being informed.

My response to this individual’s question was that I can take a newly formed team and get them to predictability in Scrum regardless of talent and skills, but just a general desire to learn the framework.  Scrum is very good at providing a framework for delivery.  It’s got artifacts, ceremonies and there has been so much literature written about the topic that there is no shortage of finding guidance.  Notice I didn’t mention anything about self organizing or empowered teams.  To me, this is a basic ingredient no matter what direction you choose.  If you desire for a more command and control type structure, perhaps you are better off not reading any further.

So what about Kanban … I have two things I like to consider when moving to Kanban.

  1. Do I have a  high performing team that is mature and looking for ways to get even better
  2. Do I have a new team that is made up of strong folks who are responsible enough to wield the power of a lean delivery model

If I don’t have either of those, I tend to shy away from Kanban.  Reason is, I’ve seen too many teams take advantage of the things about Kanban that make it so powerful.  Such as, with no time box, people work endlessly.  Again without a time box, the size of a work item tends to grow.  With no defined sprint planning, team members don’t work together to plan work.  With no defined retro, they often don’t improve on demand.  With no prescribed demo cadence, an on demand demo just doesn’t seem to occur.  So unless you have the right folks or a strong leader, these things just don’t occur.

I get it, you could argue that all of the missing components in Kanban could be added in, but to be honest, I don’t like that form of prescriptive nature.  I believe when Kanban is working, demos spawn at any point, retros occur when someone feels the need to improve.  I do still like cadence based planning but other than that, I’m not really in love with the idea of ScrumBan.

So to wrap this up, my opinion is people are what’s important, not necessarily the process. I’ve got plenty of experiences that show this at small scale as well as at large scale while implementing the Scaled Agile Framework.  It doesn’t truly matter at the end of the day what method you use, but that you choose the one that best fits your people and tailor it according to your environment.  Know what success looks like and measure your progress towards that and I think you will be just fine.


About the author

Ben Pyle is a software developer who enjoys solving problems and delighting customers with right quality software. He's a husband, father to 2 boys and avid golfer. In his free time he enjoys reading, playing lots of golf and hanging out with his family doing whatever they are into.

Leave a Reply

Your email address will not be published. Required fields are marked *