What are the differences between Scrum and Kanban anyway? When you’re studying two similar animals from different species – I don’t know, lets use crocodiles and alligators – it’s easier to spot the similarities than the differences. I’ll give you one now and reward you with another difference for reading all the way to the end of my article. Crocs can lift their bodies off of the ground, gators can’t. Did you know that? This is a similar problem for those of us that are beginning to explore the world of Agile, Scrum and Kanban. Are they the same? From the same species? What are the differences? It’s so easy to see the commonality, because the distinctions are nuanced and harder to spot. If you’re not careful you’re unable to spot one from another. Let me help you explore some of the diversity between Agile/Scrum and Kanban
Back to the beginning…
Before examining Agile/Scrum and Kanban it is worth pointing out that there are many distinctions to be drawn between Agile and Scrum. They aren’t one and the same thing and there is probably a whole other article for a whole other day to write them up. For the purposes of this article I want to draw your attention to the suitability of Kanban in IT Operations and to achieve that I can leave Agile and Scrum lumped together. The first place to understand the contrast between Scrum and Kanban is to look back at the roots of each method. Scrum was born out of a line of iterative software development methodologies stretching back to the 1960’s and ‘70’s but coming into prominence in the 1990s as a pushback against the heavyweight Waterfall project management practices. In the ‘90’s methods such as Scrum and Extreme Programming became popular and in 2001 the Agile Manifesto was written to bind these disparate practices under a common banner. But remember that Agile/Scrum was initially formulated to solve a Software Development Lifecycle problem. Kanban incorporates a number of practices codified by the automobile manufacturer Toyota as part of TPS – The Toyota Production System – a precursor to the wider Lean movement which emerged in 1990. These roots are based in business process, in manufacturing, in the process of refining raw materials into a valuable product through manual and automated labour. In converting chunks of rubber, steel and glass into gleaming, shiny cars rolling off of the production line. Whereas Agile/Scrum was formed to provide an alternative to heavyweight Software Development Lifecycle methodologies, Lean has been more aligned to core business processes – seeking efficiency gains and quality improvements. My objective here is to speak to you as IT Professionals considering adopting a Lean or Agile approach to IT Operations. It’s worth pointing you towards the works of David J Anderson who in 2010 wrote “Kanban: Successful evolutionary change for your technology business”, informally known as “The blue book”. This is the specific variant of Kanban that you want to study and learn more about.
So wait.. Kanban is not Agile?
If we are following strict definitions and examining Agile/Scrum and Kanban as if they were two separate animals… no, Kanban is not an Agile practice. It is a Lean practice. But Kanban delivers a lot of the same benefits into an organisation that Agile promises to. And, as we’ll discover later in this post, does it in an evolutionary way rather than throwing the rule book out and introducing strange, new practices. You could say that Agile, if done correctly introduces Agility into an organisation. Notice the capital “A” there. Kanban introduces business agility with a small “a” More importantly where Agile/Scrum promotes product development agility, Kanban is positioned to make the whole organisation more agile. Kanban practices can be used across the organisation from marketing, sales, product development and customer support and value chains can be found stretching between these organisations. Best of all heavyweight processes such as Waterfall, change and release management can happily exist with the wider Kanban framework. This is the “evolutionary” part of the description in Davids book. Taking existing business processes, defining them as part of a value stream and finding ways to optimise the work.
OK – tell me more about Scrum
Scrum is a lightweight framework that defines roles (like Product Owner and ScrumMaster), artifacts (like Product Backlog, Release Backlog and Sprint Backlog) and practices (like Daily Standups, Sprint planning and Sprint review meetings). Teams following Scrum take a body of work – typically a list of features that are required to build a software product – and break them down into discrete units of work (called User Stories) that can be re-prioritised according to business needs. By taking a small section of those units of work and committing to finishing them before a short-term deadline (known as a sprint – often 10 working days) the team can focus on building the next small increment of the product before stopping, replanning and committing again. Scrum is great! I’ve been successful with teams that have used Scrum to build products. But it is a fairly disruptive method and you won’t get 50% of the benefits by putting in 50% of the effort. To be successful at Scrum you have to allocate people roles, train them and arrange your work according to the methodology. Expect to have backlog grooming sessions, to measure your work in story points and so on. Scrum is a fairly prescriptive method that requires the team to bend around the rules in order to follow it correctly. Much of the work in IT Operations is driven by external factors – servers experiencing hardware issues, ISP’s having intermittent connectivity issues. Although it’s nice to plan around the stability that Scrum promises – with a fixed sprint backlog of work – the reality is that teams have to deal with interrupt driven work and absorbing this isn’t a strong characteristic of Scrum. There is another characteristic of Scrum that appears to make this activity very similar to Kanban… that is if you didn’t understand the difference between crocodiles and alligators. The last thing to mention is that Scrum teams often maintain a “Scrum board” visualising their work on cards into lanes.
OK! Tell me more about Kanban
Well, the last thing to mention is that Kanban teams often maintain a “Kanban board” visualising their work on cards into lanes.
Herein lies the difficulty in distinguishing between Scrum and Kanban when the most visible artifact for either method is exactly the same. But there are significant differences with Kanban. Firstly it is an evolutionary method to introduce change in an organisation. Meaning that no additional roles or practices are introduced by organisations that adopt the method. Existing roles and processes are kept but are wrapped into Kanban. Workflows are investigated and visualised to provide control around the work but we don’t change how people do their jobs or interact. Scrum deals with the problems associated with Product Development and introduces methods to increase Agility. Kanban examines the value stream upstream (perhaps into the sales and marketing departments where leads are generated) through the manufacturing/development/technical departments down to the point where value is released to the customer – how products are shipped or released. It’s similar to the same way that a manufacturing process for a Toyota car is defined all the way from the raw steel arriving at one end of the factory through the refinement process until a car rolls off the other end. Kanban maps and provides controls throughout the whole value stream. Imagine you are in control of new laptop builds in an IT department. Surely you have a value stream which starts with a request from HR notifying you of a new employee. Actions are taken – laptops ordered, imaged, configured, added to the various management systems. At some point later (much later??) the laptop is delivered to the employee. You’ve just described a value stream that can be visualised, managed and incrementally improved with Kanban. Here is a visual outlining the differences between the two animals.
Scrum versus Kanban
I promised to reward you with the last difference between crocodiles and alligators. Look at the snout – but presumably from a distance. Crocs have a longer, sharper “V shaped” snout. There you go! But this isn’t the action that I want you to take away from this article. Your IT organisation should be investigating new ways of working and building a culture of high performance and continuous improvement. Agile/Scrum and Kanban are all worth investigating. My call to action in this blog post – if you are in a position to suggest work improvements in your department – is to buy David J Andersons Kanban book and see how evolutionary change is possible in your corner of the world. (Amazon Link) Most successful Kanban adoptions are lead from the “middle out”. That is junior managers taking the initiative and adopting Lean practices influencing those that carry out the work. Their successes often influence upwards as senior managers identify the resulting service improvements. Who knows – buy the book today and in a few months you could be blogging your IT transformation using Kanban on the ITSM Review. I’m looking forward to that!