People: Respect and Acceptance

Taylor’s centralized knowledge teams

A development team is not usually organized like a team in the strictest sense of the word (assembled by peers with equal rights), but is more like a hierarchy. The typical hierarchy in a development team, which can be found mainly in traditionally led projects, follows Taylor’s theoryTaylorism is characterized by the division of labor, repetitive operations, extreme labor discipline, and the supervision of work. about centralizing a team’s knowledge. The individual team members take up specific roles and corresponding tasks. Analysts, designers, developers, and testers often work independently of one another in a linear process.

Due to this separation of tasks and roles, a hierarchy is created. Although this hierarchy might not officially exist, it is formed by the different roles in the team, some of which have greater prestige or importance (acceptance level) than others. Often, the acceptance level is defined by linear development. This means that analysts have the highest acceptance level, whereas coders, testers, and, even worse, maintainers, are at the end of the acceptance level chain, doing all the “dirty” work. This sequence of acceptance levels is just one example, but is an oft-encountered one.

However, the major problem is that nobody wants to be at the lower end of this acceptance-level chain. Therefore, everybody tries to climb up the ladder from maintainer to designer or, even better, to analyst. Or, if we look at it from another perspective, we’ll find the largest percentage of novices in maintenance or implementation. Consequently, there are often too few experienced coders on a team.