In software development with fully automated build and test technologies, it is state of the art that a fully tested and documented software product can be built at least once in a Sprint. In the development of mechatronics systems, we encounter longer build and test times and traditionally much longer development cycle times.How does all this fit into a Sprint? In the last blog post we (Jean-Pierre Berchez and Joachim Pfeffer) discussed the definition of an increment. Today it’s all about cycle time: How can we get faster?
Management Approaches for Development Speed
We can get much faster without touching our engineering processes, by reducing waiting time and hand-offs. Analysis of lead time versus hands-on time in product development show normally waiting time of 90% or more. So mathematically, it should be easy to do twice the work in half the time. For decades, Lean approaches such as Value Stream Mapping (VSM) have been attacking this problem from the management point of view, working top-down. VSM is still a very useful tool (we often can reduce cycle time by 30% in the first workshop) but not very popular, as it requires top management to be involved in several 3-day workshops throughout the year. Time-to-market seems not to be a very high management priority. Lean also reduces hand-offs, which always create a loss of time, information and quality. By introducing the “chief engineer”, one person has the economical responsibility by owning the requirements, the technical concept, the profit, the budget and the customer feedback.
In contrast to that, Scrum has a bottom-up approach for optimizing waiting time and hand-offs. A Scrum Team improves Sprint by Sprint, attacking too long cycle times more implicitly than VSM does. Regarding hand-offs, Scrum gives all the mentioned accountabilities to the Scrum Team. This team is empowered to balance functionality versus solution and stakeholder needs. So Lean and Scrum strive for the same goals, with slightly different approaches.
Engineering for Speed
On the product level we can find several approaches to get faster:
- System Architectures,
- Alternative Manufacturing,
- Simulations and
- Automation.
So let’s dive in.
System Architectures
A modular, loosely coupled architecture is key for fast iterations. It allows one to iterate one architectural element (e.g. component) against stable interfaces, without touching the whole system. Wikispeed is a famous example for this approach. Talking about system architecture, we have to discuss architectural goals. In a complex environment (this is where we use Scrum), adaptability becomes much more important than production cost. And be aware: loosely coupled architectures need a professional interface management and roadmapping.
Alternative Manufacturing and Simulations
Manufacturing methods like additive manufacturing are well known, but often not used to the maximum possible extent. 3D printing is often associated with orange filament prints and sometimes regarded as a toy. Only a few companies use the available technology to print with the “real” material like steel, aluminum, titan etc., depending on the volume even in series production.
With simulations, we encounter the same problem: only few companies develop with integrated simulations where software, electronics and mechanics can interact. While digital twins cannot fully substitute the real product, they are a key element to gain speed in product development.
Both aspects, new manufacturing methods and integrated simulations have in common that they seemed too expensive (in terms of infrastructure and knowledge) in linear development approaches. In a complex environment however, it is very hard to learn and adapt, if available technologies are not integrated into the development process.
Automation
While build and test automation is state of the art in the world of software, the “physical world” is still slow in adopting these concepts. For many, the first step would be (partial) build automation with additive manufacturing and robotics. Test automation is widespread in Hardware-in-the-Loop (HIL) environments where test stimulation is still a software task. The next level is to incorporate robots (e.g. safe CoBots) for physical test stimulation.
With automated build and test, we cover two-thirds of the V model. A new topic, which came up in the last few years, is design automation. “Design Compilers” are able to design a product on given requirements and design rules ready for production in a few hours. Currently three of our customers use this technology for fully automated design in the automotive industry.
Speedy Supporting Processes
Running one or more Scrum teams in product development gives a fast improvement in cycle time and shifts the bottleneck to the supporting (often overloaded) entities such as purchasing, quality management, sample shop etc. For the improvement of supporting processes, they could be included into the agile teams or work with management prioritization and process exemptions to not hinder the agile teams.
Summary
Concepts for fast development cycles can be adopted from software engineering. The technologies are there. In our experience, agile hardware development does not fail because of physics but because of a lack of clear management commitment to real agility.
Want to learn more?
Our next Blog-Topic will be: "Traditional requirements vs. product backlog items in "Hardware" Scrum?"
Our Webcast regarding "Hardware" Scrum will be on the 16th April 2026 here at Scrum.org
Additional Sources (German Language):
https://www.scrum-events.de/training-details/certified-agile-systems-engineer