Organizations worldwide are trying to adopt DevOps practices in software development and delivery. One of the things enterprises do is to conduct a devops assessment which will outline current maturity and identify roadmap of improvement areas. Our team has done devops assessment for organizations spanning from startups to large enterprises. We have noticed some patterns during those assessments that differentiate an assessment which adds value vs. one that does not contribute much to organization. We also believe these findings can be useful to initiatives which span across teams/silos in organizations.
Before we dive into ingredients that enable a successful DevOps assessment, let’s do a overview of how a typical devops assessment looks like. Based on the size of organization the DevOps assessment can span anywhere between 2-6 weeks. If the teams are distributed globally, we also typically try to interact with more than one location to get a better understanding of collaboration and team strengths. During DevOps assessment we spend significant chunk of time with developers, QA engineers, build and deployment teams and potentially infrastructure teams - basically all teams involved in hands on implementation. We also spend time with project/portfolio managers, technical architects and management to understand the goals, strategies and decisions planned for next few years. With hands on teams we do a few iterations to deep dive into certain areas and to solidify initial assumptions and understandings. Report is drafted every day and a weekly review is done with key stakeholders such as technical architects etc. The last week or few days are typically spent in conducting POCs if applicable, building out holistic report and presenting to stakeholders and management.
The report itself focuses on a few pillars: process, technology & tools and organization. Each of the areas has details of potential improvements, how to go about implementing the improvement, what is required to get it done and what kind of benefits to expect out of it. Areas which need POCs are called out - typically pertaining to evaluation of tools when more than one exist and need to be mapped to organizational needs. Finally a rough phased implementation plan is provided which will help in implementing one thing at a time enable building on successes of small achievements.
One of the key factors in any successful activity is correct identification of problem. You can not expect a solution to work if problem identification is flawed. For DevOps assessment to be successful the right sample size selection is an important factor. For example in a large organization with multiple business units, it may not be practical to conduct assessment even for one business unit entirely. What might work best in this situation is choosing one product/project with a fair mix of known problems and areas known to work well. Choosing a project which already is working well may not provide any valuable insights while choosing too a complex project might lead to too many problems to be investigated in short span of DevOps assessment. In a smaller organization with one or few focused product lines the assessment might be easier to conduct for whole organization and will also yield more value by finding ways to standardize.
A typical DevOps assessment includes interaction with your development, QA, business, production support and infrastructure teams. Each of teams/members might have different ideas about what DevOps is and what it is not. It is very important to set the context right before the assessment. While setting the right context would help in getting information, we think setting KPIs for each of teams will go a long way in aligning all teams for the same goal. During the assessment KPIs can aim to achieve provide detailed information and identifying three potential high leverage areas of improvement. During the implementation the KPIs can be more concrete such as reduction in failed deployments by 50% over 6 months. Or reducing the instance provisioning time by 50% as compared to current time.
One of key practices that DevOps introduces is breaking the silos. For a holistic view of end to end value chain the assessment must involve people from multiple silos. A lot of problem areas are not visible in silos but surface to top when dots are connected across the silos. Ideally involve people from all phases of SDLC to work together towards the end goal. Breaking the silos will not only kick of the process of bringing down communication barriers but also help in aligning teams towards a larger common goal.
If you are looking for a silver bullet called DevOps - unfortunately none exists. Improvements in an organization and technology take time and it is an evolving process. DevOps assessment will show you a path and will give you a headstart in journey of DevOps implementation. But beyond that you will have to follow due diligence in implementing it. In age of emergent design moving faster in smaller chunks is better than huge efforts upfront design. Implementing DevOps is a journey and only way to get there is take the first baby step.
DevOps like any organizational initiative requires changing existing ways of working to make space for new one. DevOps assessment if done right can act as a lighthouse for navigating the journey of DevOps implementation. Share with us your experiences of DevOps assessment and implementation.