As part of many SDLC framework planning phases, tasks are estimated and then engineers are assigned those tasks depending on how much work load they have. Those engineers with free time will pick up extra tasks until their hours for the sprint are filled. If implemented poorly, these frameworks commoditize engineers, remove accountability and responsibility, and indirectly reduce happiness, all of which are detrimental to a project. Let me explain.
First, not all engineers have the same proficiency. But let’s put that aside. Now, any reasonably-sized code base means that engineers will have a deep knowledge of some parts of the code but only vague knowledge of other parts. The expert in an area will be able to implement a feature 2x, 3x, maybe even 5x times faster than an engineer not familiar with that part of the code. Anytime the engineer is unknown, the time estimate of a task becomes much less precise. If you counter this by saying you don’t have experts in your organization and that everyone owns the code equally, you’re wrong. Even if this is your policy, there is always a natural drift for people to specialize and revisit code areas in which they are familiar. Most importantly, when an organization is structured to have fungible engineers without areas of expertise, you lose accountability and responsibility, and indirectly you lose happiness.
Engineers are efficient creatures and they hate wasting time. This is great for the company. Engineers also like to please and receive praise for their work, who doesn’t?! However, some side effects arise from these two things that all managers, team leads, and scrum masters should be aware of: hacky code. Hacky code is perfect for one-time demos, proof of concepts, or for changes to a code base that is known to end of life. However, for a code base that intends to live on for years, hacky code will slow down development in the long run and create defects, often very difficult-to-diagnose defects. Engineers will produce hacky code under certain conditions: they are lazy (beware this engineer) or if it is much faster to produce compared to a clean fix and either management is pushing hard for a quick fix or they have no responsibility for that part of the code. In this case, the engineer will make the hacky fix, receive praise for solving the problem quickly, and move on. This tendency towards hacky code is doubly true when the engineer is not familiar with a certain part of the code and is not responsible for it. Why would an engineer create a bigger change, which carries higher risk (greater chance for bugs), spend more time doing it, and more time testing it, when he can do it quickly? He wouldn’t unless he was responsible and accountable for that feature and knew that he would be making changes to that code for months or years to come. There is a common, though diminishing, belief that code should not be owned, and while fundamentally true (everyone should be able to contribute to any code), this idea has been taken too far such that no one is responsible for anything; only teams claim responsibility. An examination of the source code shows that a no-ownership policy results in poor code. In sum, fungibility creates poor code.
Finally, an indirect, but perhaps the most important aspect, is happiness. Scrum inventor Jeff Sutherland outlines the three points of happiness as autonomy, mastery, and purpose. While you can try to emphasize that what matters is how the team performs (and in fact it is more important), people crave individual praise and purpose. By owning, i.e. being accountable for, a component of the project, one can be proud that their component was delivered on time and functions flawlessly. They are happy to say “I, and I alone, was responsible for creating that feature”. We all know that how the team performs is more important. However, happiness is derived from owning something (autonomy), being the go-to person for that something (mastery), and seeing that something contribute to the overall product (purpose). In sum, do not disregard the individual. While hearing that the company did well or the team did well is important, it is equally important to hear that *you* did well.
I have touched on a lot of topics, namely the importance of accountability, preventing hacky code, and happiness, and how they relate to engineering fungibility. The worst side effect of fungible engineers is the loss of accountability, which in turn leads to hacky code, and believe it or not, less happiness. Teams are immensely important but do not diminish the individual in praise of team. Do not commoditize work. Do not make engineers fungible.