Quality feedback is essential to any software delivery project and the best way to improve feedback is to reduce the developer feedback cycle and make any (and every) result transparent to the project, its members and its stakeholders. You should continue to mesure and broadcast results through communication mechanisms commonly referred to as “information radiators.” These information radiators can be as low tech as a printed report on a wall or as high-tech as a computer display showing up to the minute, live results. The key is to make it avaiable.
Most organizations understand the need for metrics, but often get stuck at probably the most important question: What should I measure?
Since what you measure will often have a huge impact on the behavior of your team and the direction of the project it’s important that you chose your metrics wisely and don’t find yourself in the vanity metric trap. Managers without an understanding of software development often try to measure things like lines of code, for example, trying to measure velocity by some sheer number of lines written. A poor metric like this always leads the developer to write many short lines of code or pack a particular piece of code with unneccesary garbage to inflate their “value.”
The most important metric, and the place where any project should start is simply cycle time. Determining how long a single line of code change takes to make it from requirement to Production is hard to measure because it covers many parts of the software development/softwared delivery process, however it tells you more about your process than any other metric available. A properly implemented CI/CD pipeline should make it simple and clear to find and calculate the part of the cycle time corresponding to every part of the process from check-in to release. It should also let you see the lead time from the check-in to each stage of your process, so you can identify your bottlenecks.
Once you know the cycle time for your application, you can now identify what you should work on to reduce it. It also identifies where is the best place to focus your times and resources to get the biggest return on investment. A typical process for resolving cycle time issues is the following:
- Identify the limiting constraint on your system. This is the part of your build, test, deploy, and release process that is the bottleneck. A common example is typically a manual testing process, or poorly created automated GUI tests.
- Analyze the constraint to determine potential remdiations:
- Does it require more resources? Does it require different resources?
- Does the activity require refactoring? Are we doing things in the most effective way possible?
- Is your process creating an artifical bottleneck that may be resolved by modifying your process?
- Implement your solution.
- Re-Evaluate nd repeat.
