The Busy Trap: How to Distinguish Being Busy from Being Productive
5 Myths of Productivity
In our last blog,
we explored what types of productivity exist. In the realm of software development, a gap exists between perception and reality, particularly regarding where work items spend their time.
We are quite confident that the gap exists because we ended the article with a poll on where people think work items spend time. At the time of the writing, only 30% of people agreed that the most time is spent waiting for something to happen, i.e., in a queue.
Most people think that the work items spend most of their time on some activity. Let’s bust this myth and present evidence that challenges these beliefs based on some of the case studies we have done at Incubyte for our clients.
Myth 1: Active Development and QA Consume the Most Time
A prevalent belief in the business world is that the lion's share of a work item's lifecycle is consumed by development and QA activities. However, our case studies reveal a different scenario. We find that a significant portion of time is actually spent waiting in various queues, such as "Ready for QA" or "Waiting for Release." This idle time often turns what could be days of actual work into weeks of waiting, highlighting inefficiencies not in the work itself but in the process.
Here is one of our case studies. You can see how, on average, work spends six-plus weeks awaiting production deployment; typically, developers and QA get it developed and tested in under four days each!
Let’s call out every status of a ticket that looks like a queue.
In my previous blog about decoding developer productivity, I came across a comment that claimed programmers are the biggest bottlenecks of an organization.
While it's true that managers often prioritize measuring programmer productivity due to their crucial role in achieving organizational goals, it's an oversimplification to suggest that programmers are always the bottleneck.
Myth 2: More Planning Equals More Productivity
The following graphic is from a team where product managers front-load the issue creation.
Once again, productivity does not improve in these cases. Now, tasks linger for too long in the "To-do" and the following queues. This can also lead to higher team anxiety because they're always looking at a long list of undone work.
The ticketing system exhibits that the subsequent ticket statuses act like a funnel. In a very generic sense, this workflow sounds like:
Generate a lot of work for the future
Select some work for estimation
Commit to an even smaller subset
Deliver even less!
Once again, it takes more than ten weeks to deliver some five days’ worth of hands-on keyboard work! The only thing you are assured of is everyone is busy here! That’s a great segue to our next myth.
Myth 3: Individual Busyness Implies Productivity
The notion that staying individually busy equates to team productivity is another myth that our case studies debunk. By shifting focus from individual tasks to collaborative efforts aimed at unblocking colleagues, teams were able to significantly reduce lead times for changes. This approach emphasizes that collective productivity and removing bottlenecks are more beneficial to project timelines than merely keeping every team member busy.
Take pull requests (code review requests) for instance. Once a PR is raised the developer would typically start working on something else while the PR waits for code review for days or weeks! Of course, the developers stay busy in this case, but team’s throughput does not increase.
Myth 4: Parallelization Boosts Productivity
When poorly executed, parallelization can actually hinder productivity instead of enhancing it. This often happens because it leads to an increase in Work In Progress (WIP), which, without a solid architecture, effective team structures, and efficient deployment strategies, results in bottlenecks within various stages of the Software Development Life Cycle (SDLC).
For example, see the above graph, when developers and analysts work too fast. They end up creating multiple items that sit in “Development Done” and “Ready for QA” buckets. It’s nothing but an indication that more work is getting done than can be tested!
Myth 5: Pull Requests, The Ultimate ROI Booster?
Pull requests (PRs) have become a staple in the software development process; they may be spanning teams and even oceans. Yet, as the quantity and bulk of PRs increase for each developer, the sacred rite of code review often dwindles to a mere checkbox exercise—ring any bells with "LGTM"?
Dragan Stepanović delivers a great presentation, rooted in thorough research, revealing the potential of PRs to throttle your organization's productivity. His talk is a must-see to understand how to make your PRs effective and fast.
Conclusion
Our deep dive into productivity myths versus realities, bolstered by Incubyte's case studies, reveals a stark truth: busyness does not equal productivity in software development. The eye-opener from our poll—that only 30% of respondents recognize the bulk of a work item's lifecycle is spent waiting—highlights a critical misunderstanding about the nature of work.
The real bottleneck isn't in doing the work but in the waiting—queues that turn days of development into weeks of delay. This insight shifts the focus from individual busyness to process efficiency and the smooth flow of work from start to finish.
Our findings debunk the myths that more planning, parallel tasks, and pull requests guarantee better outcomes. Instead, they emphasize the need for streamlined processes and effective collaboration to enhance true productivity. Let's prioritize making each moment count towards faster, more efficient delivery, moving beyond mere activity to meaningful progress.
Stay tuned for the next couple of blogs where I will be covering the strategies that can be applied across the SDLC to improve software delivery.
Feel free to check out previously published articles-
