I’ve previously written about Kanban for The ITSM Review. I described the differences between Kanban and Scrum, preferring the former for it’s more pragmatic approach towards roles and ceremonies and it’s wider application across a range of types of work.
“Kanban from the Inside” defines a model for managers wishing to introduce an evolutionary shift towards business agility, improved quality and to achieve flow.
The Kanban Method, as codified by David Anderson, focuses on existing business processes and introducing change through focus on quality and reducing work-in-progress. The work itself remains unchanged at least initially. Done by the same workers in the same way but being measured and visualised in an effort to find “flow”.
Inspecting quality and reducing work-in-progress leads to a shift in work being delivered more often, where organisations can then focus on balancing business demand against throughput and improving prioritisation techniques.
You can see that Kanban doesn’t require a revolution in the way that you work, it’s a series of steps taken over time.
In his book Mike describes four “Foundational Principles” and six “Core Practices” that teams work through.
The Foundational Principles describe the mindset and attitude that leaders take towards adopting Kanban
Start with what you do now
Agree to pursue evolutionary change
Initially, respect current processes, roles, responsibilities, and job titles
Encourage acts of leadership at every level in your organisation – from individual contributors to senior management
Throughout the book Mike provides real-world, pragmatic, examples that support these foundational principles.
With chapter titles such as “Understanding”, “Agreement” and “Respect” he deals with the dangers of changing workflow without first understanding (remember… evolutionary change), how to secure a commitment to change, and how to deal with existing roles and responsibilities respectfully. Always a challenge whilst you are acting as an agent of change in an organisation.
The six “Core Practices” are more hands-on and dogmatic.
Limit work-in-progress (WIP)
Make policies explicit
Implement feedback loops
Improve collaboratively, evolve experimentally
Following the existing literature about Lean and Kanban, Mike talks about how to apply techniques to work to shift an organisation to focus on quality, flow, learning and experimentation.
Mikes “Kanban from the Inside” is in no way an alternative to Davids “Kanban: Successful evolutionary change for your Technology Business”. I was thinking of the best way of describing why you should buy both books to read.
The best I could come up with was this. If you enjoyed Robert Downey Jr in the Sherlock Holmes movies you’re more likely to enjoy Benedict Cumerbatch’s portrayal. Watching one doesn’t detract from the other.
Mike’s book is a great accompaniment to David’s. If you are interested in starting with Kanban I would seriously recommend buying both and starting with the Blue book (David’s).
The blue book is a little more gentle on the beginner I feel. It takes you through the introducing change into a organisation in a very thorough way. Mikes book is more formulaic and is a hands on guide to the individual techniques involved.
Although Mike takes his readers through a journey, it takes some effort and concentration to keep up with him. This isn’t a criticism of writing style or narrative – it’s because this is a practitioners guide and goes deep into some very interesting areas.
The book progresses through three parts: Explaining the Kanban method; describing other methods that are useful in applying Kanban more effectively; a step-by-step implementation guide in part 3.
In an evenings reading you aren’t going to progress from Drum-Buffer-Rope to Critical Chain Project Management without going to bed with an overactive mind. This is more a manual that you’ll keep referring back to as you progress through your adoption.
This isn’t taking anything away from “Kanban from the Inside”. It’s a great book and it’s already earned a place on my desk. I’m buying more copies for my team leaders.
If you are looking for more quality and efficiency from your teams I’d absolutely recommend this book and David Andersons “blue book” as a pair of books that have the potential to change your organisation for the better.
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.
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!
Don’t worry. I am not going to rant on about hypothetical methods or visionary statements. I will not explain why agile is important for the ITSM industry, nor will I explain why agility is crucial for business survival. After all, these are no-brainers, right? I will only use your valuable time to illustrate a practical experience on implementing continual service improvement (CSI), the agile way.
In the past few years I have been privileged to apply lean and agile principles, methods and instruments to many different (IT) service environments. Most of the assignments were focused on delivering more value to stakeholders, improving collaboration between functions and domains, and reducing change lead times. However, one of the most intriguing assignments revolved around creating a culture of continuous improvement for a professional services company.
First, here’s some context. The customer I am referring to, is in the business of providing professional infrastructure and telecom services to its customers. The IT director realized they had a huge problem, when their largest customer repeatedly complained about their supplier’s reactive behavior. Surely, the customer got what they asked for, but there was no such thing as proactive service management, let alone continuous improvement of processes and services. My customer thought that they had this covered by having an extensive description of a CSI process, according to ITILv3. Yet somehow, no real improvements were initiated, let alone carried out. I profoundly assume this does not surprise you.
Looking at the core objective of CSI, I have always applauded this addition to the ITIL set. After all, it recognized the essence of having a flying wheel for improvements throughout the IT service organization and lifecycle. However, allocating a separate process and rather waterfall and administrative approach to achieving this objective, is why ITIL’s CSI falls short in so many implementation attempts. Similar to Imai’s Gemba Kaizen, successful continuous improvement in IT services involves small, bottom-up, incremental improvements, integrated in business as usual. In addition, ITIL fails to address the most important element of achieving continuous improvement: culture. For instance, as long as the culture of the organization does not reward improvements or even does not allow mistakes to be made, those mistakes/errors will be covered up, instead of being visualized, improved and learned from.
This is where the Agile way of thinking comes in. At this organization, we introduced agile principles (eg. multidisciplinary, self-organized teams), methods (scrum) and instruments (kanban) to address their improvement issues, and to grow towards a proactive service organization. We started off with scrum. First by ensuring all stakeholders had a shared understanding of agile principles, the scrum process and its relevance to support and operational environments. After that, we allocated the roles. The complaining customer picked up the product owner role, whereas the service manager became the scrum master. The primary people involved in the service chain (service desk, design, develop, test, operations, main supplier) were involved as team members.
Then, as a joint effort, the entire team investigated the current opportunities for improvements, both on processes and delivered services. All improvements were collected on a product backlog (i.e. an improvement backlog). We used a uniform format to write them down: user stories. The good thing about user stories, is that they are short and simple, yet always address the “why” question. This resulted in user stories such as below:
In parallel, we used planning poker as an instrument to estimate the improvements. I find this a particularly useful way of estimating both changes and improvements. The relative measure (story points) appeals to the unpredictive and indeterministic nature of so many changes and improvements.
In two weeks time, we had the product backlog filled (i.e. “ready” for 3 sprints), and prioritized by the product owner. So yes, this means that the customer decided where improvements were to be made first. After that, we narrowed down the product backlog into a sprint backlog for the first sprint and started off with a planning session for that sprint. Here, we created tasks for the allocated user stories, which were added to the physical scrum board we had set up. Together with the other, obvious ceremonies (stand up, demo, retrospective), the scrum process was in place and led by the service manager (scrum master). Every day, the team members pulled their actions through the process, picked up and realized the improvements during the 3 sprints.
After three sprints of each one month, 80% of all identified improvements had been realized. And implemented. Result: an engaged customer, visibly happy with the improvements made thus far and confident regarding the proactive capabilities of the service organization. But it didn’t stop there. Yes, we stopped using scrum. After three sprints the backlog almost evaporated. But at that time, it was still positioned as a separate instrument. That is why we incorporated all future improvements on the regular kanban board, which was already used for incidents, problems and changes. Improvements became business as usual. All team members, including the customer, were actively involved throughout the delivery chain, all aimed at continuously improving the service delivery chain. The people involved were all aware of the priorities of their work in progress, and the value of their daily improvements.
I hear you say: this sounds too good to be true. Of course, we encountered several problems along the way. Quite a few team members were skeptical with regard to using agile principles and instruments. Showing them the value of visualization, sharing tasks across the multidisciplinary team and providing insight into the entire delivery chain, really catalyzed their changing attitudes. In addition, it was certainly not easy keeping everyone on track and on focus for the improvements during the sprints, next to their daily incidents, project work and other engagements. Daily stand-ups, management attention and visualizing results have surely contributed here.
Creating a continuous improvement mindset is all about stimulating a learning culture. You are never ready. The same goes here. Having a CSI mindset is not enough to keep learning effectively. Further improvements for this organization include the optimization of measurements, and a further integration of Lean and Agile elements, or from Rob England’sTIPU framework.
Agile CSI is only one example of how agile and lean principles and instruments can help the IT function deliver great services. ITSM has a key role in achieving this, by sharing practical experiences, good practices, but most of all creating the conditions for all stakeholders to improve their work, processes and services.
Regular readers of my blog on The ITSM Review, or over at ScrumProUK know that I enjoy exploring the gap between the worlds of IT Service Management and Agile development methodologies.
Today I wanted to go back to basics, back to square one and start over by explaining why you – as a reader from the world of Service Management or corporate IT – should care about Agile principles and what it can bring to your organisation.
I’m glad to see one commonly held misconception being broken down and disproven recently. The assumption that an organisation cannot be both Agile and IT Service Management orientated.
To introduce principles to those that are unfamiliar, I’m taking inspiration from Tobias Mayer who identified 5 benefits of Agile (in this particular case Scrum) that will help me orientate you.
“A man who chases two rabbits catches none.” ~ Roman Proverb
A core principle of popular Agile methodologies such as Scrum and Kanban is to limit Work in progress. Scrum teams, for example, will agree to take on a small subset of work from the overall backlog within a timeboxed period, normally between 2 and 4 weeks.
By limiting the teams focus and attention on what is most important you enable them to complete work to the appropriate quality standards; and by limiting work in progress we train teams to finish work, rather than start additional work. With focus comes attention to detail and less mistakes, a higher level of quality and ultimately happier customers.
Look around your IT department today as you read this article. Do you see teams that have more work than they can handle? (Probably). Do those teams have a clear understanding of what is most important (probably not)?
How can Service Management teams adopt the Agile principle of providing focus for their teams?
Start by understanding your work. Where does it come from? How does work arrive in your department. Visualise your work by using a tool like LeanKit, Trello or Kanbanize (all have free editions for you to try). Use one of these tools to identify which work items are the most important and challenge the team to finish those items.
By reducing the scope of work that a team is paying attention to you’ll see a change in behaviour, delivery time and quality.
“What if we found ourselves building something that nobody wanted? In that case what did it matter if we built it on time and on budget….” ~ Eric Ries, The Lean Startup
Agile teams work with the principle that plans will change; that we will understand more about the work once we near completion and that no amount of planning really prepares us for the road ahead.
This is true for software development projects where Agile is accepted but of course it’s also true for IT maintenance and operational projects too. How many of your projects delivered exactly as predicted on day one?
Knowing that business requirements will change frequently and that the assumptions made before work begins are normally wrong, Agile teams handle this by working in iterations.
By planning months into the future with “just enough” detail and by focusing in granular detail on only the next 2 week sprint, a team can easily absorb changing business requirements.
By meeting with the business on a frequent basis, by examining the overall plan (in coarse detail) and by re-prioritising against the current business requirements Agile teams achieve alignment with the business. They can plan for the next iteration in detail knowing they are working on the most important thing based on todays knowledge.
It’s no use being perfectly aligned at the start of the project and not having a system to cope with the ever changing demands. Changing requirements in a project are a good thing – it means we will have a better solution in the end.
Do your IT project teams try and control changing requirements… do you welcome them?
How can Service Management teams achieve alignment with the business?
By structuring work so that teams can focus in the short term but change direction to react to business demands. For Service Management teams this might mean short term focus on a set of metric goals to solve a particular business problem. Just having the routine of sitting with the business and reviewing priorities is a great first step.
“I don’t test my code often but when I do I do it in production” ~ Internet meme
Earlier I mentioned Focus as a principle of Agile teams and that by concentrating on a small subset of work that is most important to the business we can train teams to deliver. Rather than having lots of work open and diluting the teams attention.
There’s another benefit in limiting Work In Progress with regards to quality engineering. Imagine a team that has no control over its work and everything is urgent. The team has no Focus and no Alignment with the business – no understanding of what is truly important.
That team is likely to produce low quality work. By trying to complete everything at once they’ll often do just enough to call it done. This results in risk lurking in your infrastructure; the worst kind of work that will leap out on you when you aren’t expecting it. Work you thought was done… but isn’t. Rework!!
Agile teams use the system of limited WIP as well as technical practices and standards to get work done once so they can move on to the next task.
Could you improve the quality of work by defining standards and shielding your team by limiting work in progress?
How can Service Management team promote artful making?
Have a “Definition of Done” for common activities. Not a huge, heavy operations manual that no-one will ever read but a collection of one-page definitions of what it means to be done with a server build, a software installation, a Problem ticket.
Make the definition of done visible and easy to use, your engineers will know when they are finished with a piece of work before moving on.
The best architectures, requirements, and designs emerge from self-organizing teams. Teams that are not controlled but enabled. Teams that stay together long enough to form an esprit-de-corps and that trust each other enough to have passionate debate and disagreement without destroying the teams culture.
The worst experience that an engineer can have is to be presented work that was designed by someone else, work that has no scope for flexibility or creativity, and worst of all to be told how long it will take.
Have you ever worked on a project where the scope, implementation and deadline were predetermined by those that aren’t actually going to do the work? How does that even happen??
Agile teams are self-organising within the constraints of the organisation in which they operate. They receive requirements that describe the business need (The “WHY”) and acceptance criteria (“The WHAT”) and they, as a team, determine the solution (The “HOW”).
Self-organising teams scale much better than command-and-control style teams, where a manager delegates and defines the work.
Why would you want to have your expensive managers involved in assigning tasks and resource levelling? Members of a self-organising team know when they have spare capacity for more work and they pull work into their queue.
How can Service Management teams become more self-organising?
I think this is a simple one – do you have managers that delegate work or leaders that coach teams to success? If you have the former is that the best use of their time and skills? Give the team an opportunity to own their work and determine their own destiny, within the constraints of your organisation.
This loss of control by managers might result in a team more invested in its success, more motivated and higher performing.
“Rhythm is something you either have or don’t have, but when you have it, you have it all over.” ~ Elvis Presley
Agile teams are focused on the regular delivery of value into the businesses they serve. By limiting work to sprints, usually between 2 and 4 weeks long, they are able to continuously deliver work building a partnership based on trust.
Because they focus on a subset of all possible work and they have quality standards they can deliver work of a high quality which deepens that trust.
Short time-boxes focus teams on an objective they have to meet – by self-organising they control the scope of work that is achievable within that sprint. When I started delivering work to a company using Scrum I asked my stakeholders which attribute of the work they valued most.
Was it the speed or the volume of work, or the number of features we delivered? No – organisations rely on predictability and working in set time-boxes, or sprints, makes your team predictable.
Compare this to projects that defer the delivery of value until the end of the project. Rather than release early and often they buffer the features and aim to deliver all in one large batch.
If that deadline is delayed two unfortunate things happen – firstly trust between the team and the business is eroded. And secondly the value represented in the features that are done but not released cannot be realised until all work is delivered.
Do you have a trust between the IT organisation and the business which is built upon a rhythm of regularly delivered work?
How can Service Management teams get that sense of rhythm?
I love the idea of working within constraints. It focuses the mind and makes people be creative. Even if you don’t work in software engineering define a series of 2 week “sprints” for your Service Management team.
Declare an objective for the two week sprint – “we are going to reduce the incident backlog to under 50”. Let the team self-organise and think about your teams objective for the next sprint.
Thanks for Tobias for his 5 attributes of Agile teams that I’ve expanded and commented upon. My aim here was to outline the benefits of Agile to teams outside of the world of software development. I hope that readers that work in IT Operations and engineering can compare the way they work currently against these ideals – all of which are simple and cheap to implement and realise.
Ultimately the ideas of focus, alignment, artful making, self-organisation and rhythm promotes a culture of learning – about the work you handle, about how the team performs and how you interact with the business.