A while ago I was talking with colleagues from work about what we believed was key to the success of introducing a DevOps culture into a team and organisation and why the title ‘DevOps Engineer’ is potentially confusing and harmful in any organisation.
I am in no way a DevOps expert. I simply learn what I can from others and share what I know, hoping it helps someone, somewhere. Here is what I think about DevOps, feel free to comment or give feedback, whether you agree with me or not, all input is welcome.
My problem with ‘DevOps’
I feel that One of the biggest problems about DevOps these days, like so many other things, is the name. DevOps is a compound of Development and Operations. The issue with this name is that people often think you therefore must be either a developer or an operator to be involved in ‘DevOps’. This misunderstanding is what immediately lead to the rise of things like SecOps because now Security need to be involved, then we have DevSecOps because we should all be working together, right? Let’s not discuss WinOps, LinOps, WinLinOps, DevSecWinLinMobEngOps…
The opsification of every person’s role title just causes more segregation and confusion, getting us further away from what DevOps was supposed to help us achieve.
Who is DevOps really for?
DevOps is for the *makers* and the *supporters* of something, every single person within your organisation will be one of those two, however indirectly.
DevOps is about ensuring the product, or thing, being made is to the highest standard and functioning correctly, with a focus on learning from failure and continual improvement. Yet there are still too many people talking about technologies, languages, frameworks, and pipelines; Almost immediately excluding a great many people from becoming part of your DevOps journey.
For me it simply comes down to three main things but with an important common theme linking them, consistency; Communication, Collaboration, and Trust, for me are the basic building blocks of a DevOps culture. Consistency underpins the lot and is a fundamental part of DevOps as once you have a consistent point to start from, you can make measurable improvements with greater confidence.
It seems pretty obvious but if you don’t communicate with each other you are never going to get anywhere significant.
You attitude, team, and environment all need to promote safe and respectful communication. Just try to ensure that your team is protected from excessive disruption from the outside world – communication is important but it still needs to be relevant and add value.
– Do team members feel safe and able to communicate with each other?
– Are they only talking between teams when they want something?
– Is the way of working promoting the value of discussion?
– A standup is a good way to get team members talking and find value early on. Just make sure it goes beyond these short ceremonies.
– Are you current technology choices helping with efficient and effective communication?
– Technology can be of great help with communication, just make sure that it is working for you and not the other way around.
Consistent communication is about building and maintaining effective relationships in and across teams. Communication needs to be near instant and always mutually respectful. Just make sure you’re not only talking to people when you want something, build a relationship that works for and benefits everyone involved.
Continuous and consistent communication is certainly the first step and, just like the rest, requires constant review and attention.
Once you have built effective paths of communication with people, you’ll hopefully start wanting to actually work together. Collaboration is key to successful DevOps. By always having the attitude of ‘one team’ you will be less likely to throw problems and issues at each other but instead work as a single unit to tackle and resolve problems; hopefully learning from and sharing the experience.
Team members need to know that collaborating and asking for help are not bad nor will they look bad on the person. There is nothing wrong with working as a team, talking problems together. Personally I encourage group working to achieve a higher state of quality compared to lone working, it also seems to be at great way to quickly strengthen a teams’ combined knowledge.
– Are all team members able to work with one another?
– Is working *together* actively encouraged?
– Do the facilities allow for it (remote or local working), is there desk space, etc?
– Are you thinking of collaborative working when planning and sizing work?
– If every person on a team has only enough time to do their own work, collaboration will never happen.
– The work should be dealt with by a ‘team’ not a team member.
– Are you current technology choices helping with efficient and effective collaboration?
– Can teams share desktops, workspaces, video?
– Can people sit next to each other and pair program?
– Do you have breakout areas of dynamic working of problem/task based teams?
Consistent collaboration means that team members will get used to how each other works and productivity will increase. Try not to see collaboration as a way to increase velocity directly, it is more about quality and team health.
Trust is earned and can’t be rushed or forced. Trust within the team comes from communicating and collaborating, regularly and consistently.
By consistently interacting and working together, we build trust in one another’s way of working and capabilities. By consistently delivering quality, we use DevOps to build trust in the development, release, and operation of our product.
Consistent trust in teams and team members provides us with a delivery benchmark that can be used to effectively size and forecast work: Trust takes significant effort to build but can be lost very quickly.
With consistency, communication, collaboration, and trust all being so important to DevOps, it is critical that each is continuously monitored and discussed with the team(s) to ensure the culture is receiving the same level of attention as the product being built with it.
DevOps is not new. DevOps is not a thing you buy, hold, or show off at parties. It is a culture focussed around consistency and quality. A culture that sees failure as an opportunity to be better; preferring collaboration as a collective and not commendation as an individual.
Look around your team, look around your organisation, speak to people about the things they do day-to-day. Do you hear or read anything that you feel could be better? Is there a process that could be made better or even just easier. Perhaps by educating someone, or improving the process itself, maybe you can help them automate that process making sure it is carried out exactly the right way, every time?
By communicating, collaborating, and trusting one another, we can start to fix problems far easier and with far greater impact.