This report summarizes the findings of a series of workshop conducted in relation to the CoDeMeMo performed for Your Awesome Company on 2024-04-07 00:00:00 +0000.

Here follows a short intro to Your Awesome Company

The Continuous Delivery Assessment

The interviews and workshops related to the CoDeMeMo has the purpose of getting a complete overview of the organization with specific focus on software development, the tool stack that surrounds and supports it and the processes used to develop, verify, deploy, test and release software.

The goal of the interviews and workshops is two-fold:

• To raise awareness in the software development team of some of the best practice methods, tools and processes available for improving efficiency and producing higher quality software.
• To outline a roadmap as a practical guide to achieving this goal.

Awareness is achieved by conducting a considerable part of the interviews and workshops and facilitated discussions with the developers in the software team.

The roadmap is manifested in the report you are currently reading.

This report

The report is structured around the Continuous Delivery Metric Model which was presented to all participants during the workshop. The chapters in the report reflect the focus areas in the model.

Throughout the report, findings and observations are given their own section header and paragraphs under each section are marked with an up-arrow  indicating that it contains a recommended action mitigating an issue.

Mitigation’s are tagged with a prioritization (M, S, C or W in parentheses). These letters represent the authors opinionated recommendation of priority for the suggested actions.

The lettering refers to the MoSCoW principle for prioritization:

• Must have A condition that must be satisfied in the final solution for the solution to be considered a success.
• Should have A condition that should be included in the solution if it is possible. A critical condition indeed but not discriminating for success if left out.
• Could have A condition that could be included if time and resources permit. It is considered desirable but not strictly necessary for success.
• Won’t have (not used in this report) A condition that is not currently relevant and which will not be implemented but could potentially become relevant in a future scope.

The prioritization that we have come up with is meant to be a catalyst for your internal discussions - you may not agree with our priorities in which case you should obviously go with your own.

Each section is designed as a standalone piece so that the suggested remedies and improvements can be applied independently. This approach should enable you to copy most sections marked with  directly into JIRA and prioritize them. All you need to do hereafter is to groom the task, estimate the work, and put it on your backlog.