The Four Types of Software Work

Introduction

Taiichi Ohno’s Toyota Production System had a profound effect on me. His methodology is as applicable to software production as it is for car manufacture. However, there’s an intentional difference: whilst all work has an element of innovation (such as innovating for continuous improvement) the problem that cars are trying to solve is pretty much settled. That’s not true for software; much of the challenge of software development is making sure the right problem is being solved. This blog post attempts to extend Ohno’s work into modern software development by introducing a new concept of Discovery.

All product and technology work can and should be categorised into 4 types:

• Core

• Project

• Excellence

• Discovery

Whilst we vary the types of work we do within a sprint and according to the team, we need to maintain an acceptable velocity across all 4 types over the course of a quarter (or other programme increment) in order to have a sustainable pipeline of delivery. We must make sure we’re doing enough of each type otherwise we will fail.

Note: It’s important to apply all four types of work to customer-facing product features as well as the internal systems that enable the work.

Definitions of Types of Work

Core Work

Hyōjun sagyō (標準作業): Working within the current best method. Keeping the product and codebase healthy and running.

• Maintenance: Dependencies, patches, infrastructure

• Unplanned work: Incidents, urgent issues, escalations

• Quality work: Bug fixes, tech debt, refactoring, test improvements

• Optimisation: Performance improvements (both user-facing and internal)

Characteristics: Work that maintains or improves the existing system. Core should be measured as Planned and Unplanned Core; Unplanned Core has the biggest impact upon the velocity as interruptions destroy flow and therefore productivity. As lean puts it: “Today’s Core work is the shadow of yesterday’s Project and Excellence work”. Conversely, underfunding Core detrimentally impacts Project and Excellence. Core is the true constraint in most software engineering organisations.

Project Work

Kaikaku (革新): Radical or breakthrough improvement. Planned work to expand product capabilities or validate strategic bets.

• New features and products

• Significant expansions of existing features

• Building validated solutions from Discovery

• Strategic initiatives (platform moves, market expansion)

Characteristics: Finite scope, clear success criteria, cross-functional. Project work is inherently larger-batch, which is why it must be planned and time-boxed. Projects add Core Work downstream (maintenance) and often require Excellence work to sustain them.

Excellence Work

Kaizen (改善): Proactive, systematic enhancement. Investing in how the team builds and operates.

• Developer experience: Tooling, CI/CD, development environments

• Capability building: Training, documentation, knowledge sharing

• Process improvements: Retrospectives, ceremonies, ways of working

• Observability and operability: Monitoring, alerting, debugging tools

• Characteristics: Work that improves the team's ability to do all other work.

Characteristics: The line between Core and Excellence is intentionally blurry; continuous improvement should be everyone's Core work but Excellence makes it explicit, time-boxed and budgeted. Teams do Excellence work as part of their sprint goals. Organisations do strategic Excellence work less frequently but more impactfully, to improve upon tools and processes. Excellence is not gold-plating; investment in Excellence is the smart way to amplify Core and Project work.

Discovery Work

Shikomi (仕込み): Preparatory groundwork. Learning what to build and how before committing. De-risking and validating before execution.

• Problem Discovery: user research, market analysis, problem validation, competitive research

• Solution Discovery: technical spikes, design explorations, prototyping, proofs-of-concept, A/B tests, beta programmes

Characteristics: High uncertainty, learning-focused, throwaway but not waste. Directly feeds Projects. Discovery outputs should be: a decision with a confidence level, a direction to guide subsequent decisions, and a boundary that defines what will not be done. Discovery does not produce deployable output but this is not waste; as Ohno put it, Discovery is “preparation before work”.

Effort <-> Four Types

Whilst there is research on how to apportion time to each type of work, the best practice of others is not necessarily true for us. Every company is in a different stage of maturity, of uncertainty and so percentages will vary. Here’s a starting point for a recently-formed software engineering capability working on a new problem space.

Varying the Allocation

This allocation will vary depending on team and role. Incident response teams will spend much more time on reactive Core work, Research and Design teams will spend much more time on Discovery work. However, no team should reduce any allocation to zero. For example, Incident teams will benefit from Discovery work to identify common sources of reported incidents and instantiate Projects to address these sources. Core work for Design teams is to learn from developer feedback to remove friction points in using their design system.

The allocation will also vary with skill level. We may well find it is better for senior engineers to spend most of their time on Excellence work as a “force multiplier” for the rest of the team. Conversely junior engineers may by necessity spend more time on Discovery work.

Measuring the Four Types

Instead of dogmatically allocating percentages of story points to these types of work, it is more instructive to measure how we are allocating story points as signals for underlying issues:

Conclusions

Teams and leadership must buy into the effort allocation. It’s all too easy to conclude that in every quarter of say 6 sprints we expect to do just over 3 sprints of new shipped Project work. The mistake is in concluding that only Project work delivers business value. The value delivered by all 4 types of work should be measured to be explicitly communicated.