Kanban: The Next Level for Scrum Teams

As we have been discussing the journey of various Agile teams, an interesting question came up – what does “progression” look like? Yes, teams go through the standard forming, storming, norming and performing phases...but once they are a performing Scrum team, what’s next? What is progression beyond that? From a business point of view, isn’t Agility delivering frequently – is two weeks not too long to wait? Are we not putting constraints that limit Agility? Don’t get me wrong, I am a proponent of Scrum – I like its prescriptions and discipline, but when those prescriptions and discipline become limiting, it’s time to move on – towards more Agility.

I recently came across a comment made by Jeff Sutherland during his visit and training at TESLA: “There is far too much ‘California Agile’ in Silicon Valley, where developers do whatever they want and so you get ‘whenever’ delivery.”

--I see this in teams that want to do KANBAN primarily because they think it’s less effort than Scrum.

Less effort than Scrum...hmm, really? Scrum and Kanban cannot be compared in terms of effort; in fact, the question is really not about the effort – it’s about Agility.

I see Kanban as a path of progression for Scrum teams TOWARDS greater Agility. The effort that Jeff points towards is really the prescriptive nature and discipline Scrum offers as teams work on new product development, especially when moving away from waterfall methods.

Kanban does not offer similar prescriptions; however, it does not eliminate the need for any of the Scrum events, artifacts or roles either. Kanban teams collaborate around their boards, prioritize their work items/user stories, and deliver valuable software ALL the TIME – not at prescribed intervals as in Scrum. There is no prescribed cadence because it is about empowering the self-managed teams to decide when they want to swarm, how they can quickly move a feature through the delivery process, how they can help the Product Owner (yes, they DO collaborate with whoever is the ‘voice of the customer’ even if it’s not a prescribed role), visibly show what is blocking them, and work towards adjusting their WIPs periodically to ensure work is always flowing freely! While there is no Scrum Master role, the team takes on that role or someone acts as ‘Lead Agilist’ to ensure that the power of Agility is being utilized. The key is, it must be done right. To avoid the “whenever, whatever” syndrome, the team should truly review the flow of work, quality, impose and change WIP limits as needed and work towards “done, done”.

Kanban is the lean form of Scrum! When teams understand the discipline of Scrum and learn to execute on it, they reach a point where that becomes a limiting factor, a constraint they want to get rid of and believe they can move faster – that is true Agility! And that’s exactly where Kanban fits in!