The previous blog describes step 3 of the roadmap towards delivering software solutions better and faster. This blog will deep dive into step 4: bringing Dev and Ops together
The benefits of taking down the barrier between Dev and Ops have been researched by many companies. Most of them report improvements on typical support KPI’s like mean time to detection, mean time to recovery, deployment frequency, defect rates, average response times, etc. But also, a shorter time between inception and go live of an enhancement. Typically called something like time to market, time to value, or simply lead time.
In order to truly bring Dev and Ops together, there are a few final challenges to overcome:
- Bringing the people together
- Bringing the work together
- Bringing the money together
Bringing the people together from an organizational perspective is not that hard. We do that all the time in projects as well. The main challenge in this step is the behavioural difference. Project people are a different breed than support people. Some organizations get lucky and have people who are just proud of the product they work on. They don’t care if they do root cause analysis on a bug in production or build a piece of new functionality. If you’re not so lucky and encounter cultural differences between the teams, it’s important to not just ‘throw’ them together in one team. This calls for proper organizational change management to ensure a smooth integration of the two teams. Use the broad palette of team building, product branding, purpose finding, visioning and other methods and tools out there to bring the teams together in one ingroup.
The second challenge is to integrate the work lists of the Dev and Ops people. If they need to work together, they should be looking at the same list to plan their work. This can be achieved by treating tickets from the Ops team and backlog items from the Dev team as one and the same. Both are essentially work items: something that needs to be done. Having one tool that brings them both together allows the team to manage all their work in one tool. If your ticketing system is in a different tool than your scrum backlog and moving to one tool is politically not feasible, an interface between the two will need to be developed.
Bringing the money together implies one budget for the product and its DevOps team. Instead of separately charging for support, hardware, licenses, enhancements and projects, the stakeholders should be charged for use of the product. The best way to achieve this is to draw a parallel between SaaS solutions that are bought off the shelf and your own product. SaaS solutions are usually charged per user or per node. That charge covers everything from the helpdesk and the hardware to new features that are rolled out regularly. In essence, this is identical to what your DevOps team is doing. The only difference is that your DevOps folks are in your own organization and the SaaS solution is usually delivered by a third party. From a budgeting perspective, they can be treated the same.
If all went well, you are ready to deliver your IT solutions faster and with a higher quality. This will also lead to more satisfied end users and stakeholders and increased trust from senior leadership in the ability of your technology folks to deliver on their promises.
As mentioned before, there will be impediments to overcome and moments of despair to suffer through. But we hope that this conclusion will motivate you to continue on the journey. The rewards are worth it!
This is the last part of the serie of blogs ” Delivering software solutions better and faster ”
Featured image thanks to Mohamed Hassan from Pixabay