Agile in IT Operations stories: A Network Operation Center
2017 has been a year fully dedicated to work with teams within IT operations departments. Nothing new to me, considering that my first steps as an IT professional, where at the Support Applications group at cantv.net’s Network Operation Center, 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.net customer network’s up and running 24/7.
We were responsible of doing everything regarding the apps that supported the NOC operations from end to end (from customer need to support once in production) and when a bug arised, we were there to deal with and it and get it fixed.
How do we avoid context switching ?
At the time, Network specialists were the onces dealing directly with customers, systems and network related issues. Support applications specialists were in charge of analyzing and developping applications to keep NOC’s support systems evolving.
Within the operations team, they dealt with context switching by prioritizing alerts and incidents depending on their impact over 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 keep communication and collaboration on between both groups?
We were really closed physically, so it was easy to get Network Specialists feedback quite soon during the development process. They acted as Support Application’s main stakeholder. So feedback both ways as much as possible, to reduce issues omce 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 us (the developers) were responsibles of getting them clarified and implementend with the highest quality possible.
The Networt Specialists team had a team coordinator (Service Owner) responsible of keeping NOC’s services up and running, doing its best for guaranteeing Service Level Agreements and Operation Level Agreements signed with internal and external customers.
We used pair programming, code reviews and gang reviews to demonstrate new features to customers (Network Specialists).
We tested increments using different environments (development and production), that were manually updated. Network Specialists were part of smoke testing sessions and new features releases to production changes.
We didn’t have a common backlog for the whole team, each developper kept its own and share it with it customers and its team coordinator. Both teams coordinators, the Support Applications and the Network Specialists team got together often to validate improvements and share needs and potential problems to be solved.
We didn’t use time boxed iterations but we negotiated work in progress to balance out our limited capacity. The Network Specialists team gathered together regularly to share insigths about incidents, bugs and troubleshooting in progress.
So in conclusion, I think we were using Agile practices in our way to keep customers deligthed, our services under agreed levels and collaborate to do things better and greater.
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 within an IT Infrastructure provider context.
So please, don’t stop there and keep sharing stories.
What is your Agile In IT operations story?
In the mean time, take a look to some related resources that could enhance and elevate your Agile tails:
- The Secret sauce of a team-outer, http://www.jesusmendez.ca/the-secret-sauce-of-a-team-outer/
- Connecting team strategic planning agile organizations, http://www.jesusmendez.ca/connecting-team-strategic-planning-agile-organizations/
- Forming Agile Teams (All in one), http://www.jesusmendez.ca/product/forming-agile-teams-all-in-one/