Kanban & Digital Operations
Before I joined Spark Ventures (the R&D group of New Zealand’s largest Telco, Spark NZ) I had always been frustrated with the planning (or lack thereof) of non-BAU work. Basically, anything that fell outside of Incident, Problem & Change was usually captured in an IT Service Management (ITSM) tool. To ensure better planning and alignment with the Spark Ventures software delivery team we adopted and adapted Agile methodologies by using Kanban for the IT Operations teams as a way of planning out work that required operational resources to complete.
Adopting and adapting Agile methodologies: How ITSM and Agile can Work Together
At the time Spark Ventures had a large software development team using Jira to run and plan their sprints. As we already had the expertise within Ventures, so Jira was chosen as our Kanban tool of choice. It also fitted in nicely with our “Cloud First” approach to applications consumed by Spark Ventures.
What is our Operational setup?
Our Operations teams consisted of 3 DevOps Engineers with a further 7 Sys Admin/Engineers and 2 Help Desk analysts/Tech Support who were all focused on supporting a number of customers, both internal and external. Work carried out by the Operational team could vary from granting access to environments, designing totally new solutions or building new AWS instances for Developers.
What were we trying to solve?
- Forward planning non-BAU work
- Creating a future road-map for work – backlog
- How do we ensure Operations do not become a blocker for Software Development?
- How can we track time spent in order to capitalise the team’s time?
- How can we share with the rest of operations what we are working on?
- Demonstrating the value of Operations
- Reduce shoulder tapping of Operational resources?
How did work get into Digital Operations?
To begin with, we classified work into a number of categories; Project Requests, Feature Requests, Service Requests (I want something) and Incidents (it’s broken). Once work was classified it was dealt with either by Jira (Project Requests, Feature Requests) or RemedyForce (SaaS-based IT Service Management tool). We also created high-level epics that allowed us to break down work into smaller tasks and then associate them with our customers. Within Jira we also enabled the time-sheeting functions so the teams could estimate time for each task and then, once completed, they could put actual time spent on that task so their time if required could be capitalised.
Why Kanban?
Kanban seemed to be a more adaptable approach (than say full-on scrums/sprints) in meeting our needs and was relatively easy to adopt by the team with minimal training and effort. It also allowed work to be prioritised. This approach has led to a number of benefits, such as a significant decrease in shoulder tapping to request work, more certainty for the Operations teams in their workload and closer collaboration with the Development team sprints where Operations is not seen as a blocker.
We ran a fairly simple Kanban board with 3 columns; To Do, In Progress and Done (see below). We had also decided to create high-level Epics enabling similar tasks could be put together, it also assisted with assigning budgetary amounts (as part of our annual financial planning) against those Epics.
The reality, it’s an iterative approach
It has been an iterative approach, where we have taken the elements of Kanban that suited the way we worked. That said, we have not been afraid to change the approach if it is not working. For example when we first started we initially held daily stand-ups but that soon changed to every other day and, eventually, changed to having them at the beginning and end of the sprint only. We do however run 2 weekly sprints so the team have a known time period in which to complete the work assigned. Kanban also gives our customers (being the Product Managers) some certainty of delivery times.
When adopting any methodology it must be a case of rigour without the rigmarole #agile #kanban
The journey so far…
Start with the problem(s) you are trying to solve and work on a solution from there. That said, any solution chosen should be evolved over time to suit the way the team would like to operate including how they collaborate with other teams to deliver outcomes. We have been using Kanban as an approach to plan Operational work for the best part of 2 years, and I would definitely recommend using Kanban with Jira as a way of managing non-BAU work, to give the Operations team, and those relying on Operations, the ability to deliver outcomes and visibility on their active work as well as the backlog.
Start with the Problem: Lean Canvas – you must ask yourself what Problem am I Solving.
Adopting and adapting Agile
This approach, I believe, will also set us up for increased scale, both from a customer and people perspective. We will also continue to manage BAU (incident, Service Requests, Problems, Changes etc) tasks in RemedyForce (you could use other ITSM tools, such as ServiceNow or Cherwell) and Project/Feature Requests in Jira. I am sure there will be plenty more iterations to come.
Use of any methodology comes down to how you adopt and adapt it to your working environment
This approach can be used by other business units, especially those outside of IT such as HR or Finance