From very early age, software engineering has been borrowing heavily from manufacturing industry. We as software professionals has learned a lot from manufacturing systems/concepts such as TPS. No doubt, this has helped a great extent to the success of software engineering profession.
But there is one fundamental issue with borrowing blindly from manufacturing. That is manufacturing queues and software development queues are fundamentally different.
Do we have queues in software engineering???
Queue in this context is the line up of work to be completed. In software engineering, our queues are sprint or product backlog. In manufacturing, queues are the jobs to be performed in a production line.
Manufacturing systems
All (almost) the manufacturing systems are based on “homogeneous queues“. What that means is that each piece of work (job) produced is similar or homogeneous. For example consider a Toyota factory. There will be multiple production lines but one line can produce only one type of vehicle at a time. If the line required to produce another type of vehicle, a considerable downtime is required to for the change.
Software development systems
In software engineering, we can equate a “production line” to the software team and queue to the sprint/product backlog.
Software development teams are never get similar (or homogeneous) type of work. The first user story (or task) is totally different from the second user story. Therefore the software development queues are “heterogeneous queues” as one task is different from another.
What does this mean? Why this difference is important?
This simple difference in queues makes the DIRECT application of some of manufacturing concepts such as six sigma to software engineering is fundamentally flawed. The concepts which work in homogeneous queues do not necessarily work in heterogeneous queues.
For example, six sigma relies on the variance to identify problems in the system. Variance can only be tracked when the work is repetitive. I.e. when somebody produces the same thing over and over in the same way. We never get this repetition in software development.
If Toyota produces the software in their factory;
Imagine a situation where Toyota has been asked to produce software in their production line.
Engineers will set up the production line for story 1 – Let’s say to develop “User creation” feature. We will have BA workstation specifying the requirements, to be passed to UX workstation to produce prototype, etc. Finally it goes to deployment slot after passing QA.
When the second story (This is a bug to fix in “Global search”) comes to first workstation, that workstation requires a total change of set up. This require downtime for change of set up.
With this amount of variability, most of the manufacturing concepts/tools will be ineffective.
Conclusion
One needs to be careful and understand this fundamental difference before directly applying manufacturing concepts & tools to software development.
Many misses this important difference between the types of queues which results in pressurizing development teams to deliver software like cars coming out of Toyota production line.
Obviously if the software teams are asked to develop same task over and over again, there will not be any problems
A big cautionary note
A big cautionary note here is that this does not mean that there is no use of adopting concepts from manufacturing or every manufacturing concept is not valid. For example lean concepts such as “inventory as a waste”, “eliminating waste”, etc. are fundamentals and they are still valid fully in software engineering.
My argument here is that as software professionals, we should not blindly adopt ALL the manufacturing concepts in to software development.
Anuradha Gajanayaka 