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!
Big ‘ole corporates don’t stick around like they used to. To survive companies must innovate or die. A key part of the innovative process is to be inspired by, mash-up, and build upon previous work.
The Penny Drops
I attended the ServiceNow London forum last year when Frank Slootman urged us to “Lead, Follow, or Get Out of the Way”. For a company whose market valuation and pitch to investors is based on expanding outside IT, the company demonstrated precious little leadership on how a company might actually get there. It was clearly the customers doing the leading.
In the short time since those forums the penny seems to have dropped. Knowledge included a number of initiatives to empower customers and encourage them to borrow (steal) the best ideas from each other and build solutions outside the IT department:
In terms of new features announced at Knowledge14, my personal highlights were the Kanban visual tasks boards and new features to assist Demand Management.
I can see the Demand Management features being a great toolbox and playbook for Business Engagement Managers or those tasked with direct interaction and responsiveness to business requirements. In theory – you could collect all suggestions and develop them right through to delivered services. But also include the reality check of business impact, risk and resource constraints.
Fruition Partners were showcasing the launch of their App Factory with some specialist solutions for the Healthcare market. The ‘Healthcare Management Suite’ is a set of apps built on the ServiceNow platform with Healthcare standards and compliance in mind. More info here.
KPMG stated that they had historically worked with alternative service management software providers but were now a 100% ServiceNow business. To support their growing function the firm announced a ServiceNow centre of excellence in Denver, Colorado.
As an analyst, it’s all too easy to become cynical of events, marketing hype and stock price hysteria in the technology space. With your nose pressed close to the industry effluent pipe, an observer can become jaded from the sheer volume of bilge.
Whilst Knowledge14 had it’s fair share of chest beating and hyperbole, I found the energy and enthusiasm from the event infectious. Cranky Frank the CEO gave us the company perspective and spoon-fed cute lines to journalists, the main man Fred Luddy entertained us and painted a vision of the future – but for me the main event was the attendees.
There was a genuine energy about the place as IT departments were beginning to realize they could perhaps become an enabler again and take a seat at the table of the business. The realization that ITIL and other frameworks are important, but they should be the wiring under the board – not what the customer experiences.
“We have a seat at the table, we are helping the business innovate” ~ Nicole Tate, Metro PCS #Know14
Don’t get me wrong, the streets of San Francisco were not paved with ITSM gold, organizations attending were still facing the same old incident-problem-change daily grind and curve balls as the rest of us – but there is a light at the end of tunnel.
Was it worth it? Yes. I thoroughly enjoyed it and thanks for the ServiceNow team for looking after us at a very well organized event.
This independent review is part of our 2013 Incident and Problem Review. See all participants and terms of the review here.
TOPdesk adds Kanban-type resource scheduling to add a new dimension onto Incident and Problem Management.
The Plan Board incorporates a Kanban style approach to scheduling tasks to help drive efficient resourcing
Keywords trigger standard solutions, linking into a two-tier Knowledge base (for Analysts and End Users)
Task Board for individual support staff can be sliced and diced by most time critical events
Sometimes “over-customisability” can rear its head in reviews – just because it is possible to have 7 different priorities does not mean it is a good practice to do so.
Some terminology (which can be changed with a little more detailed knowledge) can be a little cumbersome – for example Objects for Assets.
Primary Market Focus
Based on the information provided, TOPdesk’s typical market is to customers of between 500-2000 employees (Small – Medium/Large)They are classified for this review as:Specialised Service Management Suite – Offering ITIL v3 processes and proprietary discovery tooling.The offer integration to Monitoring tools.
TOPdesk offer a SaaS and an on-premise solution.The license bracket is based on the number of end users supported and an unlimited amount of users of the system.With regards to on-premise pricing, annual maintenance is 15% of the one-off value per annum.Within the SaaS subscription all fees for support, technical maintenance and hosting are included.
Truly flexible commercial model with an end user license bracket that allows for an unlimited amount of operators to be registered for free.
Genuine ability to deliver a Shared Service Centre where multiple departments may combine budgets and expertise to support end users at no additional cost.
Human Resource Plan Board functionality.
TOPdesk strongly believes in Shared Services in which multiple teams work together to deliver services to end users.
For this reason TOPdesk offers out-of-the-box solutions to support processes like, but not limited to, Building Management, Visitor Registration, Planned Preventative maintenance, HR services or Room booking management.
TOPdesk’s framework is delivered with full advanced reporting wizard, dash board, task board and plan board which will provide our customers with the tools they need to manage their processes.
The jewel in the crown of the TOPdesk solution is the incorporation of Kanban style resourcing, and some intelligent linkage of solutions and workarounds to categories and key word matching.
A while back, I wrote an article reviewing Kanban capability, but concluded that if it was standalone, it would be a level of additional work that was not practical.
To bring that functionality into the tool makes it a very powerful addition to a suite.
The basics of Incident and Problem Management are all there, and they use Wizards to try and speed up the process for the service desk.
Their deployment model is very much set-up and train-the-trainer rather than on-going consultancy, and as such the product is highly configurable.
As a result initial best practice-based implementation lies with the consultants – and unlike other vendors, it was not immediately clear the level of their experience and knowledge – so it could be easy to make the tool quite unwieldy, quite quickly.
Other little niggles lie around some of the terminology – referring to assets as Objects, and requiring a back-end change to alter that.
But all-in-all the tool was an appealing offering, with a unique selling point in the Plan Board.
Logging & Categorisation
There are some nice features here for calls being logged – where a service desk analyst can take a number of details and pull up any information on the caller, including any assets associated with them, and all calls logged by them.
It is also possible to create a custom field indicating the level of IT Competency (for example) helping the service desk to build a profile of the person they are dealing with.
Once the analyst identifies the call as an incident to be logged, all the initial notes are pulled into the new record.
From a self-service point of view, TOPdesk try and limit the amount of information initially asked for, and on an initial save more fields are activated – showing target date for resolution, priority (linked back to categorisation) and displaying any actions that have been taken to resolve the issue.
Tracking and Escalations
TOPdesk provide a capability to link key words (for example specific error codes) to categories and based on the category, can have the records automatically assigned to a specialist.
Records can be sent to a general queue to await assignment.
TOPdesk have incorporated a Kanban style scheduling structure within the tool – the Plan Board.
Using this board, all support analysts can be listed, and tasks assigned to them displayed.
In a single view, it is easy to see who is currently over-loaded with work, and who has capacity to take on more work.
It accommodates office absences, and shift availability.
In addition, Task Boards exist for the individual analysts, and can be listed in terms of SLAs and target resolution times.
As SLAs are being breached, TOPdesk use Elapsed Time Triggers to send automated emails.
The Impact and Urgency matrices shown used business language to help drive the priority for an incident but in the demo, there was an abundance of potential priorities.
There are none provided out of the box, and consultants who assist with the deployment come with standard practices to help customers in their implementations.
The terminology works on an incident being completed, and can be closed once concurrence has been given.
Within any incident record, TOPdesk offer a Major Incident tab where the incident can either be marked as the first incident in the chain or other incidents can be linked to a master.
Once multiple incidents are linked, there is a Closure Wizard which will close multiple records on resolution of the major incident.
In terms of Problem Management, in a similar way, multiple records can be linked to a new or major problem in a cart-based selection process.
It should be noted that here, the Impact and Urgency reflects more IT terminology (although this can be configured).
TOPdesk use a concept of Partial Problems where different groups can play a part in substantiating a problem, as part of determining the root cause.
This concept also exists for Incidents.
Known errors can be created after that point, and links back to their Standard Solutions to show that there is a workaround, which can be triggered by keywords during the logging phase.
TOPdesk offers some innovative ways to manage Incidents and Problems, namely using the Plan Board, but also go some way to make the service desk role a little easier with the linkage of the standard solutions to key word matching and tying those to the categories.
The product is extensively customisable, but perhaps some care should be taken to maybe show that off in combination with simpler best practices.
Wide range of ITIL®-based modules for all your business processes
TOPdesk’s Plan Board gives you all the information you need. Stay on top of your employees’ availability and workload, and assign tasks with ease.
The Task Board displays all your tasks in one overview, enabling you to see your calls, change activities, operational activities and services at a glance.
In Their Own Words:
TOPdesk makes ITIL aligned service management software for IT, Facilities Management, and eHRM help desks. Our award-winning solution helps you process questions, complaints and malfunctions. Optimize your services with a user-friendly application, experienced consultants and expert support. Raising your service levels and reducing your workload has never been easier. TOPdesk is an international leader in cutting-edge Service Management solutions and standardized ITIL software.
Our unrivalled integration, implementations and support is tried and trusted across the Service Management industry.
5,000+ organizations use TOPdesk
We are located in the UK, Netherlands, Belgium, Denmark, Germany, France, Brazil and Hungary
We are one of the top 5 Service Management software providers worldwide
In these uncertain economic times the watch words of the moment seem to be:
“Do more with (continually) less”
The effects of outsourcing both to clients of service providers and within their own organisations too means that support groups need to be as efficient as they can with (quite frankly) what they have left.
Could the visual scheduling tool LeanKitKanban, a web-based virtual signboard and card system, help Service Management support groups manage their time more efficiently and perhaps help bring about a more proactive approach to certain disciplines?
Lean and IT
Lean has its roots in manufacturing and production. It is a practice that views the expenditure of resources for any goal other than the creation of value for the end customer to be waste, and therefore should be eliminated.
Value in this context an action or process that a customer would be willing to pay for.
Stretch this out to IT, and what Lean is trying to achieve is less wasted time by support resources and more efficiency in how they work.
Kanban is a Japanese words that quite literally means “signboard” and is a concept related to lean production, and looking at Just-In-Time production in particular.
In a production perspective, kanban is a scheduling system, used to determine what, when and how much to produce.
So, looking at it from an ITSM perspective, what are you working on, when are you scheduled to finish it, and how much more are you juggling.
At a glance, therefore, you can see where work is being bottlenecked and better utilise the team to reduce the overall workload.
The key aims are:
Map out your organisation’s processes onto virtual whiteboards
On each board, processes are represented in vertical and horizontal lanes
Team members use Cards to represent work items which they can update and move across the board
The idea is that managers, customers, project managers can view this board for updates.
Pre-defined Board Templates
When you register, you get a number of pre-defined templates to select from, that best defines your business, so I looked at their IT Operations templates.
Of the two available, only Business Process Maintenance seemed to come close to mapping processes across an organisation.
Within this template are categories of Cards:
Defect, Feature, Improvement, Task
Just looking around the template, you could have cards allocated to team members to look at:
Planned Business Need (with varying due dates and High/Low impacts)
How ITSM projects could use this
The idea sounds great but the practice needs a little thought.
The boards provided in the evaluation version are probably more geared towards Software Development or wider Business Process Re-engineering.
I like how team members show up against the cards so that you can see at any one time who is working on what, but what immediately struck me was duplication of effort.
Tool vs Kanban – Incident Ticket Lifecycle
I mapped out the key parts of the Incident management process, listing how an Incident Record would move through its lifecycle in a tool, versus how that same progression could be simply mapped in LeanKitKanban.
Pre-Defined in Tool
Pre-Defined in Tool
4 definitions in Template
Investigation and Diagnosis
Assign to Team member
Assign to tean member
Resolution and Recovery
Update tcket as appropriate
Update as appropriate but no auditing
Often auto-closure configured after resolution
“Done” and archive functionality after a number of days
In order for someone outside the immediate support team or service management team to understand the progress of a ticket, they would normally be expected to have access to the ITSM tool, and to be able to see open Incidents and their progress as part of a steady state.
The idea behind LeanKitKanban is that it allows people maybe outside of that to have “visibility of progress”.
For Business As Usual, people outside the immediate support teams would normally receive Service Management reports with pertinent information.
Kanban and ITSM Solution Development
Moving away from Business As Usual, I thought I would consider its use when an ITSM solution is being developed and implemented.
Some tools do offer the capability to project manage development and testing work within the tool itself, but it does mean that people who may not ordinarily expect to use an ITSM tool would have to spend time working in it to work out progress.
Where software development is being managed using the Agile methodology, there is a useful board for that template. If the ITSM tool itself does not provide Project/Development tracking modules, then this tool would be ideal for tracking tool development and customisation.
Putting it into practice?
LeanKitKanban have a good repertoire of reference clients on their website, although I think it lends itself more to the Software Development side than more traditional ITSM implementations.
In reality, however, time pressures on an implementation project are such that sometimes even visual summaries such as these may get discarded.
For every ticket that is being worked on, a corresponding ticket would have to be created in Kanban, so who would realistically do this, and maintain it?
It makes sense for it to be a Team Leader or Project Manager, in order to have a view of progressing work, and to keep the working team free from “management noise”.
In reality, most project management calls with teams revolve around a simple status Powerpoint with Tasks achieved, Tasks to do, Issues, so now it is the project managers that are faced with duplication of effort in maintaining reporting.
In order for this to work, this tool would need to be at the heart of project reporting and most likely a more comprehensive version than the initial trial.
To get the best from this tool, you would need:
Full buy-in from all levels of Project Management to have it as the tool of choice
It would need some customisation effort for anything outside of the templates provided – which are available in the Professional Edition pricing options
Some level of buy in from the teams having to provide input for the tool, as there is a danger for duplication of effort from the teams below.
It looks most suitable for development and implementation efforts rather than as part of ongoing steady state operations.
I would also recommend using the Personal Kanban board and template as part of the free offering, which offers users a chance to split tasks into 4 project lanes, and provides columns to help users track their to-dos.
For those spread across multiple projects, it provides a little more of a visual, virtual structure than scrawling To-Do lists on paper/sticky notes, and I am finding it helpful for working on distinct areas of work.