As organisations continue to adopt Agile practices, there’s an inevitable conversation about Scrum vs. Kanban waiting in the wings.
In many situations Scrum is introduced as it’s seen as the easiest way to ‘be agile’. Shortly after someone feels overburdened by sprint planning meetings and suggests the team move to Kanban. In Kanban Land the grass is far greener, the air much cleaner, developers canter through their work at their own pace, people spend less time in meetings and more time hanging out in Norther Quarter coffee shops, drinking flat whites. Or so they’ve heard from their friend who knows someone who works at <insert flavour of the month tech company here>.
Who could resist, right?
Many find their efforts shot down before they get far off the ground. The recently qualified Scrum Masters are particularly keen to hush up the Kanban lobbyists, after spending two whole days (minus lunch breaks, coffee breaks, ice breakers etc., so maybe a couple of hours in reality) ‘mastering’ the art of Scrum, the thought of this lost time is too much to take – they’re masters now and they’re not going to let anyone forget it!
Some plucky teams get further, they get their Kanban board up, they might even stick some WIP limits on there too, they release themselves from the heavy burden of a 2 hour sprint planning session each fortnight, giving them more time to think about that tech debt task they really don’t want to do, or pick a new Spotify playlist for the week.
Then someone reads a Kanban book and starts asking about lead times, cumulative flow charts, throughput or, even worse, asks the team to estimate their time to release (really annoying that one, bloody PMs) and the team start to think there might be more to this Kanban lark than they first realised.
The team are baffled, features go unfinished, Product Managers weep, Executives panic, Scrum Masters smirk contently in the corner.
/sarcasm off
Whilst this might be a little farfetched (or frighteningly close to reality?) the Scrum vs Kanban debate is real. I’ve been there several times and people will generally have their own preferences. The truth is that Kanban is very disciplined, flow is king and this needs to be understood by all.
There’s loads to consider if you’re thinking about adopting Kanban for lean software development. As a start, it might help if I draw your attention to just a few points, before you dive in…
SHARED END TO END ACCOUNTABILITY
The team need to be prepared to put aside role or job title boundaries to get work done. We help each other out, whenever required, in order to keep work flowing. Generally, in Scrum you’ll estimate and accept work based on capacity, in Kanban you’re flowing work continuously, so the blur of responsibilities tends to be greater across team members. We need to be comfortable with this and the impact it has on the team members.
KANBAN KNOWLEDGE AND USING THE RIGHT METRIC TO IMPROVE OUR PROCESS
This might sound obvious, but everyone on the team needs to understand the basics of Kanban. This includes understanding what the key metrics mean and being disciplined enough to maintain the agreed process and WIP limits. Kanban courses are good, there are also board games that can really help (e.g. https://getkanban.com/); if you don’t have at least one person in the organisation who understands Kanban well, then address this before you start.
Once you’re up and running you need to inspect and adapt using key metrics for the team. For example,Lead Time, Throughput and Cumulative Flow are not vanity metrics; make sure the team understand them and use them in retrospectives to take positive action.
LEADERSHIP
I’m a big fan of self-organising teams who are given clear goals to achieve, but leadership is still a thing – someone needs to coach the team on the process, someone needs to remove blockers that require escalation, someone needs to be consistent source of energy. A great leader serves the team, it’s their job to clear the path and help the team get better. This isn’t a Project Manager or a co-ordinator, or someone who put a Scrum Master certification on their email footer; it’s a leader who motivates and supports.
There are other considerations of course, but don’t fall into the trap of thinking Kanban is just like Scrum but with less meetings. It’s different.
In the opinion of this blog author, there’s no ‘right’ framework as such. A framework is just a tool, or collection of practices, that provide a team with a common starting point. From there, continuous improvement should see this change over time to best-match the needs of the team to achieve their outcome.
At Sorted, we’re using Kanban as a starting point for our delivery framework to promote rapid value creation for our customers, and we’re going to continue to tweak, change, learn and improve it based on what we learn.
If this sort of process experimentation excites you, then you should check out our current vacancies.