Agile in IT Operations stories: An Infrastructure Cloud Hosting Provider

Agile in IT Operations stories: An Infrastructure Cloud Hosting Provider

By the end of 2016, I joined iWeb as their Agile (Kanban) Coach. My main purpose there, was to help a Cloud Engineers team to get more organized and better structured. Also, help with facilitating/enabling conversations between directors and their teams.

Between October 2016 and May 2017, I played a coaching role for a dedicated co-located team, which main responsibilities were to support cloud hosting systems & applications, and provide cloud hosting tools to developers, to make an abstraction out of the infrastructure layer, in order to keep iWeb customers up and running 24/7.

This team was also in charge of keeping the production environments working, and they were the second level support to issues generated by the development teams too.

How did we deal with context switching ?

At thetl time, only Cloud Engineer’s were dealing directly with customers, systems and network related issues.

Meanwhile, software development teams were in charge of analyzing and developping applications to keep hosting infrastructures evolving.

The CloudEng team dealed with context switching through a kanban system were:

Work related to keeping systems anf platforms up and running was kept always visible.

Impediments to deliver were raised.

Work in progress limits per type of work were established and regularly revised.

Work was classified by type and nature, and swim lanes were designed to help us manage flow.

A dedicated person per week, was responsible of dealing with unplanned work.

Daily stand ups and weekly planning and reviews sessions were there to help the team continuously improving.

How did we keep communication and collaboration between both groups?

We were seating at the same floor, really close physically one to the other, so it was easy to give and take feedback during the development process. The main issue wasn’t at the team level, it was between their managers whom had totally opposite visions in terms of:

Leadership styles.

People management.

Technological choices.

Priorities and the most challenging part, they weren’t able to trust each other.

To remove the barriers created between these opposite views, with the help of the software development teams Product Owners, the cloud Eng Service owner, the collaboration of both managers and the Engineering’s VP, we created a biweekly meeting to discuss priorities across the board, for all teams. We did also a team reorganization exercise, to build bridges between both groups and enforce synergie through inclusion and better communication.

With the help of a kanban board, we made work in progress visible to everyone, tried to limite work in progress by established WIP’s, and helped the leadership team with making informed decisions.

This mechanism worked fine temporarily. At the end, the lack of trust was heavier than our collaboration intentions.

Were we using Agile methods and practices?

Yes! The software development teams were oiled scrum machines and the cloud eng team embraced Kanban practices for at least 6 month and it seemed to be working.

Engineering practices

Both groups were eager to help each other deliver product increments into production. We used pair programming, code reviews and sprint reviews to demonstrate new features/services to stakeholders.

Testing and continuous integration

We tested increments using different environments (development, integration and production), that were automatically updated without human intervention (sometimes manually done). CloudEng Specialists were part of smoke and regression testing sessions when new features were released to production and could potentially lead to production issues that could interrupt the service.

Backlog

We had different backlogs for each team in Jira. Product and Service Owners were responsible of keeping it updated.

Iterations

Software development teams had 2 week iterations.For the cloudEng team, we had 1 week iterations to helps us deal with operational issues and priority shiftings.

Conclusion

As you might have assumed when reading this article, we were using Agile/Lean practices and methodes at thr team level, but the fact that upper management had issues trusting each other, was more than enough to create an unsafe environment, complex to forge innovation and growth.

This is the end of my second Agile in IT Operations story, so thank you for reading it. In my next post, I will share another story about Agile in IT Operations in a finacial organization 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: