Author: Lorraine Pauls Longhurst Published: LPLSC Blog Date: 14 Nov 2011
Discusses key learning from issues encountered as an Agile Project Manager/Coach working with IT Operations
Dev Ops in Government - Why Ownership by IT Operations is required
One of the most frustrating parts of my recent Project Manager/Agile Coaching role at a government organisation was working with IT Operations. There were a number of strategies I tried to improve this relationship and at the time I didn't realize this was what is now commonly referred to as DevOps.
The web-based application that we deployed was suffering from performance issues due to the server configuration not being optimised for the scale of users accessing it. We were also releasing the software to production quite frequently which required additional support from their team.
We needed help from IT Operations to solve these issues. At first I thought that IT Operations worked a little like a consultant. I knew our team paid a large amount to that team to setup the infrastructure and I thought it was their role to ensure it worked as we expected.
Whereas IT Operations saw our application as 'one of many' and they felt their role was to keep systems up and running - not to optimize servers to ensure performance was improved OR to support frequent production releases.
The first thing I tried was to use our relationship with the team (some of the guys on my team were good mates with the IT Ops guys) to try to get their help. What I quickly realized was that IT Ops were doing their best but they just didn't have the time or resources to focus on our performance issues. They treated our application as just another system, and didn’t differentiate it because they had no understanding of its individual requirements. This was a symptom of IT Operations not being part of the team making decisions from the beginning.
So the second thing I did was to bring in a consultant to help us out. I asked them to analyse the environments and determine where the issues were and make recommendations to improve it. This failed miserably. The consultants made recommendations but no-one had the time or interest to implement them.
In the end, we had to raise the issue high up in the organisation to get IT Operations to make this their priority. It was very difficult and it definitely affected our relationship with their team in a negative way.
Key Learning: IT Operations must feel ownership in your application!
What we did wrong was not to include IT Operations from the beginning. Because of this, they didn't fully understand what the application was being used for and therefore what kind of infrastructure made the most sense. They were blaming our team (and people who had left the team) for not specifying the right infrastructure in the first place.
Going forward we had to setup regular meetings with IT Operations where we reviewed hardware related issues. Our project helped to fund one person from their team that owned our application. Their role was to support frequent production updates and not just to ensure it the system was up and running, but that it was performing as expected.
We also asked that they setup documented templates of their various hardware configurations to help us to work together in the future to understand what options were available.
