Go deeper on Cycle Time with Risk & Resilience

Engineers experience cycle time through risk and complexity trade-offs.

Aiming for small PRs should always be the goal but we should also embrace the realities of development where we occasionally have to make larger changes to get work done in high time pressure environments.

Being fair and more precise

Cycle Time is actually a great metric, when paired with additional data to paint a more accurate picture of what’s happening. Used in a vacuum, it can lead you down some strange paths that waste time.

Shepherdly expresses Cycle Time through objective risk measures, in three easy to grok buckets (low, medium, high). Teams should have different expectations of velocity based on how risky something is. Longer cycle times (within reason) when accompanied with adequate resiliency should be celebrated not looked upon as a metric to arbitrarily drive down.

You might think that PR size accomplishes the same thing. Not quite. Scanning popular open source projects, the size of a change is can be directionality predictive, however, the importance & thresholds are wildly different project to project. In some repositories, it barely mattered at all relative to other predictors. This is why bug prediction is an untapped and undervalued resource in our field. Developers are missing a metric that captures the essence of complexity and resilience.

Codify your risk tolerance 

Shepherdly allows teams to configure their desired resilience based on the risk score. With objective risk measurements, teams can focus their velocity efforts on very low risk PRs and their resiliency and reliability efforts on high risk changes. The results in delivering most changes faster and dramatically reducing the blast radius of the most complex PRs.

Here are some examples scenarios that Shepherdly can enable:

My team needs to go fast, we can tolerate some turbulence

💡Low-risk PRs increasing test coverage can be merged without review. Moderate-risk PRs require a review on top of that, and high-risk PRs need a feature flag in addition to all previous requirements, with at least one reviewer.

This recipe minimizes context switching on a large amount of PR activity which is generally low risk. It focuses the valuable review capacity on collaborating on how to best mitigate risky changes.

My team is optimizing for rigor and resilience

💡Low-risk PRs must increase test coverage & require one review from a member of the team. Moderate-risk changes require specific steps unique to our team and a review by a senior member. High-risk changes additionally require integration tests, observability, feature flags, and multiple reviewers. 

In this scenario, the team justifiably maximizes their resiliency effort by incorporating best practices and custom processes unique to their team.