An obvious solution to software development problems is to create buffer capacities for non-permanent processes. Some companies figured this out a long time ago. In 3M for several decades, developers have been involved in 85% of their capacity. At Google, engineers are allowed 20% of the time (day of the week) to do whatever they want, which means they always have extra time available if a project is delayed. But such a solution is quite difficult to organize. Few will escape the temptation to keep employees 100%. Managers reflexively issue new tasks when they see downtime.
But there are other solutions as well.
Change control system
In the case of a pharmaceutical company, this may mean aligning the goals of the animal testing department with the development department. For example, you can reward the testing department for quickly responding to requests rather than utilizing resources.
Selectively increase resources
By adding additional resources to areas where the utilization rate exceeds 70%, you can greatly reduce the waiting time. If a pharmaceutical company did this in the animal testing department, then responses to requests for new chemical compounds would come faster. When testing is done with computer modeling and simulations, the increase in resources costs relatively little, as it usually means the purchase of additional hardware and software licenses.
Limit the number of active projects
If you can’t increase resources in the animal testing department, you can reduce resource utilization by reducing the number of active projects. Discipline to hard limit the product development pipeline often leads to better focus and clearer priorities.
Improve the visibility of tasks that are being worked on
One of the methods is visual control boards. They may look different, but the key point is to have some kind of physical indicators, like notes for notes, representing the work. The board should display all the work and the status of each part of the project. It should be at the center of the management process. Daily 15-minute meetings can be held at these boards to coordinate efforts and move the work forward.
image
Typical view of a development control board
The first column is new tasks, approximately similar in complexity. The second is work in progress. The number indicates the maximum number of simultaneously solved tasks. A check mark next to a task indicates a problem. The third is the parts ready for testing. A turned leaf means the manager needs to intervene. Fourth – test tasks. The number indicates the maximum number of simultaneously solved tasks in total in both columns. Fifth – tasks that have passed testing.
Misconception 2: Processing tasks in large batches improves the economics of the development process
The second reason for queues in product development is batch size. Let’s say a new product consists of 200 components. You can decide to design and build all 200 before you start testing them. But if 20 components are developed instead, the batch size will be 90% smaller. This will greatly reduce the waiting time, since on average the queue is proportional to the batch size.
Reducing batches is a basic principle of flexible manufacturing. It allows you to reduce work, speed up feedback, improve production cycles, quality and efficiency. Small batches in product development are even more impo
rtant, but few people understand this.
One reason is the nature of their workflow. Since the information being processed does not have a physical representation, neither do the batch sizes. The second is that the developers have some kind of penchant for large parties. Perhaps they mistakenly believe that this allows economies of scale.
In a well-managed process, batch size will balance transactions and storage costs. It’s like buying eggs at the grocery store – if you buy eggs a year in advance, the cost of transportation will be low, but most of the eggs will spoil, which will increase the cost of storage. If you buy eggs for the day, they will not spoil, but the cost of transportation will be high.
image
The optimal batch size is the one with the lowest total cost (transactions and storage). Small deviations from this point do not bring big problems. For example, if you deviate from the ideal lot size by 20%, the change in the cost of production will be only 3%.
Having figured this out, companies are starting to reduce batch sizes, with surprising results. Some are moving from testing large batches once every 90 days to testing small batches several times a day. One computer peripheral manufacturer reduced software testing cycle time by 95% (from 48 months to 2.5), increased efficiency by 220%, and reduced defects by 33%. The savings amounted to twice what the company expected.
Misconception 3: We have great development plans, we just need to strictly adhere to them
We have never seen a project whose requirements have remained constant throughout the development. But many organizations continue to firmly believe in their plans. Any deviations are chalked up to poor management and execution, and they track every step to reduce them. For production processes with frequent repetition of steps, this is a good approach – but it is not suitable for development innovation. New insights can come daily, and conditions are constantly changing.
The classic study of technical problem solving shows the fluid nature of a developer’s job. It shows how the engineers who created the aviation subsystem developed options and chose the best one. As they worked, their preferences changed frequently, and they tested and refined solutions. This is typical of innovative projects – testing and experimentation reveals what works and what does not, and preliminary estimates of cost and value can change.