Breaking The Work Up

Contemporary software projects are managed through a set of principles and abstractions that can be helpful for discretising digital products into pieces and once discretised into pieces, creating something that vaguely resembles a roadmap - a plan for what a project will (or at least intends to) deliver over a relatively long period of timeframe. Putting process norms to one side for a moment this seems to make practical sense. If we are a stakeholder in a project we would want to know what people are working on, how they are going, whether the project is on track for time and budget and to understand possible risks.

The way in which contemporary software projects are discretised into pieces is that they are often broken up in terms of features, or the value that they bring to either the business or to the customer. When I wrote about code I highlighted that the work that software developers to is distinct from the value that customers receive - digital experiences. This has some serious implications for project management given that while experiences may be commodified, the solutions are not.

Today it is common for engineers to be working in what has come to be known as an agile way where they receive a set of items that are intended to be completable within a fixed unit of time, most often two weeks. The idea is that project is in state A at the beginning of a fortnight, the items that are planned for completion represent change set B, and at the end of the sprint the project is in state C i.e. C = A + B. The items are given estimates of effort to deliver. Projects may maintain a buffer of a number of cycles ahead of time as an effort to facilitate discussion to add new considerations in order to maximise confidence in delivery.

All of this sounds sensible and like a real plan for how the project will track, as long as you ignore how the solutions are distinct from the problems. (i.e. the delivery of the features) Taking new user-facing features as an example, engineers are presented with tickets (a project abstraction for an increment of work) which are almost certainly described in terms of a digital experience. They are asked to describe how long it will take to take the current state to the new state. They are often asked to estimate the work before they know what the work is. When this happens, the correct way to manage this is to hold the engineering estimate at this point in time loosely. If there were a point in time where engineers need to be held accountable, these forecasts are certainly not that place. Allow me to illustrate why with an analogy.

Suppose that I am hosting an event for a large group of people and that in preparation for this event we would like to announce that pizza will be provided. I'll now ask my event staff for estimates on much time they believe that they need in order to keep the promise of available pizza for my guests. One staff member tells me they need 20 minutes for pizza to be ready for my guests. That sounds pretty good. Another tells me they need 9 hours, and to meet our deadline the time to start was several months ago. How can this be?

In these two estimates there are quite different conceptualisations of the role that third-parties will play in our delivery of pizza to our guests. It may well eventuate that there is a pizza place near the venue of our event that is able to cater to our needs. It could also eventuate that they (and every other venue nearby) are closed, at capacity or otherwise unable to attend to our needs, in which case we need to fill the gap ourselves, and produce our pizzas through alternative means. How much of the value chain do we really have to take responsibility for? Should we have invested in a wood-fired pizza oven and started growing tomatoes many months in the past in order to meet our forecast timeline? If we firmly commit to an outcome, which is a norm in contemporary software development, then we should be prepared for a broad variance in the time to a solution when we make forecasts, and we should also be prepared for those forecasts to be incorrect, sometimes by an extremely large margin. This becomes even more pertinent when the product that will be delivered is highly specified. Going back to our analogy, suppose that we not only promised pizza to our guests but pizza from Pizza Hut specifically. Suppose also that there is no Pizza Hut for hundreds of kilometres of our venue - perhaps they recently went out of business. We have two options: recreate the entire Pizza Hut value chain ourselves, or break our promise. So in this instance the variance for ensuring we are able to deliver Pizza Hut pizza for our guests could be anywhere from the 20 minutes it might take to receive a delivery from our closest Pizza Hut, to the many months or years it would take to rebuild the Pizza Hut value chain from zero.

If there is a need to measure actual time to deliver a particular outcome in a more accurate way, there is a case for a parallel tracking system that discretises delivery of features in terms of a forecast solution, before then estimating the delivery of that solution. Anything less is to not engage with the reality that the production of code is not directly connected to the delivery of customer or business value.

There is a palpable sense among many engineers that process does not align with purpose. The answer is not to dismiss process entirely as there is no such thing. "No process" is also a process, although one that is much less structured, less commoditised and less well-understood. The principles underlying the agile manifesto are reasonable and well-founded. The ecosystem and some of the practices that have emerged around it are less so. Are we learning? Are we aligned with what we have observed? Our expectations of what could be - are they grounded in realistic assumptions?

Until next time.