Implementing DevOps – What Did I Miss?

Prashant Arora Blog DevOps ITIL ITSM

DevOps! a new buzzword, marketing hype or a real force for Change?

Well, looking at the increasing adoption rate at various SMBs and large organizations, it looks like DevOps brings the solution for never ending debate between stability versus responsiveness thus most of the organizations either started the exercise or have a roadmap created for DevOps implementation.

Your organization may be one of those early movers who have started this practice to break down the silos between development and operations. While this paradigm shift is towards DevOps, there could be few things which may fall between the cracks and you may be wondering what did I miss?

PS, If you are still at the stage of creating roadmap for DevOps implementation, check out these 7 ways to get you started onA Rise of Beyond Conventional ITSM’.

Here are a few things you must keep in mind while implementing DevOps:

Organizational Change Management

Believe it or not, DevOps is more than new tools, technology and skills. It requires a change in mindset which is totally dependent on the people and culture. No matter what automation tools you are using and how effective your processes are, missing this piece can hit your overall success.

While development teams are all about responsiveness and faster innovations, operations teams are more concerned about stability. These contradictory mindsets need to be managed carefully in order to introduce DevOps philosophy. So do not miss to include organizational change management in your DevOps planning and it must be supported by a strong leadership buy-in.

The culture should not be responsiveness vs. stability but responsiveness with stability!

Define an end date for the DevOps team

If you are on your way to implement DevOps, most likely you would have a dedicated team to help penetrate this philosophy to development and operations. It is OK to build a DevOps team (internally or externally) to assist people with practices, tools and metrics at the starting stage. But at the same time it is also necessary to ensure that this team does not stay there for a longer period. You must define their end date else your DevOps initiative may end up being just another project with the DevOps team being the PMO.

The idea should be, set up a team to get the DevOps initiated, transform the capabilities and let this team move on to the next application or service leaving the DevOps mindset all around. People should recognize it as BAU. To have the real value creation, it is very important to have this philosophy embedded into people’s DNA.

What is the risk of not scoping out the DevOps team?
Well, you have created a DevOps team to break down two silos (development and operations) now what is the guarantee that this ‘another team’ (DevOps team which you have created) will not become another silo few months later?

Consider outsourcing of automation

Your DevOps journey is going good so far and business has already started recognizing the positive effect of this change. Is that a time to sit back and enjoy the journey? Of course yes, but wait a minute! You could achieve even more!

The newly introduced tools your operations and development teams are using for automated testing, deployment and monitoring can be great but if people are spending too much time with these tools, it is not a good sign. If your teams are taking too much time to provision production-like systems then this is actually defeating the purpose of DevOps. Remember, DevOps is all about improving the time to market with same or better quality.

Consider outsourcing of these automation related work. With that your teams can actually focus more on innovation, faster delivery and customer feedback, rather worrying about the infrastructure readiness. You don’t have to be skilled on these tools and at the same time you can leverage the best available tools in the market because your outsourcing partner will be taking care of all that. Yes, I am referring to New Relic, BMC Petrol, Chef, Puppet, Qualitia, GitHub etc.

Define the ‘right’ metrics

Like any other initiative, you may have few measurements and metrics in place to assess the effectiveness of DevOps. While goal can be better business agility, increased uptime or improved customer satisfaction, you should not miss the right set of metrics for both development and operations teams.

You may be incentivizing the development teams for rapid delivery and shortest backlog but tweaking the criteria a bit will change the way people think and act. Make it ‘rapid delivery and shortest backlog with less downtime’ and see the difference. Similarly, for operations, change your metrics byless downtime with more number of deployments’.

Also, so far you may be capturing ‘L4 Reach Out’ in your metrics but it’s time to track theOps Reach Outtoo. Measuring how many times development team has reached out to operations for some assistance or problem solving will give you a sense of real collaboration.

Share your experiences with any other things which were missed in your journey to DevOps.