20 October 2019
About 7 months ago, I started my new role at a SaaS company and was provided the freedom to identify multiple problems the internal DevOps organization currently had. From my 1on1 customer interviews with managers and engineers at all levels, the biggest themes included near real-time visibility into committed projects and overall health of the DevOps teams.
Terms like visibility and overall health are ambiguous at best and can suck up valuable time if led down the wrong rabbit hole. Where does one go for guidance on how to best lead and develop DevOps teams towards specific outcomes? The book I’ve been studying is Accelerate.
Unfortunately, this post isn’t for beginners in DevOps. If you are new, I would suggest starting with the Phoenix Project that provides beginner (although life changing) DevOps knowledge through story-telling. This book is a detailed case study of over 23,000 survey respondents and 2,000 unique organizations (startups to large enterprises) across multiple countries. The authors (Jez Humble, Gene Kim) of the book are practitioners and thought leaders in the DevOps space. I’ve had the privilege of getting classroom coaching from Jez directly in my first Agile training session many years ago. I’ve also been fortunate to meet Gene at the end of a Q&A session around the same time period. Both have practical experience and know what works and what doesn’t work for DevOps teams.
What’s great is the book very succinctly distills the insights and areas of focus for a high performing DevOps organization which I’ll describe in TWO parts below.
These are the 24 capabilities broken down by 5 broad categories (in no particular order) that a high-performing DevOps organization does very well that will ultimately drive improvements in software delivery performance. By focusing on capabilities, we’ve shifted the focus from thinking about OUTPUT (How much work are we doing? What’s the maturity level of our org?) to OUTCOMES (Did we help deliver on business objectives?).
We’ve shifted the focus from thinking about OUTPUT to OUTCOMES.
The pitfalls of focusing on output leads to toxic practices such as gaming the amount of work you do, fog-of-war tactics for a team’s work, burn-out for consistently overcommitted teams…etc. Focusing on outcomes aligns the incentives at a macro-level towards the betterment of the overall business and away from micro-level incentives. For a deep dive on each of these capabilities, I would suggest buying the book :)
1. Continuous Delivery
a. Version control
b. Deployment automation
c. Continuous integration
d. Trunk-based development
e. Test automation
f. Test data management
g. Shift left on security
h. Continuous delivery
2. Architecture
a. Loosely coupled architecture
b. Empowered teams
3. Product & Process
a. Customer feedback
b. Value stream
c. Working in small batches
d. Team experimentation
4. Lean Management & Monitoring
a. Change approval processes
b. Monitoring
c. Proactive notification
d. WIP limits
e. Visualizing work
5. Culture
a. Westrum organizational culture
b. Supporting learning
c. Collaboration amongst teams
d. Job satisfaction
e. Transformational leadership
Jez and his team distilled their findings across many organizations to find the metrics that matter most to improve software delivery performance:
1. Lead time
2. Deployment frequency
3. Mean time to Restore
4. Change fail percentage
As a cliff note: Lead time is the time it takes to fulfill a customer request, Deployment frequency is how often code is going into production, Mean time to Restore is the average time is takes for an application service to be restored during a service incident, and Change fail percentage is the ratio of successful deployments vs. failed deployments. Read the book to dive deeper on these topics.
Now we have the framework of 24 capabilities that our organization should be focused on building/improving. What’s the health of each capability look like? Which ones should be focused on first?
We also now have 4 KPI’s to measure the performance of agile software development teams that will help build those capabilities. Sweet cycle, yeah? :)
At first glance, this looks like a lot to handle. You’re totally right! Enacting change in a DevOps organization takes time and if you’re going to apply this framework to your org, I would suggest solution-ing a piece at a time rather than boiling the entire ocean. It’s usually better to be great at one thing rather than mediocre at several.
Deciding where to start can be tricky. I would suggest finding out what is most important to the customers/stakeholders within your org. That would usually be the VP, directors, managers, product/program managers and engineers. Doing user interviews and surveys will yield a painted picture of the status quo and where the the needs are most dire. I do have another framework to use for understanding the general landscape of the health of the org which I’ll leave for another post. But the idea is to understand the status quo before you begin.
None of this transformation stuff is easy. Culture is hard, engineering and systems building is a bit easier. Remember that none of this works without people and respect for those people. Now go and accelerate your transformation!