Scrum or Kanban – which is right for you?

Scrum or Kanban – which is right for you?

As more organisations move towards an Agile way of working, it goes without saying that their teams need to choose an Agile framework to help them get things done. But with so many Agile frameworks available, there is debate about which to use. This article compares and contrasts two of the most common – Scrum and Kanban – to help you decide which is right for your team.

Where Scrum and Kanban are different – but also surprisingly similar…

New development teams often criticise Scrum, complaining that it involves a lot of meetings and they would rather just get on and develop. Their next request is usually to move to Kanban because they think it means less structure and fewer meetings.

In fact, it’s quite the opposite. Kanban requires a lot of self-discipline and a constant analysis of metrics and data. Kanban also has a structure of regular meetings

(Appendix A: The Seven Kanban Cadences).

In fact, both Scrum and Kanban are based on the same approach. The meetings form the backbone of the Inspect, Adapt and Continuous Improvement iterative cycle.

Continuous Improvement Cycle

So, what are the characteristics of each framework?

Scrum is a push system – where you plan an iteration in advance and work through it. Kanban is a pull system – where you pull the highest priority item from the top of the backlog, work on it until it’s finished, before pulling another. But in many other ways they are similar.

Iterative & Incremental Delivery

Both deliver incrementally, building working products piece by piece and deploying to Production on a frequent basis. Scrum delivers at least once per sprint – commonly, but not necessarily, a 2-week timebox (i.e. incrementally AND iteratively) and Kanban preferably delivers as soon as backlog items are complete, although some teams may still use regular releases rather than CICD (Continuous Integration, Continuous Deployment).

Collaboration & Feedback

Both emphasise the importance of collaboration, transparency and feedback loops – within the team, with other teams, throughout the organisation, and (ideally!) with your customers. This should reduce dependencies and bottlenecks, keep the team aligned with business priorities and maintaining simplicity (gold-plating and developing unnecessary features is expensive!). It gives the team a voice in discussions on requirements and priorities, which in turn gives them autonomy and greater empowerment.

Continuous Improvement

Both use methods to inspect and adapt to achieve continuous improvement – keeping teams operating at their best by addressing challenges and issues before they negatively impact the team or the flow/delivery, and by seizing new opportunities.

Metrics Analysis

Both use metrics to identify improvements to predictability and productivity by adjusting processes, practices and behaviours. Kanban focuses on reducing waste and improving flow by examining metrics such as Cycle Time, Lead Time, Throughput and Cumulative Flow. Scrum focuses on examining sprint metrics such as:

• Say/Do Ratio (how much does the team say they’ll complete at the start of the sprint vs. what they have done at the end of a sprint)

• Velocity (the average number of points completed per sprint)

• Throughput (the number of items completed per sprint)

• Burndown Charts (progress of completed work tracked against an ideal line for completion by the end of the sprint)

• Cycle Time/Lead Time (see diagram below). Analysis of these will show queues/delays in the process of getting software to customers, which can be targeted for improvement.

5 data points to capture for Cycle & Lead Time

Planning & Forecasting

Teams need to use their metrics to become more accurate when they plan and forecast. A stable Cycle Time means that a team can predict how long it will take for them to for them to complete a backlog item on average.

Scrum can make it easier for teams to plan and to forecast delivery as the inbuilt timebox of the sprint provides more data to highlight issues and identify appropriate changes. For example, Say/Do Ratio and Burndown Charts measure predictability – is the team able to deliver what they forecast? If not, what can they change to become more predictable? Are their stories too big? Are they considering capacity (holidays, training, support etc.) when planning?

With Kanban there are no in-built trigger points, so teams need to be very disciplined in using their metrics, and there are fewer predictability metrics available

Backlog Item Breakdown & Refinement

A mature team is able to break down backlog items down to smaller increments that still deliver value.

Both Scrum and Kanban work best when backlog items meet the INVEST criteria.

INVEST Criteria

Scrum’s sprints ensure that backlog items are no longer than 2 weeks (and preferably less!). Teams working in Kanban need to be disciplined in breaking down their backlog items and ensuring that they are small enough to avoid too much deviation in size. Smaller backlog items are more accurate – whereas a 3-month piece of work has a lot of unknowns and deviation from the original idea. Instead of painstakingly trying to plan a 3-month piece of work, identify what value you could achieve from that 3-month item in the next 2 weeks. This gives you greater certainty – and you build on it incrementally. A mature team also ensures backlog items are well-defined and don’t result in lots of re-work (the well-known software maxim of Garbage In, Garbage Out). Starting work on poorly defined backlog items inevitably results in becoming blocked or not knowing when you are “done”, which will negatively impact your Cycle Time and ability to deliver at a sustainable pace.

Who should use Scrum and who should use Kanban?

As a general rule, if your team is good at breaking down stories, has an active interest in the metrics, always looks for opportunities to improve, and has a stable cycle time, then Kanban may be suitable. If the team is less mature, then Scrum may be the better option.

Teams who work only on new products/features can use Scrum or Kanban. Many teams of this type will start with Scrum, and only when they’re very stable and mature would they consider moving to Kanban.

Teams who have a mixture of strategic work and support and maintenance can use Scrum or Kanban. When using Scrum, teams must track the ratio of the different types of work (planned and unplanned) and use this data to understand their capacity available for strategic, planned work. Capacity considers the availability of the team, as well as the proportion of time that should be reserved for unplanned support and maintenance work. Obviously, this is approximate and a major incident can torpedo the whole sprint. On the other hand, there may be little to do one sprint, and the team should ensure that enough work is ready so that they can pull things in. This will often take the form of small items of tech debt or similar tasks that can be picked up and put down again if something critical comes in. Again, most of this type of team will start with Scrum, and only when they’re very stable and mature would they consider moving to Kanban.

Teams who deal only with support are recommended to use Kanban, as their work is all highly unpredictable and planning a 2-week sprint is next to impossible. They need to ensure that their backlog is constantly reviewed so that they highest priority items are tackled first.

Here at Liqueo, we provide organisations with the skills to implement programmes successfully through our flexible workforce model, tailoring solutions for our clients’ strategic goals. We deliver an exceptional, bespoke service to every client via a dynamic and agile framework. If you need us to help you implement Scrum or Kanban or want more information, contact us.

Appendix A:

The Seven Kanban Cadences

Team Level Cadences

The Daily Meeting

Similar to the Daily Scrum – an opportunity to synchronise with the rest of the team. Usually uses a Walk The Board format, where the team looks at the tasks on the Kanban board from right (closest to Done) to left, to understand what is needed to get items over the line to Done and to ensure that WIP limits are being observed. Team members will typically pair or swarm to get items to Done or to relieve queues and bottlenecks in the workflow.

The Replenishment and Commitment Meeting

Similar to Backlog Refinement and Sprint Planning, held as often as the team needs to ensure that priorities are up-to-date and to keep the backlog fresh and well understood – usually at least fortnightly but often teams will review this daily.

The Team Retrospective

Similar to the Sprint Retrospective, held fortnightly or monthly. The purpose is to examine the team’s metrics and identify continuous improvement opportunities in their processes and practices to improve flow, team happiness etc.

Service-Oriented Cadences

The Service Delivery Review

Similar to the Sprint Review but held weekly, as Kanban doesn’t have iterations. As with all Agile frameworks, the ideal is to demonstrate working software but the purpose is to examine the progress on the product backlog, ensure items delivered meet customer expectations and KPIs, that priorities are still valid and to identify issues with flow, new opportunities etc, so this can take the form of discussions and presentations, if working software is unavailable. This can involve several upstream and downstream teams.

The Flow Review

This is a sub-cadence of the Service Delivery Review and may alternate with it. It can involve several upstream and downstream teams, as flow is a critical Kanban metric. It examines the metrics for the teams involved and focuses on ensuring that dependencies are managed, blockers are removed and flow is maintained or improved.

The Operations Review

Held monthly, this is an extension of the Service Delivery Review. It has the same objectives, but involves the wider organisation to ensure that the organisation’s delivery flow (i.e. lead time) is maintained and optimised, and that any organisational blockers are removed.

The Risk Review

Held monthly, the Risk Review looks at issues and bottlenecks identified at the Operations Review and the Service Delivery Review, to assess and deal with them, assigning them to owners or escalating them, as appropriate.

The Strategy Review

This is held quarterly. It is the highest-level review, and its purpose is to ensure that any adjustments to strategy resulting from customer feedback or market research is permeated throughout the delivery organisation, subsequent adjustments are made to backlogs, and everyone remains aligned.