Chapter 7: Management Practices for Software
Background: Management Paradigm Evolution
- Project/program management (PMI, PRINCE2) dominated for decades
- Agile Manifesto (2001) → Agile methods gained traction
- Lean ideas from Toyota’s manufacturing system applied to software
Toyota’s approach: solve the problem of creating wide variety of cars for small Japanese market. Relentless improvement → built cars faster, cheaper, higher quality than US competition. US auto industry survived only by adopting these ideas.
Lean software: Mary and Tom Poppendieck’s Lean Software Development.
Three Components of Lean Management
Researchers modeled Lean management with three components:
- Limiting Work in Progress (WIP) — using WIP limits to drive process improvement and increase throughput
- Visual displays — showing key quality/productivity metrics and current work status (including defects), visible to both engineers and leaders, aligned with operational goals
- Monitoring for business decisions — using data from application performance and infrastructure monitoring tools to make business decisions daily
WIP Limits — What’s Actually Being Measured
Not just “do you have WIP limits?” but:
- Do WIP limits make obstacles to flow visible?
- Do teams remove obstacles through process improvement?
- Does this lead to improved throughput?
WIP limits alone don’t strongly predict delivery performance — only when combined with visual displays and production monitoring feedback loops.
Visual Displays — What’s Actually Being Measured
- Are dashboards used to share information?
- Are kanban/storyboards used to organize work?
- Is quality/productivity information readily available?
- Are failures/defect rates shown publicly?
- How easily accessible is this information?
Central concepts: types of information displayed, how broadly shared, how easy to access. Visibility and high-quality communication are key.
Lean Management Impacts
These practices together:
- Decrease burnout (see Ch. 9)
- Lead to a more generative culture (Westrum)
- Improve software delivery performance
Change Management: The Surprising Finding
Every organization has some change management process. Research examined four scenarios:
- All production changes approved by external body (manager or CAB)
- Only high-risk changes require approval
- Peer review manages changes
- No change approval process
Results
| Approach | Impact |
|---|---|
| External body approval (all changes) | Negatively correlated with performance |
| High-risk-only approval | Not significantly correlated with performance |
| Peer review | Higher performance |
| No approval process | Higher performance |
External approval is negatively correlated with lead time, deployment frequency, and restore time. It has NO correlation with change fail rate. So it makes things slower without making them safer.
“Approval by an external body simply doesn’t work to increase stability of production systems — but it certainly slows things down. It is, in fact, worse than having no change approval process at all.”
Why CABs Don’t Work
Software systems are complex. What are the chances that an external body, not intimately familiar with system internals, can review tens of thousands of lines of code by hundreds of engineers and accurately determine the impact on a complex production system?
This is risk management theater — checking boxes so when something goes wrong, we can say we followed the process.
Recommendation
Use a lightweight change approval process based on peer review (pair programming or intrateam code review), combined with a deployment pipeline to detect and reject bad changes. Works for code, infrastructure, and database changes.
What About Segregation of Duties?
In regulated industries (PCI DSS, etc.), auditors often require segregation of duties. This can be satisfied without a CAB:
- Someone who didn’t author the change reviews it — before or immediately after commit (same team is fine). Record approval in GitHub (PR approval) or deployment pipeline.
- Changes only applied via fully automated process (deployment pipeline) — all changes must be committed to VCS, validated by build/test process, deployed via automated pipeline.
Result: Auditors have a complete record of every change — what changed, where it came from in VCS, what tests ran, who approved it and when. A deployment pipeline is particularly valuable in safety-critical or regulated industries.
The Right Role for External Oversight
External teams should:
- Monitor delivery performance
- Help teams improve by implementing known good practices
- Play a governance role, not an inspection role
“Rather than inspecting changes, they should help teams implement the practices known to increase stability, quality, and speed.”