The truth about Scrum, Kanban and Agile why they are not the same

This post was born out of a comment from a friend who works for an energy company. He is not an IT professional, but he lives and works on the periphery of technology. He has a keen ear for IT bulls**t and the stuff that consultants, specialists and domain experts will sometimes say … so a perfect fit for what we are trying to remedy at IT elementary school! So why the snake oil, obfuscation and BS? There are a number of possible reasons for this, including; (a) they are trying to sell you something, or (b) creating a sense of distance or mystique, or even (c ) to cover their lack of knowledge. In a list of such terms, familiar to players of buzzword bingo I was surprised to hear Scrum and Kanban. But these are real things, they do not live in a world of strategising, work-shopping, white-boarding and similar abstractions, metaconcepts and zombie nouns (Ref. Steven Pinker, The Sense of Style).

A short Agile refresher

(See IT element Agile for more detailed explanation)

Agile is a philosophy and a framework for the efficient delivery of high quality software, although in more recent years it has been corrupted and confused to mean anything from being agile (i.e. flexible, responsive, and fast-acting) to a hybrid mess of new ideas and language with traditional approaches.

Agile is not prescriptive, it is not a method that dictates the ‘what’ or the ‘how’ things should be done … it really doesn’t, so be wary of a consultant or software provider who promises an off-the-shelf set of processes or a ready-made solution. Agile should evolve and adapt to suit specific circumstances, organisational culture, and context. What the Agile Manifesto does do is provide a set of values and principles relating to such basic tenets as people, prioritisation [of needs/work items], change, sustainability, team organisation, and the interactions necessary to deliver good quality software quickly and efficiently.

The skinny on Scrum

Scrum is a specific approach that will fit the Agile framework if implemented consciously and consistently, it should do because it was one of the inputs to the creation of the Agile manifesto. In my experience it is the most popular flavour of Agile being adopted by organisations. Here are some highlights of what adoption of Scrum should entail:

• Scrum uses short, fixed duration (development cadence), [software] development sprints,
• Sprints deliver against a prioritised list of things to be done (backlog),
• Scrum has a number of optional, but recommended, group tasks and ceremonies including; backlog refinement/grooming, sprint reviews (show and tell), and retrospectives,
• Any impediments to finishing tasks in a sprint are actively managed to maintain momentum so that all the committed work – the sprint backlog – is finished whenever possible,
• Typically measures of team performance and work throughput are used to understand and optimise activity. These measures include team capacity, delivery velocity, burn down rate of tasks completed over time against a notional linear chart,
• Scrum does not use a traditional project plan, as it is a continual delivery model, although outside the team’s immediate concern there may be a larger-grained roadmap or release schedule.

Scrum teams are multi-disciplinary and self-organising, although they typically have a dedicated Scrum Master to help develop operational best-practice and make the whole process and team performance as efficient as possible. Ideally the Scrum Master and the whole team should constantly strive to improve the quality and throughput of work; I will touch on this again later.

Kanban Knowledge

With special thanks to Chris Hefley at LeanKit, I have used some ideas from his guide ’Kanban Roadmap: How to get started in 5 steps’ and a presentation at Suffolk University. See this related webinar:

https://leankit.com/blog/2014/02/map-your-process-with-kanban/

As with a lot of mid- to late-20th management and IT practices, Kanban started in Japan. Toyota developed a visual system to represent a just-in-time (JIT) production line and drive for Total Quality Control/Management. Kanban is Japanese for a sign, board or visual symbol; this shouldn’t be forgotten in the race to fit Kanban around your existing tools and logistics, Kanban is all about ‘ … better communication through visual management.’ (Leankit).

Kanban fits nicely into the Agile family of non-traditional software development approaches. However, unlike Scrum, Kanban does not have the concept of a fixed timescale, it’s all about the flow of tasks (left-to-right or ‘to do’-to-done) and continuous improvement to reduce unproductive activity and actively manage bottlenecks, impediments and queues. Here is where software development is the same as a physical production line or distribution process; there is no value to the process (and the owner of the process) in having things lying about doing nothing in a work queue or a physical artefact in a warehouse.

Here are some suggestions and pointers to implement Kanban.

(1) First understand your process*

The Kanban board should model the existing process or workflow so the first step is for the whole team to analyse and understand the nature of the work, the tasks (steps) undertaken and players involved. Think of this as a Current Situation Analysis rather than a process redesign. Incremental improvements will follow naturally once Kanban is up and running. Consider the whole process but focus in on the transition into and out of each step/(swim)lane; where does the work come from and where does it go to next? Getting these transitions right is one of the keys to keeping everything moving.

*although essentially you are building (visualising) a complete system on the board, including overarching goals, capacity, human and technical dimensions.

(2) Work on the team culture

It’s may be obvious, but it is genuinely all about the team performance, working together to make the whole better than the sum of the parts. It’s implicit in all the other points here that the team decides how Kanban works best for everyone.

(3) Don’t be afraid to meet, talk and implement improvement actions – but be disciplined

That’s it really. Meetings are good; developers sharing a problem, testers talking to developers about testable conditions, anyone talking to the Product Owner (or other stakeholder) to clarify their understanding. However, if the whole team is involved [in meetings] then make sure that it is a productive use of everyone’s time, i.e. they result in a positive outcome and actionable items.

(4) Pull, not push

No I’m not talking about Dr. Doolittle’s llamas! Again think about JIT and changing the mindset from  a traditional push system as dictated by a project plan dependency or milestone, to the recipient actively pulling-in work items … zero waiting time is good for everyone.

(5) Reduce task switching

Again, this is intuitive, although it needs to be reinforced, especially where the organisation culture is to look busy and take on more work than you as an individual or a team can handle. It is always better to finish something than to (re)start something else with the overhead of switching your attention and trying to multitask (again Pinker lets us know how few pieces of information the human brain can handle at the same time). There is nowhere to hide in Kanban, work is there to be completed and there are no prizes for juggling too many work items and not delivering. Counter-intuitively limiting work-in-progress (WiP) is a good thing for work-flow and to increase throughput.

(6) Regularly ‘Walk the board’

This is a key message from LeanKit; use the daily stand-up and any other opportunity to ‘walk the board’, from right to left. Look for any big queues (loaded lanes) that might be developing; ask whether any tasks have been inactive for a long time and why; review any approaching deadlines. More mature Kanban teams will also have a range of measures to monitor. For example, how long things take to traverse the board (lead time), throughput of tasks (a bit like Scrum velocity), and the subtle interplay between capacity, queue sizes and limits.

Note: i’ve not gone into the detail here, but each task or statement of need (normally a virtual card or a real post-it note) will not only describe the task/work-item/requirement, but should include other meta-data, such as [business] value, priority, estimate, classification (type of task) etc.

In summary

In the context of software development, and increasingly wider business and non-IT processes, Scrum, Kanban and Agile are real things! They have suffered the same way as anything perceived as new, trendy, disruptive and challenging, i.e. confusion, misinformation, ignorance, and even wilful misuse of the basic rules of the [new] game, whether you are implementing Scrum, Kanban or even Scrum-ban* I think it’s helpful to consider adoption of new Agile practices as an evolution rather than a revolution. Don’t be too hard on (y)ourselves, invest in some training but better to learn on the job, expect some dips in performance before everything begins to work smoothly. But, most importantly, try to use the right terminology and don’t let the snake oil salesmen anywhere near your Scrum team or Kanban board!

*(Ed. there is a hybrid approach, but I’m not sure its a legitimate alternative to doing either Scrum OR Kanban well, it definitely doesn’t need new jargon!)

Thank you for any comments on this post. And I would love to hear your feedback and anecdotes from the world of Agile.

(c) 2018 IT elementary school Ltd.