Treat your developers like interchangeable cogs in a wheel, and the quality of your project will fall.
In the late 1890s Frederic Taylor came up with the idea of Scientific Management.
To get more out of people treat them like machines.
(spoiler : it does not work)
Manufacturing bosses loved this idea, and the practice was widely utilised until the 1980s. Unfortunately the result of getting more product per person was that the people made a lot of rubbish. The reliability of a 1970s car is nothing compared to the life of a modern car, an average 9 years in 2000 as compared to just over 5 in 1970.
For over 20 years I have been developing software and one of the main causes I have seen for projects going wrong is the failures to implement Demming Principle 12a.
Remove barriers that rob people of pride of workmanship
Company owners and managers do not usually have the skills needed to create software. So they delegate the creation process to software specialists. In order to delegate successfully you need to delegate the following four areas to an individual.
Authority : Decide how it gets done
Responsibility : Management of how it gets done
Accountability : Reward for successful completion
Ownership : Boundaries to the scope work
Treating developers like interchangeable cogs undermines their Authority and Ownership, and blurs the Responsibility and Accountability of any task. As a result the delegation process fails.
If you really want to crash a project, use pair programming for day to day development. This technique is only suitable for knowledge transfer, it destroys all the principles of effective delegation.
The Demming Principles helped manufacturing move from a world of Quality Control to Quality Assurance.
Quality Control : Make lots of things, keep the good ones and throw away the bad ones.
Quality Assurance : Work out why we make bad things and stop doing it.
Quality Assurance is something that I never seen in the world of software development. We always use Quality Control, the testers look at out programs and when it does not work, we rewrite it. We spend the development money twice.
These are great tools for tracking the huge complexity of tasks involved in software development. But there incorrect use by managers is the biggest factor in treating developers like machines with all the resulting project failures.
The most successful projects have clear boundaries and people allocated to each area. In the successful projects I have worked on, team leaders manage the process they do not Manage the Board.
Tracking story points and making decisions based on velocity breaks Demming Principle 11
Eliminate numerical quotas for the workforce and numerical goals for management
But that is a story for another day.
Most developers are Clever, Motivated and Productive people. Please don’t destroy any of this valuable resource by using management techniques from the Victorian period of the industrial revolution.