“Why are you proposing Kanban if we have been maturing with Scrum since last year?”
This was a question I got from one of my teams – totally legit. Why should they try a new agile framework if they are somewhat satisfied in going with scrum? The reason is that their context of work is changing, more precisely, they are having more and more uncertainty (what’s right, how long the task will take) and, therefore, I want to ensure they know more options to choose from.
I wont step into much overall detail about their characteristics and differences, and instead will focus the things that I see more relevant in both.
- Iteration-based – The work is pre-committed and delivered in x-weeks work. Scope change is not welcome and work is shipped to the customer only at the end (even if its done earlier).
- More prescriptive– There are pre-assigned roles and ceremonies (planning, stand-ups, refinements and retrospectives). Its expected the team to deliver in e.g. 2 weeks time, what they have committed.
- Work is estimated – In order to have a commitment, work needs to be analysed and estimated.
- We have a mature team that handles their roadblocks and delivers what its committed
- We need to have previsibility of our roadmap and have alignment with stakeholders
- We aim to be super productive in mid or long-term. Some studies refer this as the most productive agile framework.
- The success of scrum is highly dependable on three things:
- the quality of the estimates, so the pre-committed work is in fact done with the expected development time. If estimates are continuing failing it will break planning, roadmap forecasts and eventually quality. From my experience this is the main factor for Scrum to fail.
- Team capacity is allocated for the sprint duration
- and we ther is low fluctuation in the scooe. If scope changes often, priorities will be re-sorted and all the upfront work (estimates, planning) around the de-prioritized work may have been a waste – even if we re-picked them 1 month later!
- Based on Lean Values – no pre-assigned roles, no ceremonies, no hard estimates sessions. It can be started over the current organizational team process does not requiring a massive change.
- Measure the lead time (average time counting from when the task was first picked until is deployed and at the customer hands), and optimize the process to make lead time as small and predictable as possible. Scrum works with velocity (SP’s per Sprint) instead.
- There is one workflow board with a limited working-in-progress. (e.g. we can only be working with 3 tasks on each stage)
- Tasks that are repetitive or similar since there are no estimates and all the work has one-size effort.
- Team size is irrelevant – team picks a task and will move it across the workflow according to their best effort
- We need to accommodate change because of high uncertainty on whats to do next. We pull one task at a time, and therefore we can pull the ones based on the most actual knowledge and already with the knowledge (e.g. research) on what we have just learned.
- May be very hard to work with big and complex tasks
- Without the retrospective session means the problems, inneficients of the process need to be addressed in the moment- which is great if people care to take that opportunity to learn and improve. If not, without the sprint-based ceremony the team may not give the change to improve the wheel.
- Lack of deadlines, without time-frames for development, the team can fall behind
What to use?
I’ve been using scrum in almost all the teams I have worked with. It’s sexy, everyone seems to do it, comes with a recipe to follow and there are a wide variety of articles celebrating its success.
The reality is that is very very hard to collect its benefits. The quality of the estimates may be frustrating as the teams tend to not work well with unknowns (even having buffers) and there is a new wave of product discovery coming that embraces uncertainly and just-in-time decisions.
Scrum when we need predictability, when handling complex and big problems that need the elephant to be cut into smaller slices. Also when its required a predictable roadmap to sort alignment with stakeholders.
Kanban on teams doing product discovery and maintenance-like tasks. Regardless their maturity level
Next step on this
While I’m getting more and more into Kanban, another fusion-framework is getting traction. Scrumban => Scrum+Kanban. Let’s run some experiments!