Transitioning into a true DevOps culture is not easy. This is especially true in the enterprise space.
That being said: Making the change is almost always worth it.
How do team setups need to change? And why do it in the first place?
Operations and Development, but also the rest of the business need to move closer together. This is easier said than done.
In most businesses IT is organised as a function, but changes in the market have meant that IT now touches every aspect of what most companies do on a daily basis.
DevOps addresses this and is built around the idea that the concepts of Agile methodologies can (and often should) be applied to all aspects of the business.
This in turn enables businesses to react to changes in the market faster and deliver value to their customers quicker.
This value delivery is not unilateral. Quicker delivery enables quicker feedback loops, which in turn reduces risk and creates better products. (whether they are software products or not)
So, do we just create a DevOps team?
This is what lots of companies do. While this isn’t always a bad idea, it can go very wrong.
What you need to make sure is that you are not creating what is effectively a “messenger department”. If you do, you will create a department that is a jack of all trades, but the master of none, and that will constantly blamed for everything. This will slow down your value delivery.
Good DevOps teams are task forces that enable the organisational change required to shorten delivery cycles, enable a culture of sharing, experimentation, and mastery.
Where do we start?
If you are leading a DevOps effort in your company, you want to start with a project (preferably green field) where you can show quick wins.
Constant communication around these quick wins is absolutely key.
While “ground swell” is important to get this done, so is sponsorship from the business.
In this process you and the people around you will learn what DevOps means for your organisation and those priciples can be applied to other efforts in the organisation.
…that many companies take very successfully is to run with a “DevOps studio”. They effectively create a subsidiary that runs with a flat org structure and does DevOps from the ground up.
This gets them around having to break down existing barriers in their organisation and mandates greenfield development. It also gets around a lot of the legacy problems that usually occur in software development.
Moving to cross functional teams
One key change that enables agility – in my opinion – is a move from traditional funcitonal splits (Dev, Test, Ops) in organisations to product-aligned teams.
It makes it easier for people to understand what they are working on and it builds a desire to make the product better.
These cross-functional teams must stretch beyond traditional software development roles as much as possible. (including business roles, database admins, and more)
While this cannot always be achieved, you can still work as virtual teams and enable teams to connect easily.
Again: Sponsorship is important here. People must be able to make the time to work on what is important to the organisation and there needs to be an understanding of what is important to the organisation and why.
Is this the end of Ops?
I have not seen a single organisation where it is. I have seen a couple where it got very close, because eventually a lot of the traditional ops tasks were carried out by cross functional teams.
In the organisations that I am referring to there was very little need for traditional IT tasks, and they were largely software development houses.
In the average business, there will still be many IT tasks (setting up devices, etc.) that need to be carried out inside the traditional Ops organisation.
The transformation needs to take account of that.
Draining the Water-Scrum-Fall
If you build teams that are truly agile and that include experts from around your delivery process, you automatically stop working in a pseudo-agile process model eventually.
Many organisations today let their software development orgs work in sprints and get them to deliver an increment every 2-4 weeks, but what is left along the wayside is the delivery of these increments.
DevOps does not recognise value until it reaches the customer and as such limiting agile to software developers is a DevOps anti pattern.
There is so much more to cover when it comes to the cultural aspect of DevOps…
…but the important thing to remember is that a lot of the details will depend on your organisation.
The other point that I would like to stress is that all the points made in this article are only my opinion.
If you have a different opinion, or would like to discuss things, do not hesitate to reach out.
Explore the rest of the series: