kanban-blog-graphic

How we have used Kanban to deliver better software support

If you are unfamiliar with the term, Kanban is a system introduced at Toyota Manufacturing. It is a Lean methodology for indicating when operations need more materials, using coloured cards. In 2009/2010 it was co-opted for use in software development to improve efficiency and flow. Kanban is not a process like Scrum, it is a means for process improvement, and it has helped us deliver better software support.

Once we have completed development of a product, we almost always provide on-going support and maintenance for our clients. Support works as a safety net. So, if our customers encounter any problems once the application is running in production, we will help.

Implementing Kanban for software support

We have always prided ourselves on our ability to deliver a highly responsive standard of support. Implementing Kanban has allowed us to refine the process and make incremental change to improve efficiency.

To set the scene, when we first implemented Kanban at the end of 2017, we had approximately 200 open support tickets across all our customers.

I am going to talk through how we chose to use each of the 6 main Kanban practices. And how we have evolved our process by using Kanban to show us where the problems lie.

Visualise the workflow

The first thing we did was to visualise the way we deliver support. To start with we visualised these columns:

  • To do
  • Doing
  • Resolved
  • Testing
  • Done

As time went on, we realised that we needed to reflect that our ability to work on items was sometimes dependent on customer input, so we added a “blocked” column, where we could put these items.

We decided to manage all our clients’ work throughout the same process, so we created one Kanban board for all the support tickets, with filters to allow us to view the items for each client at a time.

Limit work in progress

To begin with, we had a small number of engineers working on support. However, over time we realised that spreading the load across the team meant that we had more expertise at our disposal.

Having several developers working on support means we need to be careful we don’t overwhelm the quality assurance team with testing tasks. So, we limited the items in “doing” and “resolved”, so that the developers weren’t working on too many, and the testers were able to keep on top of the workload.

After a while, we introduced more WIP limits on “to do” and “testing”, to limit the number of items waiting to be worked on, and the number of items in testing. This encouraged flow, by alerting the team to any work backed-up in the system.

Measure and manage flow

As soon as we created the board and added the issues, we realised we had a huge backlog of “resolved” items. According to our process at the time, we would wait for a customer to test and confirm approval before we closed an issue. The customer might take a while to do this and these tickets would be forgotten and left open indefinitely. Modifying the process so that we could close tickets once tested internally, was one of the first changes we made.

We continue to make incremental changes such as these to this day, to manage the flow of the system.

To ensure the developers progressed support work, we would assign them tickets in a daily support review meeting. Once they became used to the idea of working on support, and maintaining the board, we were able to stop this. Now we have a twice-weekly meeting in which we discuss any items that have not moved on and agree a course of action. The development team is now self-organising.

Flow is also measured using the Cumulative Flow Diagram, which shows the number of items in a column over time. This helps us identify if there are problems in the flow. For example, if the developers are moving too fast, the “resolved” column area will get wider.

Cumulative flow diagram

Make process policies explicit

A dedicated member of the operations team manages and maintains the support process. And the process is audited annually as part of our ISO 9001:2015 certification. This means all staff, even those not involved directly, are aware of the policies for the support process.

We have now defined and documented policies to deal with the following, amongst others.

Item Policy
Aging or stuck WIP Anything over 30 days old is flagged and priority is increased
Blocked or impeded items Items are moved to “Blocked” status and customer is updated; ticket is closed if no response is received in 14 days
Re-work and defects Items that fail testing are returned to the same developer and moved to the top of the list
Coordinating different types of work Different categories of issue are marked for easy identification on the board

Implement feedback loops

As our Kanban runs alongside our Scrum Process, we use our sprint retrospective to review it. During this meeting, we use various exercises to gather feedback from the team on how support and the sprint are doing. This feedback generates actions, for the team to make changes / improve the process.  

We also run regular surveys to gather feedback from the team anonymously. This allows us to check in on whether the process is understood as well as how the team feels it is working. These are run quarterly, and feedback is reviewed with the team in our monthly improvement meetings.

Improve collaboratively, evolve experimentally

At SAS Applications, we use Lean to drive efficiency via continuous improvement. Our entire team is empowered to identify problems, escalate them, and make changes to fix them. This applies to all our business processes.

This means that our team has a documented, and structured way to provide feedback. And a mechanism in place to make improvements based on that feedback, if necessary.

We have worked hard to create an environment in which the team feel confident enough to be able to tell us when something isn’t working and propose a solution. This collaboration with the team who are doing the work, has changed the way we do business. It has created new commercial opportunities, enabled new revenue streams and changed the way we engage with our customers.

Summary

Our continuous improvement journey will never end. But we feel confident that we have been able to deliver a superior level of support to our customers having implemented Kanban and continuous improvement.

The following graphic shows the levels of the Kanban Maturity Model. This is a structured framework for incremental development of a team’s Kanban implementation.

Kanban and software support form only a part of all our continuous improvement and Lean efforts but they provide a great example of how we have used Lean to overhaul our business.

To find out how we can support your business, contact us to book a meeting.

Liz Williams

View posts by Liz Williams
Operations Director Liz engages with every part of the process at SAS Apps, supporting the team to deliver exceptional products to our customers. She also facilitates the continuous improvement programme, empowering the team to be the makers of the change, and drive the business to success.