“An integrated approach to enterprise improvement”, by Bryan Finster
One of our goals is more rapid feedback of delivered quality. To achieve this, we need to expose the reasons that feedback gets delayed. The most direct route is by shrinking itmeboxes. We set a goal for a maximum time from when we start work until it is delivered to the user, and then find and fix everything that prevents that.
Why can’t we fit all of the activities to deliver a story in five days instead of fourteen? Why not two? In 1955, C. Northcote Parkinson wrote, “Work complicates to fill the available time”. In error-tolerant design, a forcing function is a built-in constraint to prevent common user errors. In our case, shorter iterations act as a forcing function for improving quality. With a shorter iteration, we are required to create smaller units of work. To make the work smaller, we must get into the details of what we are delivering, and uncover the assumptions and dependencies we may have missed. This improves quality and allows us to deliver value sooner with less toil, rework and stress.
This in particular would be useful to the ATLAS group (seller risk) folks, who seem to have domain experts on areas of the code until the thing is 100% done and deployed, at which point a knowledge transfer (KT) happens.
Teams should use a pull system where the whole team focuses on delivering the highest priority before moving to the next. This ensures that the whole team has context to the current work and can contribute to quality and speed of delivery
Oof. This seems to apply to all of the groups I’ve worked with (especially the authority & responsibility pieces).
Teams should be organized around business capabilities and the flow of value to the customer, not around roles. Teams should be resilient to absence, contain all the skills required to deliver without handoffs, and have total quality ownership of their domain. This ownership means they have the authority for how to solve the problems, the authority to improve and responsibility for the outcomes.
Keep asking “Why can’t we deliver changes to trunk today?” and solve the problems. Understand that CI is about people communicating, not about technology.
Relevant to keplers. The cost of change is too high, so you don’t get to make architecture changes.
By focusing on shrinking the size of everything we do, CD helps us uncover the problems in our flow that are impacting quality and increasing the cost of change.
Metrics he suggests:
- Lead time (recieve request -> deliver solution)
- development cycle time (work start -> deployment)
- build cycle time aka “hard lead time” in Accelerate terms (merge -> production)
- defect & change fail rate, measures quality gate effectiveness
- mean time to repair, measures instrumentation & speed of breakfix delivery
- undelivered inventory (work backlog, WIP, undelivered code changes, etc). Lower is better.
- Morale (team sentiment)
Non-metrics:
- test coverage
- velocity
- individual activity