In my previous blog on the minefield that is DevOps I discussed briefly the five foundational CALMS principles which underpin the methodology.
Today, I want to focus on the first of those. C. Culture.
To many, culture is what you get when you listen to highbrow radio shows; to others it’s what you get from a pot of yoghurt. For our intents and purposes however, we’re looking at the work environment and the kind of culture you, as senior managers, need to engender in your DevOps enabled workforce.
Traditionally, the silo-based mentality of many IT departments provides a team of developers a set of objectives: to develop and deliver working code to give the business a competitive advantage. The developers being dutiful employees will go beaver away at their keyboards and deliver a beautiful feat of software engineering which they then attempt to release into the wild.
Operations teams, on the other hand generally have a conflicting agenda. Their objective is to maintain the stability of the production systems with which they are entrusted, and anything that can affect up-time is to be approached with distrust.
Thus, Ops distrusts Development because there is the view that they either don’t bother, or don’t know how, to test code properly, or aren’t around, or can’t be bothered to assist when, inevitably issues are discovered. And Developers get frustrated with Ops because they see them as a permanent road-block to deploying the latest piece of shiny new code and allowing the development team to get on with writing the next release.
DevOps culture is therefore about bringing these two teams together, but the question remains how?
- First, start small – find a product in your portfolio that has development and operations teams that do (sort of) work well together and are keen to accelerate their releases.
- Next, co-locate them. Whilst this is not an absolute requirement, it certainly eases the culture of collaboration in the early days of adoption, and helps them bond better as a cohesive team.
- Empower them – allow them to take decisions on their own as to their priorities. This doesn’t necessarily mean giving them carte blanche to do as they please, but as long as they are broadly in-line with your corporate strategy and their stakeholder’s requirements, let them set their own agenda. This will make them all feel like they have ‘skin in the game’ and make them care more about what they develop and what they release.
- Get them involved with one another – invite the operations team to the developer stand-ups, and vice versa. This helps everyone get a feel for the challenges that each side of the fence faces and can even lead to solutions to issues that are born from a different perspective.
- Finally, don’t let your existing processes become a roadblock to allowing the adoption of this closer working relationship. Ensure that your change management process allows for the rapid deployment of code artefacts without unnecessary layers of approvals, learn to trust your team, just as you’re asking them to trust one another.
Most importantly, don’t assume that by bringing the two teams together you can afford to eliminate roles or reduce headcount. This is a fundamental mistake. In fact, when we start to look at the other DevOps principles you will see situations that will actually require an increase in headcount in order to maximise efficiency.
Next time, we’ll take a look at the ‘A’ in the CALMS principles – Automation. A key technological underpinning of the DevOps ecosystem.
Author:
Mark Edwards, Architect, TESM
