Why is this a good thing? Well, once something is measurable, it is actionable.
The Matrix is split into rows (Quality Levels) and Columns (Aspects of Delivery). You should be able to give a Quality level for each Aspect based on your current development life-cycle. This can help us to understand where our weak points are, or why we may be unable to deliver consistently.
|Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation|
by Jez Humble and David Farley
The following is an extract from a piece that I wrote in 2012.Delivery had been a big problem for us, but the matrix helped us to understand how we could make the delivery process more reliable and robust. I took a copy of the matrix and marked where we were against it (see above). Something had to change, and the matrix helped us to identify the adjustments that we we could make and also helped us to use an appropriate language with our line managers. Where we were regressive, we would take action to become repeatable. Where we were repeatable, we would take action to become consistent, etc.
Our improvement would not have happened without measuring against this matrix. It is my belief that after every project delivery we should grade ourselves against this matrix as part of the project review, learn the cause of failure and create actions to address this in subsequent project deliveries.
Please take a moment, have a think about your latest project delivery, grade against the matrix, and have a think of how it could have been less painful.
Remember, when it comes to software delivery: "If it hurts. Do it more frequently".
Understand the pain and address it.
Two books that should be on your book shelf.