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).