Navigate evergreen delivery
Evergreen delivery: The risk of bad process
Even the best individual contributors can be corrupted by bad processes and the overarching organizational ecosystem in which the team performs work. For example, despite establishing agile adoption committees in the next step, the enterprise falls victim to waterfall planning strategies. Leadership finds themselves wondering why adoption rears turbulent and unpredictable results. The most frequent risks stem from inadequate processes that surface as technical debt, product debt, poor code quality, and volatile team output.
Technical debt is defined as the long-term cost of rework. It is caused by teams cutting corners to get the product out the door faster (a sometimes acceptable strategy) or by poor and accidental technical decisions. Technical debt is closely related to engineering maturity. It is worth establishing and reviewing best practices across the following:
Testing strategy and metrics
Scalability requirements and metrics
Security standards and testing
Monitoring tools, reporting
Code quality standards, testing
Product debt is not technical in nature but implies a similar future cost of rework to improve the market fit (or user adoption). For example, an eCommerce platform integrates authentication and authorization services from an existing social platform, such as Facebook, to speed up the initial go-to-market timeline. Debt itself is not a risk, as long as the team is aware of the accrual.
Actively log technical and product debt as stories in separate debt backlogs. Stories are estimated, and the total size of the technical backlog is monitored during each sprint. Teams allocate part of their sprint capacity for debt removal, and the delta of change is reported during a demo.
Avoid scenarios where technical debt accrues faster than it is cleaned up. Eventually, the product reaches a point of no return where teams experience never-ending churn without the ability to ship new features (also known as legacy software).
Poor code quality also puts evergreen products at risk. Adopting a set of strategies for quality metrics (e.g., test automation, reporting) and code quality standards (e.g., code reviews, styling) enables organizations to monitor risk and correct errors when necessary.
Consider the tracking of defects as stories in the backlog. For example, a report that contrasts the number of escaped defects with resolved defects depicts several insightful stories on the effectiveness of the testing strategy. The ability to resolve defects without delays implies healthy elasticity in the pipeline. However, increasing the overall defect quantity uncovers a poorly designed test automation strategy or lack of unit coverage. Similarly, tracking defects discovered by internal testing engineers pre-release reveals individual engineers are getting sloppy and vice versa.
Tracking metrics enables the product team to self-govern and course correct.
Risks presented by volatile team output manifests in an unpredictable sprint velocity. For example, the root cause of volatile throughput could be estimation. Teams overestimate and under commit, trying to game the metric for when pressure is being applied from senior leadership. In other instances, root causes indicate a bottleneck in dependencies stemming from poor refinement of the backlog.