Many people think that the answer to their problems is to pick an agile approach and use it to deliver their services. In doing this they frequently put the needs of service development ahead of the wider organisation and risk overlooking well-known constraints and context that will trigger failure. Kanban, Scrum and XP each have several key implications which need to be properly understood before taking the plunge.
Whooah! Stop and hold that decision, just for a moment. Before you make a choice that might trap you.
There are a thousand places where you can learn about how Scrum and Kanban work but few properly explore their wider implications. The reality is that service development doesn’t exist in a vacuum – it is intrinsically linked to strategy, market conditions, sales, delivery cycles and support considerations, and of course customer need, let’s not forget that!
Beyond the detail of the methods and their pros and cons, there’s a key difference that can be the difference between success and failure.
Scrum is based on fixed iterations (or “sprints”) lasting anything from a few weeks to a few months. Work takes place within these time-boxes with a discrete beginning, middle and end. At the end of each sprint a tangible increment of completed work is delivered for all to see and evaluate.
Scrum is great. Everyone knows what is going on and what is needed and when. It breaks down work into small chunks, turning large problems into manageable small ones. It lets us you keep re-prioritising and responding to changing needs. It provides a regular cycle of delivery that you can set your watch by.
Except when it doesn’t because the sprints over-run. Except when the cycle doesn’t fit with the needs of customers, sales cycles or external service constraints. Except when other people within your organisation do work that cannot be easily broken into small iterations. Except where operational constraints are a barrier to incremental delivery.
Scrum is “high discipline”. It focused on the service development approach and has little to say about staff who are not involved in that development. They are expected to adapt and fit with Scrum. While you can flex the size of your sprints, that’s a band-aid and not a path to smooth delivery.
The big question with Scrum is: can my organisation work this way top to bottom and will this work for my customers?
Kanban is based on continuous flow of a stream of tasks. It has a lot in common with Scrum but has no iterations at all. Work is simply pulled from a queue as capacity is available. Tasks are completed as quickly as possible and deliveries of improvements can be made whenever is convenient, batching up a series of completed tasks.
Kanban is great. It is simple and easy to use yet very powerful. Its flexibility lends itself to a wider set of situations than Scrum and it adapts really well to changing circumstances. There’s no need to estimate tasks accurately before doing them. You have maximum freedom to change your mind and direction.
Except when what you and your team needs is the discipline of a regular delivery cadence to focus minds and force taking hard decisions early. Except when you have operational and market constraints that dictate when you can deliver. Except when that virtue of flexibility will be a distraction.
The big question with Kanban is: do we have the discipline and opportunity to work this way?
This is not about whether Kanban is better than Scrum or Scrum is better than Kanban. That’s not a sensible comparison because it depends who you are, what you do and what you need. You might as well ask if an apple is better than custard – it depends. And there just as there are some people who like apple pie with custard, there is also Scrumban.
Know first what you need and only then evaluate and choose a method.
Licence and Terms of Service
Methodologies are only a template – a guide, if you like. The best approaches are those perfectly tailored to local needs based on well-known principles. So take what works for you, embrace and extend it, creating your own mashup. But make sure you properly understand the principles and moving parts first, or you risk disaster. Ignorance is no basis for experimentation.