I work at IGS Energy in Dublin, Ohio. My team and I are responsible for Information Security, Network Engineering, Systems Administration, Telecommunications and Technology Support. We work in a fast-paced environment with frequently changing priorities and deadlines. A few weeks ago, I set a goal to improve and streamline our project communication/collaboration.
We work in a department comprised of several agile development teams. From the moment I started at IGS, I was very impressed with the open and transparent communication involved with running an agile team. In the back of my mind, I always wondered if I could make that work for the Infrastructure & Security teams at IGS. Our team already held daily stand up meetings and worked very closely with the development groups. Could we take it a step further?
We ended up attempting to leverage agile for an Infrastructure-related project. The goal of the project was to replace the portion of our network that is leveraged by our end-users. Unfortunately, we struggled to leverage agile for this project. We found that the work didn’t always fit into standard delivery time slots and often had to be delivered continuously due to inconsistent maintenance windows, etc. We also found that we had to frequently change the schedule to allow us to occasionally focus on daily maintenance and keeping the lights on. Finally, we noticed that attempting iterative delivery of this specific infrastructure project was actually hindering the user experience and negatively impacting the goals of the project.
We ended up trying other methods of project delivery and communication. Everything from sending email status updates to holding individual project meetings. We even tried using Microsoft Teams to document status updates. These solutions were good but we wanted something great.
We really just needed a few things:
- Open/transparent communication
- Continuous delivery
- Clearly articulated priorities
I ended up asking friends and colleagues for advice. I reached out to App Dev Managers, Business Analysts, Infrastructure Leaders and even our VP of IT. I ended up getting some great advice that lead me to the Kanban Methodology. I ended up doing some research and found that several Infrastructure & Operations teams had successfully implemented this form of project flow.
I ended up deciding that it’s worthwhile for us to test out Kanban and see if it works for us. At that point, we had to make a few decisions. Should we have a physical or virtual Kanban board? It made a lot of sense for us to use a virtual board but we still had to decide what product to use. Our organization already had subscriptions to Jira and Office 365 which both offered tools for virtual Kanban boards. However, a member of the team was already using Meistertask and after exploring the UI, we decided to give that a shot.
We ended up starting out with 5 categories:
- Backlog – Tasks that haven’t been assigned. I was given some great advice to purge items from this category if they remain dormant for an extended period of time. If they’re dormant for that long, clearly they aren’t a priority. An extended backlog of tasks that are never prioritized could turn the board into a source of anxiety.
- Hold/Blocked – Tasks that have been assigned but can’t be completed at this time. This could be as simple as a task being contingent on the completion of another task.
- Work In Process (WIP) – Active tasks. Our goal is to limit the amount of WIP to items that can be focused on at that point in time.
- Validate – Tasks that are being tested.
- Complete – Completed tasks. It’s important that we take time to recognize these items and celebrate success.
After discussing this with the team, there were a few questions that ended up causing us to make a few adjustments to the process. For example, he team already receives a high volume of requests/tasks through ServiceNow. Should all of those flow through Kanban as well? We made the decision that only items that will take more than 3 business days will be added to the Kanban board.
The team also discussed who could actually create items for the Kanban board. It’s important that we had a clear sense of priorities and didn’t introduce too many cooks in the kitchen. We decided to add an extra category for “brainstorming”. This is an area that anyone on the team can add an item to. During our weekly project review meeting, we will discuss all open brainstorming tasks and decide whether or not they are added to the backlog.
We plan on communicating the status of our tasks during Daily Stand Up Meetings, Weekly Status Meetings, and a Monthly Retro. During our retro, we will review what went well, what we could have done better and what our next steps are. We will also hold retros for any unplanned downtime.
I’m looking forward to seeing how this works out. Have you implemented Kanban for an Infrastructure or Operations team? If so, let me know how it went!