Self-proclaimed productivity obsessive, Tenzing’s Product and Technology Specialist, Seb Aspland, explains how developers have stolen some of manufacturing’s best ideas. And the valuable lessons developers can still apply.
Software development, like manufacturing, is built on a series of workflows and processes. The more productive businesses complete high-quality work efficiently which drives profit, efficiency and growth.
Many of the tactics software firms have used to drive efficiencies are not original. They’re stolen manufacturing ideas that have been experimented with and adapted to suit the world of development.
Understanding how to make development teams as effective as possible has been a small obsession of mine. Given that manufacturing is the success story of the 20th century, I think there’s a lot we can learn from the sector.
So, in this article, I’m sharing some of manufacturing’s best ideas and explaining how developers have applied them. I’d suggest you read this with an experimental mindset. To see which productivity-enhancing strategies you can apply to your software business.
Applying the theory of constraints to software development
Imagine a manufacturing line. A widget goes through each step of the process. It takes one minute at stage one, two minutes at two, five at stage three and one minute at stage four.
In their attempt to make the process as efficient as possible, manufacturers would try to automate and drive efficiencies. That is, until Eliyahu Goldratt challenged this way of working.
He realised it doesn’t matter how fast the widget goes through one, two or four. Because it will keep getting stuck at stage three – the longest stage. He introduced manufacturers to the idea that in any flow of work, there is only one constraint. Everything else is just a distraction.
How software developers applied the theory of constraints
In a typical software development environment, software goes through a number of processes before it gets into customers’ hands. Historically, this consisted of something like:
- Gather requirements (3 months)
- Prioritise requirements (1 month)
- Write very detailed explanations of exactly how requirements should work (3 months)
- Developers write code to solve the requirements (6 months)
- Create an environment where developers can see their code working (1 month)
- Testers test the backlog of features (3 months)
- Developers fix reported bugs (1 month)
- Testers retest (1 month)
- IT build the code into a package and deploy it onto a production server (2 months)
This led to enormous lead times that left everyone frustrated. What some clever people in development circles realised is this is a manufacturing line. But one where the product can’t be seen.
As a result, a group of people created the agile manifesto. It encouraged developers to deliver working software in close collaboration with the business around once a month. This dramatically compressed steps one to four.
Try this in your business: create a super simple value stream map. One that shows all the processes involved in getting working software into the hands of your customers. Find the place where work is building up the most (the longest queuing time). Then focus all your efforts on making that process better.
Achieving one-piece flow in development
The masters of manufacturing efficiency, Toyota, helped found a movement called ‘Lean’. Which focuses on reducing waste including waiting, processing and overproduction. Toyota measured how long it took an item to go from start to end of the manufacturing process. This included times the item wasn’t being worked on. Which helped the manufacturer identify areas where poor flow slowed production.
Implementing lean practices significantly reduced the amount of time items were left waiting in a queue. This resulted in the concept of ‘one-piece flow’. Where items were worked on individually and continually, rather than in batches.
Not only was this more efficient for manufacturers, but it was more flexible too. For example, when a customer wanted to rapidly develop a new marketing campaign and change its packaging to fit, manufacturers could quickly adapt to meet the customer’s needs.
How software developers adopted one-piece flow
With cloud infrastructure in place, developers introduced operations teams. They were responsible for pushing the code into the production environment and building the required servers. Yet often, the code didn’t work in those environments. So, more time was needed to build new environments.
At the same time, the developers kept pouring in more code. Which piled up in front of the operations team, who would send it back to QA.
In manufacturing terms, this approach amounted to having a lot of inventory, which was not being worked on, sitting in the system. As a result, development teams combined development and operational roles into DevOps roles. This removed the middlemen. And empowered developers to continuously build, test, amend, check and deploy a single piece of work. Resulting in DevOps roles achieving one-piece flow and a more streamlined approach.
Try this in your business: if you don’t already use DevOps practices, consider embedding some of your more forward-thinking IT/Operations people into an agile development team. This simple step can force everyone to better understand what’s going on so they can rapidly make the right changes.
Eliminating waiting to drive productivity
Another challenge solved by manufacturers was the need for speed. One of Toyota’s major difficulties was switchover times when changing from one widget to another on a machine. Long switchover times led to large batches, which moved their production process away from their ideal state of one-piece flow. Toyota discovered that switchover times could be changed from two hours to less than five minutes. Simply by having all the tools organised and in an easy-to-reach position.
Software developers faced similar problems, albeit in slightly different ways. Because quality was so highly prized – even for minor changes – software developers’ work had to be deployed in a testing environment before it could go live. Creating these testing environments could take hours, days or even weeks and would also lead to undesirable large batches.
To get around this, developers have started using Infrastructure as Code. This means even testing environments are created in code. Which can, in theory, be achieved at the click of a button or a single line of code. This virtually eliminates all the time and energy wasted on unproductive activities.
Try this in your business: experiment with making the creation of test environments much easier. The first step may be introducing an SLA to produce an environment several times a day. For an individual or group that usually carries out this task manually. Even if this burns them out at first, any developer who repeats the same action usually finds a way to automate the task.
“I think most people in business could steal more from manufacturing, including myself. In every factory, they’re always improving, always finding a way to get stuff done a little bit quicker. If we can understand and analyse manufacturers’ work, we can adapt better and faster.”
Seb Aspland, Product and Technology Subject Specialist, Tenzing
Pulling the Andon cord in software development
Speedy processing relies on the ability to identify issues and fix them fast. In manufacturing, workers can halt the manufacturing line by pulling the Andon cord if they spot something wrong. Then the manufacturing line completely stops until the issue is resolved. Although, in reality, most processes have two to three minutes before the line actually stops. This is much more efficient than letting problems progress for someone else to resolve.
As a developer, you don’t want to pass your code on to someone else who finds it doesn’t work. Or worse, deploy it and take the entire system down. So the software sector adopted a similar approach by making developers accountable for every stage of the development process.
By using automated testing practices, developers can discover whether their code is working as soon as they’ve written it. In addition, by using a ‘deployment pipeline’, developers can run a more advanced set of automated checks. These checks make sure the code merges into other developers’ work without breaking anything.
This dramatically increases developers’ accountability. And means sloppy work is not passed onto someone else to resolve. The introduction of peer checks also allowed developers to review their colleagues’ work to expedite minor changes.
Try this in your business: if you don’t already, start writing unit tests (the smallest testable parts of an application) on any new code you write. It’s a good way to start introducing quality checks that will grow with your codebase.
The ‘plan, do, check, act’ cycle that boosts quality and value
Deming’s ‘plan, do, check, act’ cycle was adopted by Toyota to continuously improve and control the quality of their processes until they reached the desired output. The model also proposed that the quicker you could go through the loop, the faster production would improve.
In development teams, this approach was applied with an emphasis on planning, checking, acting on feedback and then planning again. The aim was to overcome one of the biggest constraints in development – working on superfluous items.
With the emphasis on good planning, software development teams began to invest in Product Managers to ensure developers only received items customers actually wanted. These roles replaced the old school way of randomly deciding what customers need without talking to them. This change often requires a fundamental culture shift in an organisation. But it can also be the biggest single win.
Try this in your business: introducing brilliant Product Managers ensures developers build the right things. With rapid deployment and early customer testing, you can uncover what customers do and don’t like. In the space of a few weeks or even days – not months or years.
Increasing regularity to improve productivity
In lean manufacturing, there are three deviations: Muda, Mura and Muri which mean:
- Muda – wastefulness
- Mura – irregularity
- Muri – overburden
In lean manufacturing, Mura is the key driver in this trio. Because irregularity causes waste and overburden (although it’s not the only source).
One way of thinking about Mura is peaks and troughs in work. When work comes into a system unpredictably, you end up with a large amount of waste. You can’t always service the peaks, and if you do, you’ll end up overburdening your staff (Muri). And you’re often over-staffed for the troughs. Through this triangular concept, manufacturers realised that agreeing appropriate expectations with customers set the pace for everything else.
For developers, achieving the right balance between Muda, Mura and Muri came back to having excellent Product Managers. They prioritised the work and provided a steady stream of high-value tasks to developers. And protected the teams from hard deadlines with fixed functionality.
In addition, automating the majority of your testing helps developers. Because they don’t get a large batch of bugs to fix when they’re building a new feature. This is a classic and completely avoidable example of unevenness.
Reducing waste in this way throughout the development cycle means people aren’t overworked. So they’re happier and more productive. Not only are processes more efficient, but people have more capacity to solve customer problems and apply creativity. And they won’t be working until 1am either.
Try this in your business: if you use sprint planning, consider eliminating this. Instead, plan features and collaborate on individual tickets using a three amigos approach. While sprints are useful for learning agile, they actually create avoidable periods of unevenness.
What else can you apply from manufacturing?
I strongly believe if we all applied the same analytical approach as manufacturers to our own line of work, we’d hit new levels of productivity. The development sector has already taken steps in this direction. But, as the world continues to change and technology advances, I think there’s still room for improvement. Adopting an open, experimental mindset is key to accelerating our processes and taking software development to its next iteration. Paving the way for even more exciting software advances.
