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.