The notes of Justin Abrahms

Recently updated

Accelerate

Feb 16, 20263 min read

Book by Nicole Forsgren, Jez Humble & Gene Kim.

@startuml
[Software delivery performance] as soft_delivery
[Organizational Performance] as org_perf
[Noncommercial Performance] as noncommercial_perf
[Westrum Organizational culture] as westrum
[Continuous Delivery] as cd
[Lean Management] as lean
[Lean Product Management] as leanp
[Job satisfaction] as jobsat
 
'skinparam linetype ortho
 
soft_delivery --> org_perf
soft_delivery --> noncommercial_perf
westrum --> [org_perf]
westrum --> soft_delivery
cd --> westrum
[Strong technical practices] --> cd
cd --> [Less Rework]
cd --> westrum
cd --> soft_delivery
cd --> [Identity]
cd --> [Less deployment pain]
cd --> [Less burnout]
lean --> westrum
lean --> soft_delivery
lean --> [Less burnout]
leanp --> westrum
leanp --> org_perf
leanp --> [Less burnout]
leanp --> soft_delivery
soft_delivery --> leanp
[Identity] -->org_perf
cd --> jobsat
lean --> jobsat
jobsat --> org_perf
 
@enduml

As Martin Fowler mentions in the forward, the “book focuses on IT delivery, that is, the journey from commit to production, not the entire software development process.”

The book claims that they found 24 capabilities that drive software delivery performance and thereby business improvements. They prefer a capability model over a more traditional “maturity model” because:

  1. You never “arrive” at done; continuous improvment means there’s always more work.
  2. the change is non-linear. You could do all of the CD capabilities and none of the architecture, rather than having to do a bit of each one to hit each ‘rung’ of the maturity ladder.
  3. capability models are outcome based, rather than a checkbox b/c you installed a tool
  4. things change. What is S-tier today is C-tier tomorrow.

Measures of performance

  1. Delivery lead time - The time it takes for work to be implemented, tested and delivered.
    1. Note this doesn’t capture when the feature is designed, including POCs of wholesale new things, (which they call the “fuzzy front end”)
    2. They further restrict their work to code commit → running in prod
  2. deployment frequency (as a proxy for batch size measurement)
  3. time to restore service
  4. change fail rate (percentage of deploys which required remediation; e.g., lead to service impairment or outage, require a hotfix, a rollback, a fix-forward, or a patch)

Capabilities that drive software delivery performance

All tall order, to be sure, but doable.

continuous delivery capabilities

  1. Version control
  2. Deploy automation
  3. continuous integration
  4. Trunk-based development
  5. Test automation
  6. Test data management
  7. shift left on security
  8. continuous delivery

Architecture capabilities

  1. loosely coupled architecture
  2. empowered teams

product & process capabilities

  1. Gathering customer feedback
  2. value streams
  3. working in small batches (see batch size)
  4. team experimentation

lean management & monitoring capabilities

  1. change approval process
  2. monitoring
  3. proactive notification
  4. WIP limits
  5. visualizing work

cultural capabilities

  1. Westrum orgnizational culture
  2. supporting learning
  3. collaboration among teams
  4. Job satisfaction
  5. transformational leadership

Quotes I liked

A successful measure of performance should have two key characteristics. First, it should focus on a global outcome to ensure teams aren’t pitted against each other. […] Second, our measure should focus on outcomes not output: it shouldn’t reward people for putting in large amounts of busywork that doesn’t actually help achieve organizational goals.

Graph View

Backlinks