- Description
- Ancien établi de menuisier en bois, avec ses étaux à vis et ses outils posés dessus.
- Source
- Лапоть · original page
- Licence
- CC0 Public domain
Developer Experience and Flow
This theme measures the smoothness of a developer's work and the flow of changes within the team: wait times, short feedback loops, controlled cognitive load, work in progress…
In brief
This theme measures the smoothness of a developer's work and the flow of changes within the team: wait times, short feedback loops, controlled cognitive load, limited work in progress. It should be read as the cumulative effect of the other themes on people: a productive developer is one who waits little, understands quickly, and can act independently.
Level: 🟢→🔴 · Theme code: DXF (DL matrix)
Why this theme#
Productivity is often measured by activity (lines, tickets, hours), which is a poor indicator: teams can be very busy while delivering little. The SPACE framework (satisfaction, performance, activity, communication and collaboration, efficiency and flow, 2021) encourages measuring multiple dimensions rather than just one. Research on developer experience (DevEx) highlights three levers: feedback loops (speed of tests, reviews, builds), cognitive load (complexity to understand before acting), and flow state (interruptions, focus time).
On the flow side, work in progress (WIP) is the main enemy: the more items started simultaneously, the longer each one takes to finish (Little's law). Limiting WIP shortens end-to-end lead time, reveals bottlenecks (generally: review, acceptance testing, waiting for an environment), and reduces context switching. The platform team type (Team Topologies) aims to make these internal services (environments, pipelines) “self-service.”
A cautionary note: this theme is the one where Goodhart's law hits hardest. Any individual productivity measure gets gamed; the measures here are diagnostics for the team and system, never evaluations of people.
What the theme measures#
- Axis: from “we fight the tooling” to “the tooling fades into the background; time goes to problem-solving.”
- Key indicators: local loop duration (change → see the result); review wait time; flow efficiency (share of lead time spent in active work, not waiting); WIP per person; reported satisfaction (short survey).
- Unit: seconds/minutes; hours; %; count; score from 1 to 5.
Five-level table#
| Level | Short name | Promise | Typical indicator (orders of magnitude) |
|---|---|---|---|
| 1 | Endured | The developer copes with tools as they are, often at their expense. | Workstation setup in days; local loop in tens of minutes |
| 2 | Equipped | A new workstation is operational in one day and core tools are maintained. | Workstation in < 1 day; local loop < 5 min |
| 3 | Fast | Feedback on a change (test, review, build) comes in minutes, not hours. | Local loop < 1 min; review < 1 day; CI < 15 min |
| 4 | Smooth | Work flows: little waiting, few interruptions, little work in progress. | WIP limited; flow efficiency > 30-40%; self-service environments |
| 5 | Optimized | Obstacles are continuously identified and removed; the team spends most of its time on value. | DevEx survey tracked; obstacles resolved in < 2 weeks |
Milestones by level#
| ID | Milestone | Verifiable evidence |
|---|---|---|
| DL-DXF-1.1 | Required tools are provided to each developer | Standard tool list |
| DL-DXF-1.2 | Access (repository, environments, tracking tool) is granted in < 1 week | Lead time measured for the latest newcomer |
| DL-DXF-1.3 | Major pain points are known (tooling issues list) | Commented list |
| DL-DXF-2.1 | Workstation is operational in less than one day (script or procedure) | Measurement on one new joiner |
| DL-DXF-2.2 | Local build and run require no hidden knowledge | Third-party test |
| DL-DXF-2.3 | Development environments are reproducible (local database, test data) | Rebuild in < 1 h |
| DL-DXF-2.4 | A help channel exists, with response in < half a day | Measured lead time |
| DL-DXF-3.1 | The local loop “change → see the result” takes < 1 minute for the common case | Stopwatch on 5 cases |
| DL-DXF-3.2 | Review wait time is < 1 business day | Median over 3 months |
| DL-DXF-3.3 | The pipeline provides feedback in < 15 minutes, and errors are readable | Duration and survey |
| DL-DXF-3.4 | Repetitive tasks are automated (shared team scripts) | Team tools repository |
| DL-DXF-3.5 | A short satisfaction survey is run at least twice a year | Results and actions |
| DL-DXF-4.1 | Work in progress is limited (explicit WIP rule) | Visible and respected limit |
| DL-DXF-4.2 | The waiting share in end-to-end lead time is measured (flow efficiency) | Flow board |
| DL-DXF-4.3 | Environments and pipelines are self-service (no ticket needed to get one) | Provisioning lead time < 1 h |
| DL-DXF-4.4 | Interruptions and meetings are regulated (protected time blocks) | Team calendar |
| DL-DXF-4.5 | Cognitive load is addressed: starter templates, conventions, shared components | Templates used by ≥ 80% of new components |
| DL-DXF-5.1 | Raised obstacles are prioritized and resolved in < 2 weeks (or explicitly arbitrated) | Obstacle tracking |
| DL-DXF-5.2 | Satisfaction and flow are tracked over time; trends guide investments | Charts over 4 quarters |
| DL-DXF-5.3 | A platform team or role manages tooling as a product, with its internal users | Roadmap and feedback |
| DL-DXF-5.4 | No indicator is used to evaluate individuals | Measurement usage charter |
Detailed reading by level#
🟢 Level 1 — Endured#
- Signs: workstation setup = two days hunting down access; build that works “only on Paul's machine.”
- Benefit: none.
- Does not guarantee: anything — the cost is hidden in lost time.
- Difficulty: 1/5 · Effort: 1/5.
🟢 Level 2 — Equipped#
- Signs: workstation ready in one day, tested procedure, reproducible environments, help available.
- Benefit: fast onboarding; less baseline frustration.
- Does not guarantee: fast feedback.
- Difficulty: 2/5 · Effort: 2/5.
🟡 Level 3 — Fast#
- Signs: feedback in minutes; review within one day; shared scripts. Every second saved on the local loop is multiplied by hundreds of daily iterations.
- Benefit: more experiments, more learning, less discouragement.
- Does not guarantee: smooth handoff of work across people.
- Difficulty: 3/5 · Effort: 3/5.
🔴 Level 4 — Smooth#
- Signs: WIP limit, waiting measured (most tickets spend most of their lead time waiting, not being worked), self-service environments, regulated interruptions.
- Benefit: short, predictable end-to-end lead times; less context switching.
- Does not guarantee: lasting satisfaction — it must be measured and worked on.
- Difficulty: 4/5 · Effort: 4/5.
🔴 Level 5 — Optimized#
- Signs: the team treats obstacles like a product backlog; a platform role serves teams; no measure is used to rate individuals.
- Benefit: continuous improvement in delivery capacity and retention.
- Does not guarantee: product quality — smooth flow of useless work is still useless.
- Difficulty: 5/5 · Effort: 4/5.
Partial achievement and rating#
Apply the rating rule.
- 0.5 on DL-DXF-3.2: median review time at 1.5 days, with high dispersion.
- 0.5 on DL-DXF-4.1: WIP limit displayed but regularly exceeded.
- A partial 5: obstacles resolved quickly, but no trend tracking for satisfaction.
Disguised surveillance tool. Symptom: developers game the indicators or fear them. Cause: individual use (ranking, bonuses). Remedy: explicit charter (milestone 5.4), team-level measures only, qualitative surveys as a complement.
Optimizing a bottleneck that is not one. Symptom: build is faster, lead time does not change. Cause: the real bottleneck is acceptance testing wait time. Remedy: map the flow (value stream map) before investing.
Time the full path of a trivial change yourself once per quarter (one line changed → in production). The number and the expectations it reveals are worth more than a report.
A 6-person team carries 14 tickets in progress; average lead time is 19 days, including 14 waiting for review or acceptance testing. Limiting WIP to 8 and agreeing on review within 24 h brings lead time down to 9 days without speeding anyone up.
A goal of “reducing review lead time” encourages approving without reading. Monitor quality in parallel (escaped defects, 02).
Move to the next level#
Possible means (optional)
- 1 → 2: workstation setup script, procedure tested by the latest new joiner.
- 2 → 3: speed up the local loop (targeted tests, hot reload), one-day review rule, survey.
- 3 → 4: limit WIP, map the flow, self-service.
- 4 → 5: obstacle backlog, platform role, measurement usage charter.
See also#
- Neighbors: 02 Code Quality · 03 Testing · 04 Version Control · 05 CI · 10 Documentation and Knowledge Transfer.
- Other matrices: Project — team and collaboration · Project — continuous improvement · Project — planning and estimation.
- Practice: Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…) · Project Metrics and Reporting · CI/CD: Continuous Integration and Continuous Delivery · AI in Planning and Version Control Tools.
- Glossary · Rating: Reading Ratings, Scores, and the Legend.
✻ Written by Claude Sonnet 5.5
