The Continuous Delivery Maturity Matrix

The Continuous Delivery Maturity Matrix is a yardstick which against which you can measure your current processes. Ultimately this equates to how well you are able to deliver your projects.

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.
Continuous Delivery
Continuous Integration

Send me a picture, so I can remember

Retrospectives

Sprint retrospectives are important. This may sound like I'm stating the obvious but please make sure that you have concise retrospectives.

The big benefits of a good retrospective include

• Getting honest feedback on the progress of your project. 
• Gauging the teams mental state. 
• Strengthening relationships between the team members (after all, we are in this together).

If you are organising the retrospective, your biggest job is to help people to give open feedback. You can do this by creating an environment in which they are comfortable and giving them tasks that help elicit the information as opposed to directly asking for feedback on the sprint.

The following exercise describes one of the methods for garnering feedback.

Postcards from the Sprint

• Before the retrospective

1. Get (or make*) some postcards. Try to use a wide selection of destinations, 10 postcards of the east coast is not a good selection. 
2. Get (or make**) some tokens. Make sure that these are easily identifiable (eg. Monopoly pieces).

• In the Retrospective

1. Ask all member of the retrospective to choose a token.
2. Spread out the post cards on a flat surface.
3. Ask the members of the retrospective to place their token onto the postcard that they 'feel' represents the sprint that we have just completed.
       - Wait for everyone to place their token - 
4. Choose a token (not a person***) and ask who that token belongs to. Ask that person to describe in what way they feel that that postcard represented the sprint.
5. Remember to say thank you. 

Why is this a good exercise

• The postcards act as a starting point, whether that it is an association to the place, geography or a metaphor, the person is grounded by the selected image and merely needs describe a context.
• Everyone gets to express an uninterrupted opinion and comment on the sprint.
• The tokens are ambiguous, and therefore the running order is random.
• Members choices are 'locked in' so there is no playing follow the leader when they are expressing their feeling.

Retrospectives should not feel like a chore and it is not a cull-able step in the process. So keeping people engaged at this stage is important. we've managed it all sprint and by Jove we'll keep them engaged in the retrospectives too!!

* How to make a postcard: Find a royalty free picture, resize it, print it, cut it out, laminate it.
** How to make a token: (see 'How to make a postcard' above).
*** Not a person: We want to disassociate any feeling of singling out, identifying or alienating individuals when eliciting unbiased feedback, hence the tokens.

Versioning for a reason

Please do not push an un-versioned release to your test environment only to recompile and push a versioned dll to your Production environment. If the version numbers do not match then you should not presume that the application code will behave in the same way. If your QA and Testers have signed off version 0.0.0.0 of the application (which could be absolutely anything) How can your product manager confidently allow version 1.0.0.0 or 1.3.11.2 to be released.

So we know that version numbers important, but for whom?

Software version numbers are there for the management of the software through all of the processes that follow the code being written. We need to know what code is being tested, we need to know what code the user has signed off, and we need to know what features are being delivered to the end user. The only person that doesn't need to know about the version number is the user themselves.

How do we keep our version number unique?

The version number of a .Net assembly is made up of 4 sets of numbers (Primary, Secondary, Tertiary and Quaternary). We *could* just use four sets of random numbers, alternatively we could make this version number into something more meaningful.


We could use the Primary number to represent the primary functionality offered by the product. When there is a significant upgrade to the functionality, perhaps the number could increment based in the completion of an epic story. Given this, the product manager is able to understand what his product is offering based on this number.

We could use the Secondary number to represent incremental updates to the existing functionality. These would be enhancements to existing functions of the system, perhaps indicating project milestones or story completion.

We could use the Tertiary and Quaternary numbers as an incrementing 'unique' aspect to the full version number. I have previously used these to signify the time from the start of a Product's development. Currently I am using the Tertiary number to represent the days since development began and the Quaternary number to state the build number for that given day.

What have we got?

We've now got a version number that is not just unique, and therefore traceable through all stages of our development and deployment processes. But one that also contains meaning for everyone involved in the process of delivering the software to the end user.