There seems to be a growing misinterpretation of DevOps. When we hear the word DevOps, the first thing that comes to our mind is automation; continuous deployment, continuous build, and associated toolsets or we think of development and operations teams sitting together. Even when we search DevOps in google, you can get results such as How to become a full-stack engineer in 6 months or how to implement Jenkins, cucumber or crucible, etc. Sometimes it’s represented as a separate team in the engineering organization. Whereas DevOps is all about breaking down Silos to the full cycle of delivering value to customers. DevOps is a culture that requires some practices and a new vision, its common goal is unifying people and organizations around unique goals. Some of the thought leaders of DevOps have coined the term CALMS for DevOps;
C – Culture
A – Automation
L – Lean (flow, Systems thinking)
M – Measurement (measuring systems)
S – Sharing.
For me, It gives a nice representation of all DevOps encompasses. DevOps is about culture; it is also about end to end flow with systems thinking mindset; it is also about the automation of work end to end; figuring out effective ways to measure our efforts. When we read what is DevOps, it also gives a feel that DevOps implementation is not simple, it might require a lot of changes w.r.t organizational structure and might require complete automation of development and operation processes. Due to which I have often got resistance for DevOps transformation. Usually, the team brings a lot of tools for automation w.r.t build, deploy and release to declare that they have done DevOps.
MVP should not be limited to new software products. Instead, organizations should consider minimum viable everything (MVE). By “everything,” I do mean everything. Any change can be viewed as a product release. Whether an organization transformation and infrastructure shift, a new service, or a feature release to a classically developed product, all of these can benefit from MVE
Sometime back, I had read a blog that talked Minimum viable of everything to demonstrate the viability of transformation or new change or new features and wanted to experiment that thought for DevOps transformation (highlighted in the above paragraph). So, why not Minimum Viable DevOps; the first version of DevOps, that my customers can benefit from. It would help us to minimize resistance w.r.t cultural changes, reduce cost w.r.t tools but showcase benefits of DevOps implementation. I would like to share the journey of that implementation; how it started and would love to hear your feedback on this implementation.
How it started: One fine day, Customers of XYZ applications figured that the orders that they had placed were either in the wrong quantity or with the wrong price due to which they suffered huge financial losses. After analysis for a few days, it was figured that data was not loaded properly. The business was very angry with the operations team for missing the problem. The operations team was angry with the IT team for not letting them know that there was a new release. A new SWAT team was formed to solve the issue and the team proposed DevOps as a one-stop solution that can solve all the problems.
Business case – With the Minimum Viable DevOps in mind, I wanted to understand how would the end state would like for customers. What are the benefits that they are expecting? Are they expecting faster deployment? Are they looking for quicker feedback loops? Are they looking for system reliability? Used the Gemba method and interviews with Business users, development team, Operations team, and leadership team to validate the problem statement and business needs. Customers wanted the application to have good quality data, perform faster and provide a faster feedback loop for any incidents. They did not want faster release as the customers were Non-IT people and it would need constant training to keep them updated.
DevOps Approach: With customers’ needs in place, the next step was to identify an approach for DevOps implementation. Even though DevOps talks about Culture, automation, and end to end flow as a single unit, do I need to implement all in a single go? Can we do Minimum viable DevOps for this team? Hence, I started with a couple of questions to define the DevOps processes/roadmap for this team:
1. What are the ways of working of DevOps that this team needs?
2. Do we need automation from testing to Build to release to deployment to monitoring?
3. How can the customer see the benefit fast?
4. What are the cultural elements that I need to get started with?
This helped me to define the MVP of DevOps implementation. Here are some of the practices that were implemented as part of our initial phase.
1. Unified backlog – Incidents, Monitoring and operational requirements from the operation teams were included as part of the backlog. Unified backlog was used by the product owners in the grooming, prioritization process for the team to work in the iteration. The single tool was used by both the Operations team and Development team.
2. WoW – (Ways of working)
a. Dev team and OPS team were co-located.
b. As a start, the Dev team was asked to work on at least 1 or 2 incidents in each iteration and the Ops team was asked to work on some of the user stories. This helped in building a “one team” culture even though their reporting structure was different. When the team demonstrated results in terms of business metrics (faster response to incidents, time to recover, etc) reporting structure was aligned.
3. Proactive monitoring – Monitoring tools were introduced to monitor the business metrics (Product usage across countries, performance, security, data quality)
4. Automation – Build, deploy and release cycle was not automated. Only testing was automated to focus on product quality.
Each of the above practices can be a separate blog but wanted to highlight MV part of DevOps in this blog.
The above mentioned four practices helped us to meet our customer’s needs i.e. to achieve faster response to incidents, reduce data quality issues and improve product quality. This also helped me to showcase DevOps and the benefits of breaking down silos in achieving value generation for Customers.
My journey with the team continues. Will share the journey after our next phase.
Conclusion:
In summary, DevOps can be broken down into practices, processes, and tools that are needed as per the context. It is not necessary to build the complete tool chain or define new roles or define new teams to call it DevOps. It’s about customer focus mindset across all the layers of the organization, Product owner learning from customers, developers coding for operation and Operation team owing customer experience.
“MVP and agile are essential components of a successful DevOps organization. They are also effective tools to enable a DevOps transformation. If you are trying to figure out how to transform from a classic IT organization to a DevOps organization, start by considering the minimally viable DevOps organization. While you may have only reduced “boiling the ocean” to “boiling a lake,” the reduction will prove meaningful.”
Further read:
“The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” book describes the fundamental principles of DevOps, describes “The Three Ways” from which are the principles that all of the DevOps patterns can be derived from.
Netflix – chaos monkey practice
