This article was initialy published on jesusmendez.ca
2017 has been a year fully dedicated to working with teams within IT operations departments. Nothing new to me, considering that my first steps as an IT professional were with an Application Support Group at cantv.net’s Network Operation Centre (NOC) in Caracas, Venezuela.
Back in the days, between 2001 and 2004, I was part of a dedicated co-located team developing applications to help network specialists provide support and keep Cantv’s customer network running 24/7.
We were responsible for doing everything regarding the apps that supported the NOC’s operations from end to end (from customers need to support once in production) and when a bug arose, we were there to deal with it and get it fixed.
How do we avoid context switching?
At the time, Network Specialists were the ones dealing directly with customers, systems and network-related issues. Support application specialists were in charge of analyzing and developing applications to keep the NOC’s support systems evolving.
Within the Operations Team, they dealt with context switching by prioritizing alerts and incidents depending on their impact the whole network, the type of customer account (VIP or not), the complexity of solving the issue, and SLA’s and OLA’s.
How did we maintain communication and collaboration between both groups?
We were physically really close, so it was easy to get the Network Specialists’ feedback quite soon during the development process. They acted as the support application’s main stakeholders. So we kept feedback flowing both ways as much as possible to reduce issues once in production.
Were we using Agile methods and practices?
Roles and responsibilities
The Support Applications team had someone (the team coordinator) gathering project needs and we (the developers) were responsible for getting them clarified and implemented with the highest quality possible.
The Network Specialists team had a team coordinator (Service Owner) responsible for keeping NOC’s services running, doing his best for guaranteeing Service Level Agreements and Operational Level Agreements signed with internal and external customers.
We used pair programming, code reviews and gang reviews to demonstrate new features to our customers (Network Specialists).
We tested increments using different environments (development and production) that were updated manually. Network Specialists were part of smoke testing sessions and releasing new features to production.
We did not have a common backlog for the whole team, each developer kept his own and shared it with his customers and his team coordinator. Both team coordinators, the Support Applications and the Network Specialists teams got together often to validate improvements and share needs and potential problems to be solved.
We did not timebox iterations, but we negotiated work in progress to balance our limited capacity. The Network Specialists team met regularly to share insights about incidents, bugs and troubleshooting in progress.
So I think we were using Agile practices our way to keep customers delighted and our services under agreed levels and to collaborate to do greater and better things.
This is the end of my first Agile in IT Operations story, so thank you for reading it. In my next post, I will share another story about Agile in Operations in an IT Infrastructure provider context. And please, do not stop here and keep sharing stories. What is your Agile in IT operations story?
Discover our Agile for Operations training course designed to provide relief to these struggling operations teams.