Kanban & Digital Operations
Before I joined Spark Ventures I had always been frustrated with the planning (or lack thereof) of non BAU work. Basically anything that fell outside of Incident, Problem & Change that was usually captured in a Service Management 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 resource to complete. 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 analyst/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 or designing a 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 does not become a blocker for Software Development?
- How can we track time spent in order to capitalise the teams time?
- How can we share with the rest of operations what we are working?
- Demonstrating the value of Operations
- Reduce shoulder tapping of Operational resources?
How did work get into Digital Operations?
To begin with, we classified work in to 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 in to smaller tasks and to 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 work load and closer collaboration with the Development team sprints where Operations is not seen as a blocker. We run 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 has definitely 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 was 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 period of time to complete work. 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. 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, and 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…..give it a go and then help others by writing a comment below..