Overview of the Four Work Types of DevOps

The Four Work Types of Devops

The 4 Work Types

The 4 work types of DevOps is a concept that was first popularized by Gene Kim and others in their modern fable of IT called ‘The Phoenix Project’. 

The Phoenix project is a short easily read novel, in the spirit of a Lean classic called ‘The Goal’ by Eli Goldratt.

The Goal was published in 1984 during the height of the crisis in western industry brought about by the Japanese adoption of Lean manufacturing, and their resulting dominance. It was designed to show business how they could address that situation.

In a similar manner the authors use the Phoenix Project as a vehicle to bring out certain aspects of Lean, reflected in IT.

One of these aspects is a concept known as the four work types of DevOps

Three of these four work types were well identified by the authors, while one was left somewhat vague, with the result that it gets interpreted differently by different people.

We will now give you our interpretations of the four work types of DevOps and the reasoning behind them.

Shaping versus engineering

Before we get into the Work Type definitions, it is useful to review a related concept, that of Shaping versus Engineering.

An image showing the split of work in the SDLC between shaping activities, which are upstream of the READY point, and engineering activities, which are downstream

This SDLC can conceptually be broken into two sections, which for the sake of simplicity we label ‘Shaping’ and ‘Engineering’.

The activities in ‘Shaping’ are concerned with getting work to a state where it can be worked on by scrum teams; a designation we call ‘READY’. 

Activities in Engineering are concerned with the creation of working software, a designation we call DONE.

Shaping is everything left of the line of READY, and Engineering is everything right of the line, up to and including the release point.

Right of the line is where Scrum teams sit.  As do specialists like DBAs, Network Engineers, and the like.

Such roles have different footprints when it comes to their engagement with software change, but they will all be involved to some extent or another with working on the 4 work types, so let us move now onto those.

Naming conventions for the four work types of DevOps

First up, let’s look at naming conventions.  The Phoenix project named these 4 types as being projects from the business, projects from IT, maintenance, and unplanned work.

These names can be confusing. The word ‘project’ means different things to different people and in many companies, there is a differentiation made between projects and other types of change, based on size or complexity. 

An image showing that the four work types of DevOps are conceptually located in the Engineering portion of the SDLC, downstream from the  line of READY

So, for the sake of clarity, we have renamed the first two of the four work types of DevOps as being ‘Work from the Business’, and ‘Work from IT’.  These categories refer to any kind of plannable change initiated from those two sources irrespective of size, cost, or any other attribute.

The third work type is the one that was poorly defined by the authors, and we will loop back to that in a minute.

The fourth work type is unplanned work. This one is easy to understand. It means anytime we get interrupted and have to do something because there is an immediate issue.

In effect, unplanned work relates to incidents or any other kind of recovery work. 

But we draw a distinction between unplanned work and work that people might suddenly want. 

The latter is not unplanned work; it is just plannable work that is poorly planned.  These distinctions become important when we are working to change mindsets in organizations away from the old ‘Push-work’ mindset and towards the new ‘Pull based on value’ mindset.

An allocation of capacity for unplanned work must not be used as an excuse to jump the queue for someone important who has a new shiny that they suddenly want polished.

Which brings us back to the third work type.  We have covered off all plannable work under types 1 and 2, and all unplanned work under type 4, so what is left? 

The only work left that people do is routine operational work and support.  So, we have renamed type 3 from ‘maintenance’ to ‘Unavoidable routine work and support.’

Even full-time roles like scrum teams have some degree of routine work they engage in.  This is work that not related to change, so it is not type 1 or 2, and it is not related to incidents, so it is not type 4; Type 3 is what we do to keep the lights on. Such work typically happens at regular intervals, most commonly daily.

Another aspect of type 3 is support.

If IT personnel are routinely involved in support when it is not a defect in the system they are responding to, then this is an indication of a poorly designed system, or one that has not properly invested in user-accessible help. 

It is commonplace in organizations for previously manual business rules to be automated, and then after a relatively short period of time, understanding of these rules in the business is lost. This happens because of attrition and lack of training in the business.  When this situation occurs, IT becomes the repository of business rules, and IT units end up doing business support.

Plannable versus unplannable

In the context of Shaping and Engineering we can draw another line, this time horizontally, Plannable work occurs above the line, and unplannable work occurs below the line.

Plannable work is work that is adding new value to the organization.

The key insight for understanding plannable work is that it must all be prioritized as a single queue.  When we do not do so there are two potential effects. 

The first is that investment in IT is starved. When this happens, we run into problems when new work from the business does not have suitable IT infrastructure to be robustly deployed. Suddenly small and justified business changes can wind up escalating in cost as projects are loaded up with emergency costs for IT infrastructure.  The result is that company budgets are blown, or valuable business changes are side-lined because they cannot be afforded.

The second effect is that work is delayed beyond initial expectation. This usually occurs when a business project is delayed by a hidden IT project that was proceeding without transparency, and which has either consumed resources or locked systems for purposes of change.

To avoid these effects all plannable work must be prioritized in a single queue with input from both the business and IT in identifying and prioritizing work.  Sufficient investment must be allocated to IT projects to create a minimum level of infrastructure, aligned to business priorities.  This effect, in the Scaled Agile framework, is known as creating the ‘architectural runway’, for projects to land on.

Unplannable work does not add new value to the organization. Unplannable work is defending the value we have already created. It is the interest that we pay on keeping the lights on.

Moving investment to plannable work

With this view of plannable versus unplannable work, it follows that If we can reduce the amount of time and cost that we spend on work below the line, then there will be more resources available for above the line.

In type 3, routine operational work can be reduced through automation.

Support work can be reduced by designing systems that are user-centered in their design and properly supported by training and training material. 

Plannable work initiatives and type 1 in particular need to allocate resources to provide these when making change. When this doesn’t happen, it creates a form of technical debt that eventually ends up reflected in support costs.

*Note: this material is excepted from The Visionate Academy foundation for Lean, Agile and DevOps and makes references to other material which is part of that foundation.

Want to know more about DevOps? Check out our related courses.