The DevOps journey

I have been working for several years with different customers looking to transform their digital strategy and adopt the correct DevOps mindset. If you ask me what is the single one thing that stands out, I would say that just like anything else worthwhile, it is not about the end-goal but it is about the whole journey, Your DevOps journey.

There are a lot of companies these days trying to adopt the DevOps methodology and we are seeing more and more job posting for “DevOps Engineers” or “Site Reliability Engineers” with job descriptions that allude to one single thing and that is “Automate all the things”. But from my experience, many organizations while having these positions in-place are still struggling to adopt the correct DevOps mindset, and this is not due to any lack of automation and qualified engineers, but because they started their DevOps journey at the wrong place.

As Donovan Brown states – “DevOps is the union of People, Process, and Products to enable continuous delivery of value to our end users”. Many of us are familiar with this definition or different iterations of it but we take the people and process part for granted and in my experience that is where a successful DevOps journey should always start from.

At the Microsoft Business Group (aka New Signature), whenever we approach a customer for a DevOps project, instead of selling them on fancy pipelines or automated testing, we highly recommend starting with our DevOps Assessment engagement. During this 5 to 10 day engagement, we try and talk to everyone across the organization and try and get their feedback on how their day-to-day job looks, what excites them most about their workplace and if they feel like they are adding or giving value to their end users. This engagement gives us and the organization a great insight into where the org is on their DevOps journey from every perspective.
Some of the common key findings we usually get are:

• Teams operating in silos. Infrastrucutre team not sure what the development team is doing until a request ticket comes in.
• Not enough time or bandwidth to enable engineers to test out new items or to develop new skills.
• Always operating in a “Where is the fire?” mode, hindering the development team’s ability to actually provide new and innovate solutions to their customers.
• The technology side of the business not being included in the business decisions and just following requests that come down the pipeline.

Now when you take a look at some of these very common concerns we usually see, can you tell me what DevOps tool might help them here?. No, there is no tool that can help here and this where is we emphasize that the People and Process part is as important (if not more) than the tools/product side.

I am in no way stating that the right tooling is not important. Most of these engagement actually do end up with us doing a DevOps jumpstart engagement with our customers, where after we have outlined all the risks to the organization from a digital transformation perspective, we start down the path of “sustainable change” to adopt DevOps practices. From moving source code to source control, automated build pipelines to a full Code commit to Production Infrastructure. We have amazing testimonials from several customers who loved this approach and saw actual value in this. These engagements also been a catalyst for many of our customers to zoom ahead on their DevOps journey.

If you found this interesting and would like to hear more, please reach out to us. Below is our marketing material and here is the link to our offering.