I was part of a project where the senior echelons thought software development as a Manufacturing unit. I had my share of arguments in explaining why this is a false premise. Over the years software development practices have made progress across various frameworks like
scaled-agile. All these practices highlight the specific attributes of software development. But I guess, still there are a few people who feel like driving a Manufacturing unit. I would like to share the differences from my observation :
The starting point is often a very big project. The strategy is to split the project into many small parts. Then ask teams to develop each of these small parts in isolation. There is a system architect whose responsibility is to gets these integrated and working as expected. There is inherent problem of reinventing-the-wheel in every isolated team. As a system architect, I have told teams to extract and reuse. The problem is the team member does not clearly understood the requirements of the other service. Thus changes done by him result in delays and bugs on both services.
Project delays happen 1 day at a time.
Alternatively it would have been better to make a milestone based project rather than a fully functional project. But at times I feel like if the stakeholder treats everything as the Minimum-Viable-Product then there is no point in asking them to trim down. I had experiences where a MVP discussion resulted in a bloated requirements.
Often the large project is moved to a location which promises large scale hands. But the problem with Software is borrowing only hands leaves you in a bad position. The hands will not be able to maintain the quality and implement the requirements in the expected manner. Often the large projects have complex logic and connected processes.
Often when we hit delays inn such project the delivery team brings in more hands to the table. The problem is not with hands, but who will supervise these hands. This creates more chaos rather clearing it.
Quality is is a subjective issue in software projects. We try to adapt various practices like TDD and automation, code coverage. On the other hand manufacturing works with sampling. If a sample is not good enough they can throw the created lot. But that is not the case with software, if we dump the system it is complete write off.
At times the
surgeon can be brought with a team, just to improve the chances of the project. But the team had delayed many milestones and are positioned for an epic fall. The
surgeon must pull back everyone from the cliff. In my experience the approach works only if the
surgeon knows the functional domain. He makes the right attempts and fixes the pressing issues. The customer takes a note of the improvements and agrees to provide some more time. But this is more like a rare scenario.
surgeon is trying to the best of his knowledge. But this act creates a league of
spoon-feeders in the organisation. These
spoon-feeders rely on the
surgeon for every possible next step. As a result the
surgeon is often dragged to all possible meetings and discussions. This eats away his day and dragging him further. The more a
surgeon is dragged in these pullbacks, the higher changes are he will leave the organisation. I have seen some
surgeons absconding the org.
In summary we loose a lot instead of making any gain.
It is needless to say the companies invest a lot on getting the right person. Hiring is a time consuming ask. If the project work makes your better people leave the organisation then it is a major loss.
The Manufacturing unit thinking does more harm than any good. It had pushed my teams to the edge. As a senior member of the development team, I own the responsibility of challenging this thinking. This often lead to conflict but then if every time we are agree with the PM then we are just hands for him. The lower quality and delays have cause stress and anxiety.
If the project sponsor thinks like this then be prepared to have spilt-milk.
PS : I have been in software development and these are my observations for Manufacturing. Please pardon my limited knowledge.