by Scarlett Bayes, Industry Analyst, SDI
My previous blog theorised the ways in which DevOps thinking can impact the service desk, but this got me thinking about how IT departments following a DevOps approach will communicate with other teams and business factions. For this, I wanted to ask some DevOps experts who have experienced this in action; the following responses are from respected industry consultants Kaimar Karu, Rob England, and Cherry Vu.
How can a DevOps mentality be used outside IT?
Kaimar
DevOps, with its original objective, is about collaboration, learning, and improving with the use of modern technology. The whole organisation will benefit from ‘breaking down the silos’ – that is, different teams and departments working together for one common goal, which is co-creation of value for and with the company’s customers.
The practice of ‘throwing things over the wall’ is not unique to IT, it often happens between non-IT teams as well. If those teams can align their efforts for the common goal – and this can only be done through close collaboration – then there will be significantly fewer priority conflicts and significantly less wasted effort.
We also should not forget continual improvement, which again is only possible if the feedback loops between teams and departments are in place, because otherwise, the improvements are at risk of becoming local optimisations instead.
Rob
The principles of DevOps can be used anywhere to improve velocity through quality of any value stream. These are universal: Culture, Automation, Flow/Lean, Measurement/Feedback, Sharing.
Or the three ways: Flow, Feedback, Continual Improvement and Learning. (I think there should have been a fourth way: Shift Left).
Cherry
Teal Unicorn is consulting for a big garment company in Vietnam to build a happy business model. We use almost all of the DevOps principles except Automation. In this model we emphasise culture change to build trust and create a learning and sharing culture.
How do teams following a DevOps methodology communicate with other business factions which may not be as agile?
Kaimar
If we rephrase the question as “following the DevOps philosophy”, and remove any reliance on technology from the equation, then the answer becomes quite clear. In the context of the organisation, having only one part of the value chain / delivery model running very fast delivers little value. The whole organisation can move forward at the pace of the slowest part of the organisation. It is important to understand what the realistic speed for the organisation is, and what levers can be put in place to increase the speed, if that’s something the organisation will benefit from. If the product teams make an effort to understand how other teams and departments work, why they work that way, and what their challenges are, it makes it a lot easier for them to start speaking the same language.
Rob
The bimodal approach is toxic to a culture and should only be a transitional state as we work to converge on a new way of working for the organisation (and ultimately its suppliers too, where we can). While we are in that bimodal state it presents difficulties. It is trying to change one gear in a gearbox. We need a layer of management to buffer or underwrite the agile ways of working, to interface them to the pre-agile organisation, to run interference and create whitespace, to uncouple the gear from the gearbox.
The cadence of other teams is what it is and we simply have to accommodate that, but if work is being passed back and forward it greatly limits our agility. We need to negotiate faster paths where we can, preferably by removing the dependency. On a more positive note, a team demonstrating new ways of working creates a proof-point which generates pull for change in the other areas of the organisation. We can disrupt their thinking and introduce them to new ways simply by communicating face to face. Turn up and talk.
Cherry
When it comes to communicating with non-agile teams, I’d like to cite Bruce Lee’s quote: “Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way around or through it”.
What kind of skills and attributes are necessary of a team member for a DevOps approach to be successful?
Kaimar
For DevOps to get embedded in the organisation as *the* philosophy to follow, there is a lot more work to be done with the environment in the organisation, compared to focusing on individuals. DevOps requires the freedom to make mistakes and learn from them, which is something often shunned in organisations. It is not about being careless, but about accepting that not everything can be planned ahead in detail, and not everything can be controlled. The role of managers is changing – from an order-giver to an enabler. With more clarity about the organisation’s objectives and more support from those in a position to remove obstacles, people will have a much better environment to work together in. From the individual’s point of view, I believe it is important to keep an open mind about what could work, and to avoid the temptation of the ‘us and them’ mentality.
Rob
Nothing is necessary. Any group of people can improve themselves. DevOps is a way of improving, not an end state, so success in DevOps is seeing an improvement in results.
Cherry
I would say the ability to learn to TRUST others.
It’s interesting to see differences as well as commonalities between each expert’s responses, but the main themes and teaching of DevOps are consistently evident; collaboration, continual improvement, and increasing the throughput of work.
To end, I want to pass this over to you: how would you answer each of these questions?
