DevOps is a way of building and maintaining systems that, at it’s best, makes IT changes seamless and simple.  It’s also a term that gets used by people to mean lots of different things.  For the sake of clarity I like the following definition from Wikipedia:

DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

The key aspects are are that DevOps is a culture, movement or practice.  And that, at heart, it is about collaboration and communication.  And automation.  Recently Paul Hicks wrote a couple of articles on “what does DevOps really mean?” (see here and here).  His articles got me thinking about the ways people try to implement DevOps that fail; and how to avoid making those mistakes.  So here are my top 3 DevOps fails and how to avoid them.  His third article in the series is pending, I’ll link to it when it’s up.

It’s something that IT does.

Many IT practitioners fear executives going to conferences and hearing about things such as DevOps then coming back and saying: “IT go and do DevOps.”  Yes, primarily the initial changes required are in the way the IT teams work together.  One of the huge benefits of DevOps is the breaking down of silos in the organisation.  This includes the silo between IT and “The Business”.

For example IT delivery doesn’t happen without money being allocated to it.  But the way many organisations allocate money can undermine the ability to implement DevOps well.  Annual money grabs for the CAPEX to do IT projects (as I’ve seen in many government departments) are not especially conducive to ongoing incremental improvement and maintenance of a product or set of products. Designating some activities; say writing new code as CAPEX; and other activities; say fixing bugs in existing production code as OPEX; can often reinforce the functional IT silos that exist thus impacting collaboration and communication.

How allocation of funds is performed is just one of the many potential organisational areas that could, and probably should, change.  Governance over IT.  Enterprise Portfolio Management.  IT Programme and Project methodologies, structures and implementation.  HR policies and guidelines.  Recruitment practices.  All of these things and more can change in ways that make DevOps transformation more likely to succeed.

Sadly, IT people often reinforce the silo between IT and business.  Even the definition above reinforces it; by stating that it’s about collaboration and communication between IT professionals.

Patterns to avoid this mistakes

1. Acknowledge that the silo between IT and the business exists.  Often this is overlooked and just assumed.  Actively use a DevOps transformation to try to break this silo down.  The goal is for both parties to draw closer together.  To collaborate and communicate together.  It’s almost a truism to say that every company is a software company these days.  The reality is that IT; insourced or outsourced; only exists to enable business outcomes.  The closer you can connect IT to those business outcomes and the people who manage and deliver them, the better for all concerned.

2.  Accept that any transformation of IT is likely to have flow on impacts to other areas and be ready to make changes there too.  This is really a call to organisational leaders: to the Chief Executive; the CFO; the HR Director; the General Managers.  To make the most of the shift to DevOps you are likely to be required to lead changes in your area.  Be open to them.  If you’re unsure get good coaching.  Take the opportunity to learn and grow.

3. Realise that deciding to move to DevOps is deciding to change your organisational (not just IT) culture.  Embrace this and seek advice on how to implement incremental, evolutionary culture change.

It’s a tool you can buy

I was doing a current state assessment at a large public sector organisation.  In that I talked with one of the technical managers.  I was asking a bunch of questions trying to get to the heart of whether or not they were ready to move closer to the developers. Basically every question I asked about DevOps the answers was; “we’re already doing that because we’ve bought and implemented X and Y tools.”

When I talked about closer communication and collaboration with developers they said things that suggested a deep and rather bitter divide between the two.  But they were doing DevOps because they were using the tools.

Furthermore I have heard and read information from tool vendors that suggests that if you only buy this tool you’ll be ‘full devops’.

I don’t want to downplay the importance of technology to moving to DevOps; it is necessary, but not sufficient.



How to avoid this mistake

You know about it now.  Don’t be sucked in by a slick sales pitch.  Tools are vital; but you need to address culture before (or at least as) you implement tools.  Tools will not change culture.  In the example I cited above the tools seemed to be doing more to widen the cultural gulf between the teams.

You need to be proactive about the cultural change.  It needs to be led; in the spirit of DevOps; collaboratively and with clear communication.  It’s also important to note that you can’t engineer the outcome and do it all at once.  The most embedded cultural change is more evolutionary than revolutionary.

Skilled change / transformation management and coaching can be vital here.  It can cost, but the RoI you get from the lasting cultural change should more than cover it.

Creating a DevOps team

Paul talks about this in his first “what does DevOps really mean” blog.

A core value in DevOps is to employ the entire organisation to concieve, design, develop, release and maintain valueable software. (emphasis added)

If you create separate DevOps team you are, to be blunt, doing it wrong.  In fact you that team up to fail.  You are simply creating another functional silo.  Worse, not only are you setting them up to fail you are creating a group of scapegoats to blame that failure on.  After all if DevOps implementation fails then surely the DevOps team is responsible.  The same scapegoat problem can happen where you create “DevOps” job titles as well.

How to avoid this mistake

1.  Knowledge is power.  Now that you know about it; don’t do it.  DevOps is something that all people involved in the delivery lifecycle (business and IT) should be being and doing.  Not something a separate team does to the rest of the organisation.

2.  As well as avoiding creating DevOps teams I’d avoid creating specific DevOps roles too.  If you have a group of people called DevOps engineers then surely this DevOps thing is their responsibility right? Names, titles, structures are important.  They can create or break down siloes.  Put DevOps in the job description by all means.  But I wouldn’t put it in the job title.  Personally I’d call all the people involved in the actual building of a product Technical Analysts / Engineers / or something similar.  Whether their main focus is defining business need, designing and writing code, testing, deploying etc; ideally you want T-Shaped people; so they can move between things as required.  This is one of the ways HR can change to accommodate a move to DevOps.

In conclusion

Shifting to DevOps can provide powerful strategic and competitive advantage to an organisation.  Any organisation can embark on the journey; and any organisation can be successful in that journey.  Hopefully by pointing out some common snares along the way the journey may be a little simpler for you.

Also, I’m interested to hear about other DevOps fails and how to avoid them.  Comment if you’re interested.


This post was originally published on LinkedIn