The DevOps conversation with a senior executive:
Exec: We have best of the tools in world to cater for each stage of software lifecycle. We are very advanced in our DevOps journey.
Me: Great to hear. Are you getting value out of these tools? How you are measuring success?
Exec: I am not sure. There are teams who are using various tools and then there are some who are not. We are not consistent. I guess we are getting good returns in some areas and some are just getting started.
Me: So, do we have a roadmap or guidance for teams around what tools to use and how these tools work together?
Exec: We are open and flexible. We allow Developers and architects to recommend and use what works for them. We have a tools library but you can add to it if required. We don’t have a published guideline as such.
Me: That sound more like bring your own tools. Do you think teams know how to use these tools for their projects?
Exec: Not everyone. But there are few in COEs who know. Also every team is at a different level of understanding when it comes to tools. So it’s not uniformly assessed currently.
Me: Thanks for sharing the insights. Are teams aligning with business objectives?
Exec: Majority of them have their project KPIs and they are aligned with our business objectives.
Me: Your Ops teams are also part of development cycle?
Exec: No. we have a central Ops team. The project team delivers the project and hand it over to Ops for support.
Me: So, how long it usually takes to fix a production defect? Are your Devs and Ops using the same toolchain?
Exec: Depends on different teams. Devs are involved only in L2 support cases. It takes usually 3-5 days to get a release out. Our Ops use a ticketing software and triage from there. Dev team shares code etc. on n
Me: That’s quite a separation. Are there plans to join Dev and Ops team together?
Exec: Not near soon. Our organisation structure doesn’t allow that.
…..
Does this sound familiar to you?
Different People understand DevOps differently. In majority of cases people focus only on Tools and believe DevOps is all about tools. Few people start with processes related to software engineering or technical excellence and try to over-engineer them. Very few people holistically understand what DevOps means and how DevOps can help business value delivery. Don’t get me wrong here – It’s okay to start with tools or process focus, however that’s not what DevOps is all about.
Before starting your DevOps journey, it is imperative to understand the problems you are trying to solve. Once you have chosen your pilot projects, ensure goals are captured and tracked correctly. When the pilot is successful and enterprise roll-out starts, you start to experience the challenges of scaling DevOps. If these challenges are not addressed in a timely manner, you limit the success stories to few pockets within the organization.
In an enterprise environment there are multitude of problems such as:
- Organisational
- Structural
- Political
- Single View of Progress
- Governance
Resolving these problems require breaking barriers across boundaries of departments, functions and roles. Having a DevOps roadmap that can cover tools, process and people aspects along with high-level milestones can help to bring everyone on same page.
In the section below, I am listing steps that we can take to break barriers across boundaries of departments, functions and roles.
Create and Communicate Guidelines
- Create Continuous Delivery vision and guidelines
- Communicate the vision and guidelines with everyone
- Refine guidelines regularly
Culture Shift
- Ops involved in inceptions, showcases and retrospectives
- Devs go to weekly ops stand-up
- Devs rotate through ops
- Devs carry pagers
- Success is celebrated, failure is cherished.
- Experiments are encouraged
- Uncertainty is embraced i.e. panic is handled as needed
Collaboration within and across teams on
- Celebrate success together
- Knowledge
- Tools and techniques
- Best practices
- Legacy Know Hows
- Fears, Risks and Assumptions
- Business Value
- Trust
Tools and Technical Excellence
- Build, deploy, test release (deployment pipeline)
- Provisioning and management of infrastructure and environments (infrastructure-as-code)
- Database migrations and deployments
- Test execution, code coverage and code quality checks
Measures and KPIs
- Business metrics – revenues, # of customers, # of orders etc.
- Ops metrics – changes, incidents, TTD, MTTR
- Technical metrics – TPS, response time, hits
- Root cause analysis – which changes break stuff?
- Lead time and cost to release an unit of business value
Governance
- Use feedback and facts from pilots to change systems, structures and policies that don’t fit the continuous delivery vision.
- Allow exceptions for teams to define their “flavour” of DevOps, best suited to their specific environment. Do challenge them if they are more after limelight and rebranding existing stuff.
- Avoid governance frameworks, instead provide guidelines on Dos and Don’t.
Key Recommendations to long term success
Last but not the least, I would never recommend to copy someone else’s DevOps roadmap and trying to replicate it as is. Every environment is different, every team is unique and you know your organization better than anyone else.
On closing remarks, I would like to define DevOps with a simple definition as below:
“DevOps is like a lifestyle choice for both developers and Ops folks. You need to adopt new ways of working (learn), forget old habits (unlearn) and amend some of your routines (relearn). You do this consistently to get better results not just for yourself or your team but also for everyone involved in the value chain – It’s not a one off activity.” – Sandeep Joshi
I will leave you with one question in hand – “Is your DevOps Transformation driving business value?“. Share your DevOps journey, your struggles and successes and opportunities where we can work together. Thank you for your time reading this article.