Don’t put DevOps into your IT teams
Last year I was delivering DevOps Foundation training for an organisation that has worked hard to introduce DevOps and Agile concepts and behaviour into their IT teams. They have trained everyone in their IT empire in concepts like the Three ways, continuous release and those staff understand and believe the concepts will help them generate and deliver better services. But somehow this hadn’t (yet) quite brought the revolution they had hoped for though, and they asked me if I thought there was any element missing.
What I felt they had missed out was in thinking this was an IT thing they were doing. They understood the need for IT to have new skills and attitudes but hadn’t seen how other parts of the organisation needed to be an active and involved part of the revolution. At the very least, other parts of the company needed to understand what different expectations they should have in their interactions with IT. Asked for examples, I offered them two which I have set out here.
Example 1. Releasing updates
Previously service updates came out quarterly, with a range of corrections and improvements bundled together in a traditional release. This update was therefore very visible to the customers and users in the operational parts of the organisation. The updated service would offer noticeable differences, and also some noticeable changes in usage – often associated with operational changes too. With continuous release and a goal of continuous deployment, this will impact the customers in a very different fashion.
Continuous deployment means their services change most days, but to a barley noticeable degree. This is exactly what they are used to with the apps on their smartphones, but it isn’t what they are used to at work. If they aren’t made aware of the new approach, and the benefits that offers them, then it seems like IT is no longer working on improving the services. There are, however, some simple ways to explain it – and to illustrate the benefits.
Like watching your kids grow up
When your children get up in the morning, they look just the same as the did the night before – and that’s how we – as parents – see their development. It isn’t noticeable through the tiny daily changes. But when grandparents or aunts & uncles visit, their first words are usually ‘My, how you’ve grown’. Parents are in the continuous deployment situation, the others, in bundled release mode.
Getting our customers on board with the beneficial consequences of agile and DevOps means moving them from grandparent role to parent style perception. And it helps greatly if this conversion in attitude is worked on before the change in actual delivery happens. In fact, it can be used as a positive advantage and advancement in service quality. Most especially it should increase the value added by IT’s ongoing efforts on improvement.
More added value
When improvements are released they increase the value delivered to the customers. In traditional release approaches, this value arrives in large blocks each time a release is made. With continuous deployment, improvements are released as soon as they are created, and the value from those improvements is released that way too.
The image illustrates that. The blue blocks show the value from traditional release, the red areas show the extra value received by the customers from continual deployment. Clearly, this is good news for the customers, but they are not likely to appreciate or even to utilise it all if they aren’t aware of how things are nowadays. And making them part of this revolution in release is the best way to ensure they understand, utilise and even to positively influence the new approach.
(You can explain this picture quite well via the concepts of differential and integral calculus, but my experience is this doesn’t always work with most audiences. If you happen to be supporting research scientists though, give it a try.)
Less training, more innate understanding
Frequent deployment also makes user training is much less likely to happen, with changes being intuitive rather than needing formal instructions on how to use them. That’s a big topic in itself, one we can visit in a future blog.
Example 2. HR involvement
In large organisations, the traditional approach of HR is to fill vacancies with a match to previous (successful) post holders. That works if the approach and culture of the organisation is static. With a move to DevOps culture, HR needs to be involved to understand – and then deliver on – the new priorities for IT staff. The absolute priority for deep technical knowledge will be replaced, in the DevOps environment, by an enthusiasm and capability to be in self-organising teams, share goals with others and collaborate across boundaries. So, a different kind of person is needed. Involve HR as early as possible, offer awareness sessions so they appreciate the new demands and requirements, generate an attitude of partners in a new innovative and exciting approach. Without HR understanding they will continue as before, generating the possibility of conflict rather than cooperation. With HR as part of the revolution from the outset, success is more likely, and conflict between IT and HR less likely.
DevOps cultures recognise that an IT supplier – internal or external – cannot really be successful if their customer is not. Seeing the organisation as a single (albeit complicated) entity and involving all those who will benefit will increase the chances of success for the kind of organisational change that new approaches like DevOps and Agile represent. Quite simply, they are not ‘IT things’, they are organisational things, and failing to see that will lead to more conflict and less benefit.
Blog cover by Prasanna
Subscribe for blog updates
Thank you for subscribing!
OOPS! something went wrong try after sometime