Scrum vs Kanban

Is this an Alligator or Crocodile? Read this article to find out (Oh... and you might learn about Kanban and Scrum too!)
Is this an Alligator or Crocodile? Read this article to find out (Oh… and you might learn about Kanban and Scrum too!)

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.

Scrum Board

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.

Kanban Board
Kanban Board

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
Scrum versus Kanban

In summary

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!

Image Credit

…It’s a Crocodile

Supplier Relationship Management – An emerging capability in the ITSM toolbox

"Development opportunities can be completely missed because the two organizations have not properly explored how to grow together, indeed contractor enthusiasm may be misinterpreted as land grabbing."

Paul Mallory is VP Europe and Africa for the IACCM, with responsibility for member services, training and certification and research.

The recent article on the role that SLAs play in the relationship style between two organizations made me think. For some relationships, SLAs replace or even reduce the effort that an organization puts into managing the strategic development of opportunities between client and contractor.

If the contractor is seen to be achieving their SLAs then they are considered to be doing their job effectively.  If they are missing their SLAs then there is a large focus on understanding why they have failed and potentially much discussion around any mitigating circumstances the contractor puts forward.

SLAs definitely have their place as they allow the client and contractor to look at service development and continuous performance improvement through stretch targets based on the existing contractual agreement.

However, supplier relationship management (SRM) comes into effect when you want to truly transform the way in which you work with your suppliers.

So first up, how should we define SRM?

In our recently launched SRM training course, the IACCM defines SRM as:

“The function that seeks to develop successful, collaborative relationships with key suppliers for the delivery of significant tangible business benefits for both parties”.

Why is SRM important?

The average tenure of a CIO is about 4.5 years.  Most IT Service Management contracts (be it for any of the ITIL disciplines, applications or data centre outsourcing) are for between 5 and 10 years, with public sector contracts often reaching and even exceeding the upper end of that range.  Therefore it follows that those people who were in place at the outset, and developing the IT strategy, may not be there further down the contract lifecycle, yet the contractual relationship continues to exist and needs the right management practices to bring the expected benefit to both sides.

Furthermore, with the cost of IT services re-procurement often being around 30% of the annual contract cost (once transition, exit and procurement time has been taken into consideration), implementing a successful contract extension becomes a financial KPI.

Keld Jensen, Chairman of the Centre for Negotiation at the Copenhagen Business School, has identified that 42% of contract value is left on the table and not even addressed or even recognised by either party during the initial negotiations.  This means that in ITSM contracts there is great opportunity for both parties to access that 42% once the negotiation and procurement teams have left the room.  The supplier relationship manager is part of the mechanism to enable that.

What does a Supplier Relationship Manager do?

First, we must remember that IT Service contracts can incorporate a number of inter-related disciplines (especially if we take the ITIL view).  Each of those teams is going to be heavily focussed on their immediate needs and how their portion of the supply chain is delivering to them.  They will also be interested in where there are process hand-offs, but my experience has shown me that often there is a poor, singular joined up view across IT disciplines.

If this is the case, a weak supplier will maximise this to their advantage, especially where they are delivering many facets of ITSM.  They will minimise exposure to their service shortcomings and keep their network of relationships separate and distinct.  A good supplier though may just accept the frustration of dealing with a discordant IT department and focus its development opportunities on its other customers, the “customers of choice”.

In both scenarios the client does not access the 42% of value that Keld Jensen discusses, it may be from fire-fighting performance issues or an inability to properly interact with the supplier through a lack of focal point.  This is where the supplier relationship manager steps in, because they are there to:

  • Manage all aspects of the inter-company relationship, especially where the supplier’s remit goes beyond ITSM
  • They look to build trust through open communications, both internally and with the supply chain
  • They understand the full capability of the supply chain and will seek to develop successful, collaborative relationships with key, strategic suppliers
  • They share company strategy, mission and values with the suppliers
  • They ensure that the relationship follows appropriate governance requirements
  • They have ready access to, and influence from the top levels of management
Paul Mallory, IACCM
Paul Mallory, IACCM

By understanding not only the strategy of IT but also of the company as a whole, they are in a position to create a collaborative relationship with the strategic suppliers where mutual win-win opportunities are developed and encouraged.  Innovation can be targeted at the right teams, process efficiency can be realised and cross fertilisation of ideas can occur between teams who may not have realised they were working towards similar outcomes.

The supplier is turned into a strategic asset that can positively affect your organisations success, rather than an entity whose invoices are paid each month if service targets were met.

Through the conversations that the IACCM is having with its membership, we see that SRM is an emerging discipline which is becoming more important in these times of austerity.  There needs to be value for every pound, dollar or euro an organisation spends.  Effective SRM is there to ensure that value is realised.

Paul Mallory is VP Europe and Africa for the IACCM, with responsibility for member services, training and certification and research.