Over the last couple of years Leaseweb’s product engineering department has gone through some major changes, and by far the biggest was how our product engineering department has evolved.
In earlier blogs, my colleagues Arnoud and Sander already talked about Maturity models and scaling our engineering department. However, I want to tell you about how, from the perspective of an Ops engineer, our journey went from Ops to DevOps.
When I joined Leaseweb we had an Operation department (HOSD) and a development department (Leaseweb Technologies). Both departments worked closely together on delivering great products to our customers but also sat apart from each other simply because we were two departments sitting at different floors.
So, at some point the teams and our management came to the conclusion we needed to look into improving inter departmental communication and cooperation. Back then (this was in 2015), DevOps was already a big buzzword so we decided to also go for a DevOps approach and the Product engineering department was born (it had a different name back then, but that’s beside the point).
To be honest, in the beginning I was skeptical about the whole DevOps idea, and given that we introduced our Ops teams to working in Scrum teams (which our developers where already doing), the change to the way we are doing our jobs changed quit significantly.
Once we aligned the departments, teams and got necessary preparations done, the “Move” finally began. This sounds more exciting than it actually was btw. We simply moved locations to join our respective dev colleagues and formed a bunch of DevOps teams.
From here on out I will only be talking about the team I joined as the move was actually only that, the move. We were still doing our Ops jobs and our developers were still doing their development work. The only thing that really changed was that we had standups together and when we needed to talk to each other, there was no floor (and stairs) in between our departments anymore.
At this point, it seemed like not much has changed (yet), but around December of that year we concluded that we needed to take another step in our transition and decided it was time to make another change. Our team was split up into three smaller DevOps teams to get more prioritization on our different products.
This was the first real big change, because from that point on we started really to work in an Agile way adopting Scrum ceremonies like sprint planning and refinement.
But we still (at least from my perspective) were not really a DevOps team. We did stand-ups, sprint planning and refinements together but still the Ops guys did their Ops job and our developers did their Dev jobs.
The real change came when the decision was made to train our Dev engineers in more ops work and involve them in our 24/7 on call rotation (EOD).
All of a sudden, we became one team and despite some personal changes, things turned out really well.
Suddenly, there was no we and them anymore. Instead, there was just the team and we really started to work together, recognizing each other’s struggles.
Where for instance the Ops guys had always adapted one way of working, our dev guys came up with really easy and elegant solutions to cut down our spent on Ops work, giving us more focus as a team on improvements. We spent this time on building new features instead of putting out fires and not being able to properly plan our work due to so many unexpected and unplanned workloads.
In the end, we managed to drastically cut back our on-call work (basically working outside office hours) by implementing more automation, creating more documentation and handing work over to our first and second line support teams. However, the biggest impact came because everyone felt responsible for the whole infrastructure from the code to the server, and the whole team wanted to build innovative and amazing products for our customers.
For me personally it was also a big eye opener, because in the beginning I was skeptical and to be honest somewhat against the whole idea, and now I see the benefits of the way we do things. I ultimately went to get my SCRUM Master Certification and help with adapting an Agile way of working where ever I can. I even spent the last 3 months temporarily filling in as a SCRUM Master for our team.
To conclude, in the end we really made a drastic change and although in the beginning it did not look like much, we came a long way making our teams more flexible, and being able to respond to unforeseen changes more quickly.
One last tip I want to share with you all, if you are facing an Ops to DevOps transformation: Dive in headfirst and keep an open mind because in the end the benefits will make the whole process worth it.