How to improve the speed and predictability of software delivery and what metrics have to do with it
Author of the article: Dmitry Kurdyumov
Participated in Agile transformations in the largest companies in Russia (Alfa Bank, MTS, X5 retail group), with international experience in a startup abroad.
The Importance of Predictable Software Delivery
Predictable software delivery is one of the biggest challenges facing development teams.
The inability to deliver software products predictably has a negative impact on all departments of the company, ultimately leading to lower customer satisfaction and retention: marketing teams cannot plan effective campaigns, sales teams have difficulty confidently selling roadmap elements, and customer service teams find themselves in a difficult situation where they cannot guarantee software delivery times. This disrupts the business and erodes trust between engineering and other departments.
Lack of predictability hurts development teams themselves, too. Developers working in an unpredictable environment are more likely to burn out, their experience deteriorates, and their code quality suffers from pressure to meet unrealistic deadlines.
Predictable Software Delivery = Stability + Speed - Risk
To achieve predictable software delivery, engineering team leaders must focus on three key factors: stability, speed, and risk. Balancing these elements is the foundation of a robust and effective software release cycle.
Stability
Stability is key and means having stable turnaround times, manageable pull request (PR) sizes, and low rework. Teams with high stability can plan their work more efficiently and reliably deliver on their delivery commitments.
Key indicators of stability include:
– Stable task execution time: Stable teams maintain consistent task completion times, which is critical for predictability. This can be tracked using the Development Cycle Time by Month metric.
Regular, predictable releases. The Release frequency metric allows you to track the regularity and trend of release frequency
Manageable PR sizes: Keeping PR sizes small and consistent ensures frequent integrations and reduces the risk of conflicts.
Low Rework: Teams that minimize rework can focus on creating new value rather than fixing problems that should have been fixed earlier. Tracking rework after release to production forces quality to be built into the process to minimize rework.
Stable VelocityWhen a team works stably, the length of the sprint remains unchanged, and the number of story points from sprint to sprint does not fluctuate greatly.
Speed
Speed measures how quickly you can deliver business results and make money from them.
Key factors measuring speed:
Lead time – execution time
Time of execution from idea to client. These statistics of time of execution collection for each element can allow to calculate a percentile by which to predict the completion of new tasks. Look at the dynamics of the metric and plan regular improvements after retrospectives and metrics analysis
DORA Metrics
DORA metrics provide a comprehensive view of how effectively a team can deliver software at high velocity while maintaining consistency and quality. Improving these metrics helps teams maintain a high development pace and deliver software products more predictably.
Here are some of them:
MR lifetime
Merge Request (MR) lifetime is the period from the moment an MR is created until it is merged into the main branch or closed. This metric is important because it reflects how much time the team spends reviewing, testing, and integrating changes. The faster an MR goes through these stages, the faster the changes get to production, which directly impacts the speed of software delivery. Reducing the lifetime of MR can significantly improve the overall efficiency and predictability of development.
Lead time for changes
Lead time for changes is the time it takes from the moment a change is made to the code (commit) until the moment these changes are successfully deployed to production and become available to users. This metric is important because it shows how quickly a team can deliver new features or bug fixes.
The shorter the lead time for changes, the faster the team can respond to user requests, fix bugs, and implement new features. Reducing this time helps speed up the development process and improve the predictability of software delivery.
Deployment Frequency: This metric measures how often a team releases updates to production. A high deployment frequency indicates that the team can quickly and regularly implement changes, which increases the speed at which new features and fixes are delivered. The more frequent the deployments, the faster the organization can respond to changing requirements or fixing bugs, which positively impacts speed.
Time to Restore Service: This metric measures how long it takes for a team to recover from an incident. Fast recovery minimizes downtime and business losses, allowing the team to get back to work on new tasks faster. Fast problem resolution also helps maintain a high development pace, as it reduces delays caused by unplanned work.
All of these metrics are key to improving the speed of software delivery without sacrificing quality.
Optimizing these metrics not only speeds up the development process, but also maintains stability, which ultimately leads to more predictable and successful software delivery.
Risk management
Risk is a key variable in the predictability equation and one of the main factors preventing teams from delivering on time, regardless of their stability or speed. Identifying potential obstacles early on and implementing strategies to mitigate them is critical to reducing risks associated with software delivery timelines.
Software Delivery Risks:
Unplanned work: Unplanned tasks, such as bug fixes or urgent changes, can throw any development team off course. This type of work usually requires immediate attention, diverting resources from planned tasks and disrupting the team’s workflow. The key to success is finding a healthy balance between proper iteration planning and leaving a buffer for additional tasks.
Technical debt: Technical debt is the extra work required to fix problems that arise from taking shortcuts or compromises in an attempt to deliver software faster. Unchecked technical debt can, over time, cause a codebase to become brittle, difficult to maintain, and error-prone. This can slow down delivery processes and increase the likelihood of critical failures.
Scope Creep: Scope creep occurs when additional features or changes are added to a project after it has begun. Without a full analysis of delivery dates and resource constraints, scope creep can lead to project delays and team burnout. It is important to have clear processes for evaluating and approving changes to ensure that any changes are consistent with the original project goals and timeline.
It is also important to monitor the level of Tech Debt through metrics, as well as to track the volume of unplanned work
How to achieve predictable delivery
Many companies already understand the importance of predictable software delivery and are implementing tools that allow them to collect and analyze key metrics to improve their development processes. One such tool is Aimger. It helps teams gain a clear picture of their performance, respond quickly to risks and, most importantly, significantly improve the predictability and quality of their products. Aimger You will find dashboards and necessary metrics that will increase the transparency of your work and allow you to improve the process.
To find out about Aimger for more details, subscribe to Telegram channelwhere you will also find many other useful articles on process improvement.
In conclusion, we also invite everyone to open lessons that will be held as part of the course “Product Manager of IT projects”:
September 3 at 19:00 – “What exactly to use when launching a product to avoid failure.” Sign up
September 12 at 19:00 — “How to become a product manager while already working in IT? Action plan.” Sign up
September 17 at 19:00 — “Efficient Use of Data: How to Become a Data-Driven Product Manager.” Sign up
