DevOps does not have any KPI. It would be like asking what are the KPI of Love. But some of the things you mentioned (Problem and Incident Management, Capacity Management, Change and Release Management) do have good KPI, some of which are based on the theory behind DevOps.
In general, for any business process, you can create a Value Chain Map describing how value flows from Customer, through the enterprise back to Customer. The entire loop always has to start and end with Customer, but sometimes, for a service organization, the Customer can be internal. The throughput of value through such chain can be a good way to design your KPI in a tamper-proof way. Measuring any KPI in any individual link of the value chain only makes sense as long as that particular link is the bottleneck of the process and you try to exploit or elevate the bottleneck.
A common problem with KPI is when it starts halfway through the chain. For example, a Change and Release process often starts with developers and ends with deployment. This process excluded:
- Customer having a problem
- Support team identifying the problems
- Product team defining the problem for backlog
- Solutions team customizing the deployment for the customer
- Customer realizing value from the solution
The problem is that measuring a cycle time alone could lead to two major problems:
The bottleneck is in any of the excluded parts mentioned above and your customers are not realizing the value and you are not realizing the revenue proportional to the speed of your cycle time. So while your engineering is excellent, your business suffers.
The disconnect from Customers will make your release cycle spin on empty - not producing any value, despite change being done - or even counter the needs of your Customers and the work being done could have negative business value.
Another problem with KPI is that while starting and ending with a customer it might not actually measure the value to the customer. A good example would be a Problem and Incident Response process and MTTR (Mean Time To Repair) as KPI. Does the problem even affect anyone? What is the value to customers? You could have excellent MTTR of 3 hours over 100 incidents. But if most of them were internal, with no or minimal impact to customers and resolved in minutes, while the one large incident with huge customer impact took 3 days to handle, the business value is lower than if you had 1 day MTTR, because you ignore most of the internal incidents, but you responded to the huge customer impact incident within 1 hour.
NOTE: For an internal customer, in case of the support team business process, the derived value is not the value of the work to the internal customer, but the value gained by the business in unblocking the internal customer in their own business process. Unblocking a team that is a bottleneck in their own process derives higher value than unblocking a non-bottleneck team or individual. All KPI of such support team need to include the business value in their calculation.
