I’m always amazed by how challenging time can be as a concept. It’s often thought of as something malleable, able to be adjusted with the simplest changes. So many teams (and leaders) fail to see it for what it is – a fixed resource. There are three common ways that teams often misuse the concept of time.
Myth 1 - Time is adjustable
I recall multiple times in my experience where management needed a release to finish more quickly. Despite developers explaining the amount of time required for the work, the company pushed that the features must be ready sooner. In one case, a project manager announced they had found a way to make everything work; the deadline was achievable. I was skeptical.
Reviewing their plan in Microsoft Project, I noticed the flaw: the project manager had simply moved the milestone date and let Project recalculate. The manager believed (rightly) that developers will generally try to do what’s best for the company. This led to an incorrect assumption that they would “step up” to the revised plan. This had three flaws:
- The plan was missing holidays, weekends, and workdays – so it incorrectly assumed 24x7 work availability. A need for excessive work hours often highlights mismanagement and general leadership problems. A forced-march over nights, weekends, and holidays indicates a disregard for the health and personal lives of the employees. Expect high attrition!
- Moving the dates did not change the time required for dependencies. This increased team frustration as the number of “missed dates” began to increase. Productivity dropped dramatically.
- As the number of worked hours increases beyond 32, the productive capability per hour decreases. Developers fight mental fatigue. Beyond 40 hours, they also fight burnout. At 50 hours, productivity drops and errors increase significantly. After 55 hours of work, continued efforts are pointless. In fact, after several weeks at this level, teams will produce less than if they worked 40 hours each week!
Quality work requires time. Simply decreasing the available time reduces quality (increasing rework) and can lead to mental and physical exhaustion (decreasing the amount of work produced). How should the team have handled this situation? First, management needed to accept realistic expectations. Second, the combined group needed to look at faster, smaller iterations. This would have allowed them to release features more rapidly, allowing the customer needs to be met sooner. It also would have advised the teams as to whether they were building the right product!
Myth 2 - Time is a metric
During the pandemic, I learned to make crumpets. I can cook four at a time using two pans; each pan needs 16 minutes. As an average, that’s one crumpet ever 4 minutes. Treated as a metric, it’s easy to assume that I can increase my productivity 25% and reduce the time to 3 minutes. It’s easy to see in this example that this is untrue. At the same time, teams frequently do this in development with the same results. They finish early (to meet the metric), but the product is unfinished (and unpalatable). In addition these approaches ignore two factors required to improve the speed in a measurable way:
- Additional resources are required (the pan). To go faster and preserve quality, resources must be available, trained/able to contribute, and able to work on the task in parallel.
- The maximum productivity is fixed (my stove has 4 burners and there’s no room for a second stove). As the number of participants on a single problem increases, communication overhead and overlapping work reduces productivity. There are also practical limits to how many people that can modify the same code concurrently. This is why the optimum team size is typically 4 to 7 people.
This has an additional side effect: mental stress. Developers will generally try to provide the best work possible. Creating lower-quality work adds stress. Having to deliver against an unrealistic goal that cannot be achieved creates further stress (and resentment). Over time, this leads to developers becoming frustrated and resigning … taking their knowledge and skills with them.
Myth 3 - Resources beat time
This is a variation based on not understanding maximum productivity or capacity constraints. It’s so common that throughout the software industry we use the same analogy:
A project manager meets a pregnant woman. She wishes her pregnancy could complete sooner; she doesn’t want to wait nine months for the baby. “No problem!”, announces the project manager. “I’ll just bring in two more women to assist, and we can complete the project in three months!”
When there is a fixed constraint, it creates a maximum limit. That is, it is impossible to create more product (or deliver faster), even with additional resources. While we can sometimes deliver iteratively, that is not always the case. There are some challenges that can only be solved with time.
This brings me back to the limit on maximum productivity I mentioned in Myth 2. It’s a variation on Brooks’ Law (from the Mythical Man Month):
Adding manpower to a late software project makes it later.
Time and people are only interchangeable when the tasks can be distributed among the people and there is no communication between them. The first part naturally makes sense. If we can’t subdivide a task, adding more people increases complexity; it does not decrease the time. That second part may requires a bit more understanding. Time and people are only interchangeable when the tasks can be distributed among the people and there is no communication between them. The first part naturally makes sense. If we can’t subdivide a task, adding more people increases complexity; it does not decrease the time. That second part may require some explanation.
Connections and complexity
When you have two or more people, the number of lines of communication increases. With 3 people there are three connections. With four people, there are six connections. Five people have 10 connections. A simple network map makes this easier to visualize.
Mathematically, the number of connections increases based on the number of nodes (people) in a network according to this formula:
As the number of connections increases, so does the amount of communication. If we assume two messages between connections per day, 5 minutes per message, then the total communication cost is:
For 5 people (10 connections), we lose 500 minutes per week, or just over 8.3 hours. For a team size of 9 (36 connections), that jumps to 30 hours. In short, as the size of the team increases, the amount of communication and the time increases as well. Visualized, you can see the impact:
That’s quite the growth curve for such a small assumption! For larger problems, more collaboration time is necessary to reach consensus. That curve grows even faster. This is part of why throwing more people at the problem can actually increase the time required: the collaboration becomes more complex and time-consuming.
Some assume the problem is avoided by eliminating communication, but without collaboration, the number of solutions and implementations increase. Parallel work overlaps, breaking code and creating bugs. This is often seen when teams are managed in horizontal slices (tier). For example, one team implementing a UI and one team implementing services. Each team will implement and make assumptions, and those choices may conflict.
The illusion of time
Time is a resource that must be handled with care. The truth is that there is no way to guarantee the time required for a task. Any number of issues, unexpected circumstances, or delays can arise. As a result, the best we can do is to try to rapidly and iteratively create value. That minimizes the total time required, allows the work to be verified as it is completed, and reduces the chances of rework. By honestly approaching the problem and ignoring the myths, you’re more likely to find healthy solutions.