DevOps missing link - Continuous Governance (CG)
If you rolled your eyes when you read governance and DevOps in the same title, you’re not alone. There’s no question that governance initiatives evokes visions of Big Brother and wasteful “extra processes and motion”. There is also no question that large enterprises with 100s developers and Agile teams have to deal with IT performance goals at every level whether they call it governance or not.
With the advent of automation in software development, we can apply lean principles to governance and direct team-level improvement activities towards organizational goals while preserving their ability to self-organize. I call it Continuous Governance. Continuous Governance (CG) can do for improvement what Continuous Integration (CI) has done for quality and Continuous Delivery (CD) has done for feedback, use automation to enable DevOps and thereby lift IT performance to next level.
But why governance to drive improvement?
Large enterprises that run software-intensive business want to optimize on speed of delivering innovations. Emerging DevOps and Agile practices are moving these enterprises to adopt Platform-based operations with small autonomous 2-pizza Dev teams becoming customers to this platform team. This approach empowers these individual dev teams to experiment new ideas and release them to customers directly and quickly.
However, this state is difficult to achieve without deliberate governance to direct improvements in every team continuously towards organizational goals, such as, to enforce incremental use of common platform facilities, to adhere to business constraints while preserving their freedom and to enable sharing of learning across teams. That begs the question, how can automation enable such governance continuously?
The answer is in performing the OODA loop (Observe Orient Decide Act) at every level of your organization. First, Observe data across tools and derive measurements that show IT performance. Next Orient data to reflect on team’s performance and identify wasteful activities that hinder performance goals. Then using lean principles Decide on automations that constrain actions in tools or nudge practitioners to do tasks that are consistent with goals. Finally, as automations trigger, affecting daily tasks, Act regularly to statistically measure progress towards goals and adjust constraints and nudges establishing new habits that are consistent with organization goals.
What to Observe?
The recent 11th State of the Agile Report brought out the severity of measurement problem
“Inconsistency between how more strategic areas of the enterprise are measuring success and how success is being measured at the team level”.
This dichotomy is inhibiting the ability of organizations to scale the benefits of Agile and DevOps practices. For Continuous Governance (CG) to impact IT performance, we will require to use simple transactional metrics with clear improvement goal that makes sense at every level of the IT organization. Such a metric should also be continuously measurable across different product teams, using different processes and tool chains.
For example, an organization may want to measure “number of releases per week” as a transactional metric and have a goal to make a 2x improvement to it over next quarter. This metric and goal has meaning at every level of organization, be it a business unit or a program in it or specific product team in the program. By observing data across tools and processes, we can then continuously measure “number of releases per week” and reflect on IT performance at every level.
What measures make up IT performance?
This begs the next question, are there transactional measurements that cover IT performance broadly. A specific answer may vary a bit for each organization, however in general Nicole Forsgen and Jez Humble, DevOps gurus, has codified four (4) transactional measures as strong indicators to reflect on IT performance. They are
- Lead time for new changes
- Release frequency
- Time to restore service
- Change failure rate
These are perfect transactional measure to direct improvements that optimizes on speed to delivery innovations to customers because first 2 covers throughput (opportunity to try more innovations) and the last 2 covers stability (opportunity to grow confidence). By the way, if you are a CMMi wonk, you will recognize that these are excellent lagging indicators for “Level 5” process areas.
Good read on the interesting aspects of the CG framework
Yes, I am definitely interested in learning more about this. Thank you for sharing
Thanks for writing and sharing this post. Badri Sriraman. Can you tell us more on how companies are implementing the measurement of the "Lead time for new changes"? Are they taking in the consideration since the moment, for example, user stories enter the backlog til it goes into production? I am in the process of collecting metrics from many continuous delivery pipelines implemented on Jenkins and GoCD to create dashboards on Kibana with the ELK Stack.
Great article. I've been evangelizing CG to my Government customers for some time. Apps developed in certain parts of the Government have to be accredited prior to going operational. Without CG, accreditation can take much longer. This negates the advantages of Agile. Unfortunately most development teams could care less. The message only resonates with organizations responsible for accrediting - who are also being blamed for the slowing down the release process.