Gauges
Throughput
An interesting measure to focus on is simply speed or throughput. The time it takes from a developer proudly shouting “It works on my computer!” to it actually working on the end user’s computer.
For each card ask yourself the following question:
To what extent would implementing this feature or ability improve the overall throughput of my pipeline?
The feedback is measured from one to three stars. Use the stars as follows:
The improvement can be counted in minutes.
The improvement can be counted in hours.
The improvement can be counted in days.
Feedback
Continuous attention to your surroundings will provide you with the means for you to reflect upon your current situation. Think - and then improve it.
Feedback can be in the form of logs, data, graphs, statistics, analysis, discussions with customers or colleagues - Anything that gives your surroundings a voice.
If your Continuous Delivery ecosystem or your application isn’t talking to you, then you’re trying to move forward while blindfolded, in the dark.
Give your surroundings a voice.
For each card ask yourself the following question:
To what extent would implementing this feature or ability provide more feedback or visibility to the responsible worker and his colleagues?
The feedback is measured from one to three stars. Use the stars as follows:
It sporadically affects the developer at an individual level.
It affects the entire team and collaboration.
It affects us, beyond the project, at a corporate level.
Payback
For most software projects it’s the code’s complexity and technical debt that eventually makes it obsolete.
Every time we touch the code, we’re jeopardizing the original design and quality. Either by adding quick solutions that don’t scale or because we simply don’t add non-functional ‘abilities’ to the solution.
Testability, traceability, maintainability, supportability, readability… These kinds of abilities.
We’re building up technical debt - debt that will have to be paid back or you’ll end up broke.
For each card ask yourself the following question:
To what extent would implementing this feature or ability help to pay back on technical debt or actively prevent more debt from being added?
The payback is measured from one to three stars. Use the stars as follows:
It sporadically affects code snippets at an individual level.
It affects design at a team collaboration level.
It affects architecture at a corporate asset level.
Complexity
Complexity is everywhere.
In a standard approach to software development, complexity is the meter that influences all others.
The simpler a solution is to implement, the faster the Return On Investment.
For each card ask yourself the following question:
What would be required to implement this feature or ability, taking into account man hours, money spent up front, and ongoing cost of ownership?
The first level of complexity is something an individual can do within project scope. It’s marked as a low hanging fruit .
The second level of complexity is something that can be achieved as a team effort, still within a project scope. It’s marked as a team effort .
The third and highest level of complexity is something than can only be achieved with permission and funding from the line-organization. It’s too big for the project to handle within it’s own means and resources. It’s marked as a mountain to climb .
Score
The card score is calculated based on the values of the gauges.
The algorithm used is:
(throughput + feedback + payback)
Each card is also assessed for complexity, you should pay attention to the cost of implementation:
It’s a low hanging fruit.
It’s as a team effort.
It’s a mountain to climb.