Lean manufacturing cannot be applied literally to software development
Agile methodologies borrow ideas from lean manufacturing. While some ideas such as standards, components, trunk-based development, and value streams have been very useful, others such as Kanban, Theory of Constraints (ToC), Little’s Law and one-piece flow get applied incorrectly.
As a practitioner I have immersed myself in these concepts by reading books such as “Agile Management for Software Engineering”, “Learning to see value-stream mapping…” and “Phoenix Project”, and for a while I was under impression that these concepts were working. Only after some reflection it became evident that these ideas did not work as expected, they ended up slowing delivery operations which lead towards a lot of frustration. Here I will explore why exactly ToC, Little’s Law and one-piece flow can’t be applied literally.
I am not an expert in manufacturing, so examples should be taken as high-level ideas that serve as a contrast to knowledge work.
Manufacturing work
Since the rise of Lean Manufacturing majority of companies have transitioned towards one-piece flow. This is where work travels in discrete pieces from station to station where some specific operation is applied on to it such as:
This means that factories tend to have one assembly line down which work travels. Takt dictates how much time each station has to complete their task. For example, in car manufacturing, you might need to install car dashboard, you will be given 3 minutes per car to do this. If you find an issue or don’t have enough time you can “stop the line” so the entire assembly line stops.
Car manufacturers have been doing this for decades so they have figured out ways to ensure that each station has as few issues as possible so there is very little disruption. Having said that there are thousands of line stops a day and this is considered to be normal.
Assembly lines stages can get very long, and they might have number of inputs before the work gets merged into a single line. This can be witnessed when car manufacturers perform “marriage”, this is when they insert the chassis, transmission and engine in the body on the production line.
Lastly all of the cars are not the same. They will be built per different specifications. Some will have premium interior, different wheels, upgraded electronics and so on. This means each stage needs to know what exactly needs to be done for that particular car. This adds additional complexity to the manufacturing process.
What gave a drastic productivity boost to assembly line is componentisation. It became possible to put things together using discrete parts. Componentisation makes part integration possible through agreed standards. Assembly line is set up to produce similar models of the car, sure these models have different specifications like mentioned above, however they are all standard and their Takt time is set and known.
As Takt time known and it is controlled it makes cycle time fall with in normal distribution. If you are interested in cycle and lead time check out “Lean software development, using lead and cycle time to drive business change”.
Knowledge work
Now contrast manufacturing work to software engineering. Let’s say feature request A will take 15 days to complete by 4 people. B might take 5 days to complete by 2 people. C might take 8 days to complete by 7 people from 3 different departments. Some work is “standard”, however a lot of the time in software engineering work is not standard, work cycle time falls into exponential distribution (figure 5), it is volatile, and is akin to craft production.
Practitioners might say, well how about you break these feature requests down to a smaller size so that cycle time is more controlled? Is it not possible to size up all work so that it falls within the normal distribution (average)? I must counter with this, a feature request needs to deliver a discrete piece of real user value. If it is possible to break a feature request down and still deliver real value, then it should be broken down. However often feature requests can only be broken down to a finite amount until it loses its value and then process becomes task breakdown. Breaking feature requests down too far is artificial and actually leads to knowledge workers forgetting why they are doing the piece of work in the first place. This leads to poorer solutions and time waste, see “One-piece flow is inefficient for software development”.
Introducing craft production
“Regardless of the product, craft production’s finished goods are unique, tell a story, and (should be) made of extremely high quality, which is the biggest appeal of purchasing something from a craft manufacturer.
However, even though customers are interested in these unique items, it does come with the disadvantage of being harder to repair compared to the mass-produced, cheaper alternatives, which are composed of identical, replaceable parts, that are easier and cheaper to fix.
The other thing about craft production is that it’s reliant on a highly skilled craft worker, of which we’re currently experiencing a shortage. Training for anyone working in craft production can be intensive and delivered through apprenticeships, workshops, lectures, or just a simple hands-on approach.” — Craft production segment from Katana
Standard work does exist in the knowledge work world. Implementation’s consultants that are setting up a product for a customer are doing standard work. Software engineers that are re-using components and connecting them are doing standard work. However, the problem is that companies want innovation and product differentiation. Unfortunately, this work falls into craft production which is unique and not easily repeatable which makes delivery slower and less predictable.
Standard work in knowledge work can be automated fairly easily thus leaving us once again with craft production work. However for the foreseeable future there will always be some standard work that people will need to perform. This is because it is cheaper to have people do it, or it is better for the customer experience.
Craft production factors
Craft production’s lack of delivery predictability is exacerbated by the fact that people are working on the actual work. Stakeholders in organisations forget that employee A and employee B might deliver work at very different speeds due to their different characteristics and experience. Here are some factors that impact knowledge work productivity:
- Volume of work — Amount of work you have to do.
- Unknowns — Identifying stuff that you did not consider when you were estimating the work.
- Complexity — Figuring out an algorithm to solve a problem, this the main thinking part.
- Risk — Testing you have to do given the risk level that is acceptable for the task at hand.
- Skill — Improving your hard/soft transferable skills (programming, math, architecture, algorithm design, management, leadership, etc) or using your existing skills to get work done quicker.
- Domain — Gaining new domain knowledge (HR, Logistics, Financial Trading, etc) or using your existing domain knowledge to get work done faster.
- Attitude — This is how you perceive your work environment and tasks.
- Aptitude — This is you having developed or have predisposed skills towards the work that you are doing.
Assembly lines tend to be linear, single queue. Once work enters the production line it enters a queue and goes from start to the end, this is called work in progress (WIP). This is not the case with knowledge work. Work might go on to a backlog, sit there for a year and then get removed. Work that once was super urgent will be deprioritised and swapped with something else. In knowledge work there is no queue as such. If you are following Scrum, then normally the team commits to work before a Sprint starts and very rarely should user stories in the Sprint change. This commitment is probably the only place in the whole process where there is a stable queue, and these commitments can be called work in progress (WIP).
Conclusion and Implications
Little’s Law assumes that queue is stable (i.e. WIP) and that work has an average cycle time. This is true for standard work as work on average takes a similar amount of time, this not true for craft production as it follows negative exponential distribution. This means “out of the box” Little’s Law can’t be used in software engineering.
One-piece flow, a typical Scrum team has around 6 team members. It is likely that they will work on more than one user story at the time. This means it is not a one-piece flow. Constraining a team to a one-piece flow artificially constraints teams and can waste utilisation.
Theory of constraints assumes that there is one-piece flow and work is standard. Different feature requests will engage different people in the team at different times. This means the bottleneck is dynamic and it depends on what that team is working on and not necessarily who is working on the work.
One big insight that we can gain already is that in craft production the work itself can be a constraint. This is because as a team you can choose:
- What you do
- How you do it
- Who does it
This means if you have a creative product owner, your team can deliver an astronomical amount of value with a very small team. This is because they can swarm around the “problem” that needs to be solved and figure out creative ways to get it delivered quickly. With craft production you are not constrained to the assembly line, people are not machines as they can learn, help each other and be creative. However, the traditional manufacturing mindset would dictate that you need more people to deliver more units of work. This is not true for craft work as value can be delivered in many different ways.
