Less rework (Concept)
March 27, 2025 · View on GitHub
Description
Fixing things that weren’t done right the first time and, like change fail rate, is a proxy measure for quality.
Tags
outcome
Documentation
One measure of whether teams are building quality into their work is the how they spend their time. Are they able to focus their time devoting effort and energy on developing new features and supporting infrastructure? Or do teams spend most of their time correcting problems, remediating issues, and responding to defects and customer-support work (that is, fixing issues that arise because quality was not built in up front)? We conceptualize this time into two categories. The first category is proactive or new work, in which we are able to design, create, and work on features, tests, and infrastructure in a structured and productive way to create value for our organizations.
The second category is called reactive unplanned work, or rework. Unplanned work includes any break/fix work, emergency software deployments and patches, responding to urgent audit documentation requests, and so on. Rework is fixing things that weren’t done right the first time and, like change fail rate, is a proxy measure for quality.
Other Relations
| From | Name | To | Description |
|---|---|---|---|
| Well being | leads to | Less rework |
Concept Map
Concept Map for DevOps Research and Assessment (DORA)
Navigation
(generated by Overarch with template docs/node.md.cmb)