Menu
In 2001 the agile manifesto for software development was written, by a group of professionals with joint frustration. A frustration about commonly used project structures and results (or lack of results) delivered through these structures. The agile manifesto website provides the text of the manifesto and its principles and the motivations of the authors.
The core of agile software development frameworks is empiricism: build a real part of the desired software, and inspect it often and early. The most important parts of the final product are built first. Inspecting can be against multiple factors: usability, interpretation of specs, quality, etc. Often is typically every two weeks. And early is two weeks after the start of the project. Upfront design is minimized, and replaced by seeking feedback from clients through the inspect-and-adapt cycles.
Just like software delivery projects often deliver poor quality, deliver it late, and require more budget than anticipated, so do projects which deliver physical products. Physical products can be hard parts, like semiconductors, booster rockets, or dancing shoes. And also fluids like reagents in molecular biology, and gases in food conservation.
The most common myth about using an agile (empirical) framework in a physical environment is that with physical products an inspectable increment cannot be produced every few weeks. Most of the time it can, we are just not used to thinking about inspecting small parts of the final product. And it may require tools that don’t exist yet. It was the same in software development in the early 2000s. The agile development of a website with a few pages was understandable for software engineers. But a whole bank, with security and usability layers, with database and communication technology inside – that would never be possible was the common thinking. Ironically it was this project that got me into the agile movement. History has proven that complex systems can be developed in short iterations. And can only be developed in short iterations, these products are too complex to be fully designed upfront.
A CO2 monitor can be developed in 2-week iterations. First breadboarding the sensor, reading output through a Raspberry Pi – easy in a matter of days. Adding a display, and showing the breadboarded set-up to end-users. Who complain about the lack of readability of the screen. Replacing the screen with green-yellow-red LEDs to indicate the level of CO2 in the room. Replacing the Raspberry Pi with three different miniature processors to select the best option – easy in two weeks. Printing 3D enclosures to produce the first consumer units and run real-life tests. It is easy to understand how a simple product can be delivered in an iterative fashion.
But to deliver the next Raspberry Pi in an iterative way seems to be a different matter altogether. Because it will be a multi-core processor. With heat production. That is targeted to be used in AI applications. While still interfacing with multiple interface protocols. But with the same footprint as the previous models. Months and even years of upfront design don’t help to get the new Pi faster on the market. When the designs are used to produce prototypes the problems not considered by the design tools will surface, and force redesigns. Which, when produced as a prototype, shows problems not considered… And the selected components of the new Pi are now no longer commercially available and have to be replaced. Which causes a redesign, which…
Designing the new Raspberry Pi can be done by building it in a lab. First versions with candidate processors on rapidly produced PCBs. No interfaces yet, nor power management or temperature control. While the processor selection is done in a set-based approach (start with many, test these to discard the ones which don’t pass a test, run more tests until a small number of candidates remain, then select one based on economic factors), other engineers can start working on power management, heat dissipation, protocol circuits. These subsystems do not need a processor to be chosen. Designing in subsystems does need agreements on interfaces between the components.
And then assembling the subsystems will just be easy. Not. Of course not. The power management subsystem produces more heat than agreed, and the protocol circuits run on different driver frequencies. Early integration is a must to find those problems early, leaving enough time and budget to find solutions.
Although there may be other domains, so far the development of integrated circuits is the only product I know about where true delivery of a product increment is not possible. The production of a silicon wafer is too costly in time and money to be iterated. What can be done (and is done) is to put trial circuitry on production wafers. A wafer is circular, and an integrated circuit is rectangular. Rectangles filling up a circle will leave spaces too small for another production IC, but big enough to be used for a trial circuit. The iteration time is too slow to be useful for agile product development (unless you can put new IC masks in wafer production every couple of weeks). But it shows the different thinking which is required for the change towards agile product development.
The examples above are high-tech. Real life doesn’t have to be. A folding mechanism of a solar array on a spacecraft can be built from materials sold in every DIY store combined with 3D printed hinges, a customer discovered how the used screws created problems in the unfolding sequence. An ATM mocked up from plywood gave a customer early feedback on ergonomic aspects, saving 9 months of time to market.
The long example above is not the only part of agile product development. Producing a new computing device, or a new mass-production satellite is one thing, but it has to be produced in a manufacturing plant. Designing and building the plant is a design effort in itself, which can and will show flaws and problems in the product design. And ramping up the supply chain is another challenge that takes many months. In physical agile product development, these factors are present and addressed from day one of the project. When inspecting a product increment, also manufacturing people are inspecting, and so are supply chain representatives. They will flag up problems while a product change is still more simple and cheap (simpler and cheaper than working around it during mass production). A client example: adding a supply chain representative to the design team for radiation tolerant circuits prevented a year of wait time for key parts by selecting another material for the circuit enclosures.
“The thinking that got us into this mess is not the thinking that will get us out of it” – the quote is attributed to Albert Einstein. This new thinking is what will hit you and the people around you when you start to wrap your head around developing your products in an agile way. You will face radically different ways of doing things, and your muscle memory will scream at you (so will your peers, your bosses, and your development teams). And do you have a choice? You can optimize the project structure some more, saving a few days or weeks of development time. Which is not enough. When global trading came to a halt in the recent economic downturn, a new product needed to be developed in months, not years. The old thinking doesn’t allow that.