Asynchronous Agile 5:

Typical Approaches to Solving for Time

What are the ways we typically try to resolve time problems? There is the appeal to work ethic. Bob, in sales: “Come on guys, work your magic!” This assumes that all the resources in the process are already under-utilized, and by appealing to one resource (the people), they will somehow suddenly be inspired to find and fix those utilization problems. There are several problems here. (1) Even if the assumption of under-utilization is valid, this introduces a new cost, finding and fixing undefined and unknown obstacles. (2) The utilization rate of all resources may already be at its tolerable maximum. (3) It’s almost always insulting to the people in the process. Extensions of this appeal are monetary incentives, or threats. The carrot or the stick. 

W. Edwards Deming in his Marshall Plan-era Total Quality Management made it clear that exhortations for the workforce are non-productive, insulting, and often counter-productive. Like lab rats, workers will tend to “game” the incentives / punishments, and produce units of “work” that maximize rewards and minimize punishments. There’s no reason to assume that this mini-max “work output” aligns with the features end users actually want. There is an apocryphal story of a Russian shoe factory incentivized by production numbers churning out thousands of shoes. All of the same size. And all for the left foot.

A second common attempt to battle time is “project crashing”. From the science of waterfall project management and PERT charts, resources can be added to a segment in order to increase the flow at that segment. This is based on the assumption that a serial task can be made parallel. At best, the increase in output will be 2x that segment per the previous plan, but this is assuming the additional resource is fully trained, fully understands the problem, is completely ready to begin, and the work can be parsed to two people with zero cost. Obviously, this is almost never the case, and it’s worth asking how there could be such a magical ready resource. At best, the addition of one additional resource has an additional payoff lower than 1.0 because there are costs in training, transition, etc. This option is often devoid of benefit, and is more likely to make things worse. In The Mythical Man-Month (1975), Brook’s Law is established, “Adding manpower to a late software project makes it later”. Some things can’t be solved by throwing people at the problem. You can’t take 9 pregnant women and produce a baby in one month.

In the Agile world, work is not generally described by the PERT multi-stage model, so project crashing isn’t feasible (over and above the previously mentioned problems). A mature Agile team is going to account for the stories desired within a sprint, given the choices and priorities represented by the Product Owner. There is no slack available for project crashing, because the resources have already been estimated and assigned as much as possible given the empirical evidence from past work, and the current expectations of the work to be done. We call it “committing” to work, not only because the Dev Team puts their reputation into an agreement to produce it, but also because the resources are committed to doing the work and can’t also be free to do something else.


A third solution is the Geek Bump. This is the technical expression of the adage “a stitch, in time, saves nine”. Though well known, this adage draws a lot of questions. The idea is that stitching a small hole in a fabric earlier prevents the need to repair a much larger hole later. You’ve probably seen this humorous graph before. The idea here is that shifting effort forward in time can save resources at a later (and most importantly) continuing rate. In the graph “Geeks and repetitive tasks” the point is that many repetitive problems consume one marginal unit of resource for one marginal unit of output (or some fixed ratio).

Asynchronous Agile 4:

Temporal Distribution

Thus we arrive at temporal distribution. Because humans are so bound by time, we do a poor job of considering it. We are fish, rarely contemplating the water. We frequently and easily think of distributing objects (everyone on this floor needs paperclips), knowledge (all the new developers need training), and people (one person should guard each door). These types of resources can be moved within their domains relatively easily. If I have two people at checkout register 1, and none at register 2, I can move a cashier. Other resources are subject to improvements in flow, or problems related to flow: traffic, overstocked inventory upstream, starved workstations downstream. Most resource problems involve inventory.

Flow of inventory always has some cadence, either chosen, imposed, or accidental. 

Traffic is an easy example of flow problem everyone has experienced. This often happens due to a desire to improve a local optima over the total system flow. Problems that occur in traffic aren’t necessarily caused by the flow rate, but changes in the flow rate. Despite a highway being posted as a 70 mph zone, the optimal traffic flow during rush hour may only be 32 mph. Unfortunately the minimum flow rate often approaches 0 mph due to changes in the flow rate between vehicles. Drivers try to maximize their speed “when they can” but when they approach slower traffic they must brake safely in such a way that the decrease in speed is a greater loss than the average optimal speed would be (they drop below 32 MPH). Some sophisticated traffic systems post signs with variable speeds, or modulate the flow of on-ramp traffic in order to optimize the total average speed of all cars.

At a four-way traffic light, drivers may attempt to pack the intersection once the light turns yellow. If these cars are unable to clear during the green light in the other direction, then the problem is carried over to the flow of cars going the other way. This leads to those drivers choosing to selfishly pack the intersection to “beat” the problem. Although this strategy may improve the local optima for that one driver, the net effect is reducing the flow of traffic in all directions, for the majority of drivers. The bottom line in both cases is that trying to maximize a local optima, everyone is made worse off.

The most important concept often missing in discussion of flow is the idea of a “bottleneck”. While more well known in Japan, and within Operations Management fields, bottlenecks are not discussed as frequently in US management culture, or in fields that don’t specialize in supply chain management. A bottleneck is any step in a series that dictates the cadence of the entire series. As an example, an automotive assembly station may receive 4 tires, 2 bumpers, 1 engine, and 1 windshield wiper every 10 minutes. The pace of the assembly is planned to be 1 vehicle every 10 minutes. But the actual pace is 1 vehicle every 20 minutes. Without an awareness of system flow, management may focus on any one of many variables which do not matter. The robot that lifts the body of the car may be the most expensive piece of equipment. The tire installation may require the most people. The engine placement may bear the highest cost risk. It can be easy to focus on a fancy machine, assume there is too little (or too much) costly labor, training may be considered inadequate. Threats or begging usually occur. But the humble windshield wiper delivered at half the necessary rate is the source of the problem. The cause of the bottleneck in this example may be the lowest cost item, but could be causing half the rate of sellable goods. The individual biases of each person will lead them to troubleshoot according to the factors that they notice. Any costs incurred on any step that is not correcting the rate of windshield wiper delivery is a waste!

Every process has one true bottleneck. There may be many points along the process that change the rate of flow. Anywhere you see an email inbox piling up is a bottleneck. A Dev Team that is waiting for stories to work on is downstream from a bottleneck at the Product Owner. But in every end-to-end process, only one stage will be the rate constraint on the whole system. For a much more in-depth understanding of bottlenecks and flow, I highly recommend The Goal, by Eli Goldratt. His Theory of Constraints is much like chess, easy to understand but a lifetime to master. The book is a short novel with an entertaining story.

Time is unlike the other three resources discussed. Time is both the resource and the domain within which that resources resides. We cannot move, rush, or slow down time. We cannot store time in inventory. Because we can’t move time, Temporal Distribution really consists of moving other resources between periods of time. If we are lucky, we can move resources from times that have reached their bottleneck on productivity to other times which allow for more productivity.  

Asynchronous Agile 3:

Time as a Unique Resource

Because all inputs are human modulated, they are all subject to the one key resource – Time. Humans are inevitably a slave to time. Therefore, time is really the ultimate resource. And it is unlike other resources. Sometimes you can “crash” a project by adding people, you might increase heat, or the flow of a chemical, deliver two trucks of cement instead of one. But you cannot add time. Extending the delivery date of work is not the same thing as adding more time, because you can’t increase a quality of the delivery by increasing the time invested, the relationship is the opposite. “Adding time” in the sense of delaying the delivery date is decreasing a factor of quality that describes the work.

Asynchronous Agile 2:

Modulation by Humans

What do I mean by modulation? In electronics, modulation is control over the flow of an output. A transistor controls the output of an amplifier using a tiny input signal. A modulator controls a radio antenna. Your thumb controls the output of your garden hose. Whether inputs are physical goods, services, or lines of code, almost all input resources are modulated by the activity of some human being doing some kind of activity. In the case of code, a person has to consider a problem, plan a solution, write the code, test it, and release it. Some of these processes can be automated, like the testing, integration and release phases. Even those automated steps are human modulated at their inception. Some inputs could come from the natural world, like water or trees, but they aren’t part of our process until human intervention turns them into meaningful resources. For simplicity, I’m going to talk as if all inputs are human modulated.  

Asynchronous Agile 1:

“I wish it need not have happened in my time,” said Frodo.
“So do I,” said Gandalf, “and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us.

― J.R.R. Tolkien, The Fellowship of the Ring

Temporal Distribution in the World of Human Modulation

My goal here is to kick off some thought about ways Agile works within certain time constraints, and how it is hampered under a different set of time constraints. But my larger goal is to spur consideration about time as a resource. We’ll close by focusing on some ways to extend the benefits of Agile with concrete techniques to survive and even thrive outside the boundaries of the traditional work day.

Everyone in the IT/CS world is familiar with the Iron Triangle, and almost everyone has some familiarity with Agile SDLC. What the iron triangle, Agile, and even traditional waterfall project management techniques do, in essence, is to organize thought around input resources which create an output product. The resources may differ (bricks, people, lines of code) but they will almost always have two factors in common. (1) They are all modulated by a human. (2) They are all subject to the one overarching constraint – Time. We can look at any process as four essential types of resource: People, Knowledge, Materials, and Time. Developers (people) write code on computers (materials) using their programming language (knowledge) within a workday (time).

%d bloggers like this: