It’s our tendency, as technical people working within a highly technical domain, to overcomplicate matters somewhat.

Take, for example, our software delivery processes.

When developing something solo, or with a team of two or three people, the process overhead tends to be as minimal as possible: pulling items into a shared to-do list, and churning through those items as fast as possible. There’s a joy to it; the euphoria of getting things done, one ticket after another after another after…

Put simply, Agile can be distilled to the Manifesto and the 12 Agile Principles; it’s arguable that following these is perhaps the only mandatory step towards practicing Agile. Join me, then, in pulling apart the first of these Principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Our highest priority. Therefore, everything we do should be centered around satisfying the customer and around the following questions:

• Is the software we deliver providing value to the customer?
• Are we quickly delivering the first version as soon as it provides any value to the customer?
• Do we continue to iterate on the software to add more value at a continuous pace?

Of course everything’s simpler with that two person hackathon mentioned above, and it’s only reasonable that, as the team grows, more processes are required. There’s an overhead to communication; it’s the reason there are diminishing returns to adding additional developers to a team. Processes are developed further, then, to address that communication overhead, usually starting with a framework like Scrum before starting to tailor the process to the individuals in the team.

But, as with code, overengineering can be a problem. Building new contingencies into a codebase just in case they’re needed in future contributes to technical debt. Similarly, tacking on more and more processes just in case leads to a kind of “process debt”.

As with technical debt, process debt can be deliberately taken out to solve a particular issue in the short term, but if time is not put aside to tackle it at some point, the process quickly becomes a giant, hulking, spaghetti mess, slowing down delivery. Consider that team of two suddenly being joined by a number of very junior engineers. In order to reduce the risk of major issues being deployed, an additional code review step may be added before anything is pushed to production. However, over time the junior developers learn, improve, and grow. The additional step may no longer be necessary, but without considering this “process debt” as part of a regular inspect-and-adapt cycle, this step may slow down development for the foreseeable future for no good reason. Indeed, in several years time, should the team be asked why this step exists, the answer could well be “that’s the way it’s always been”!

Of course, this example illustrates process debt taken out deliberately; it’s not too much of a stretch to imagine additional hoops to jump through added simply “because management said so”. How many of these hoops have been around in a given process for several years, with nobody remembering why they were put there in the first place?

Tackling this involves continually adapting our process, in the same way as we refine and adapt our backlog and our codebases to remove technical debt. This is as simple as looking at each step and asking the above questions, but basically in reverse:

• Does this help us to deliver software that’s valuable?
• Does this help us to deliver the first version as soon as it provides any value to the customer?
• Does this help us to iterate on the software to add more value at a continuous pace?

Again, our highest priority is satisfying the customer. It’s a rare customer who cares about how the software was developed. Chances are, they very much only care about the results, and likely don’t even know the steps a development team go through to build said results.

While some process is necessary for the wellbeing of a team, it’s important that it’s applied thoughtfully and reviewed regularly. In moderation, so to speak. Occasionally, it’s worth going back to visit your process in its entirety and asking the right questions about each step we take—trimming the fat, keeping it lean, and taking a little time to tackle that process debt.