Agile methods create speed and flexibility in software projects. Can the same methods also bring more speed and flexibility to hardware projects? Practice has shown that agile software methods often backfire on hardware projects – but hardware-specific methods based on agile principles can create major improvements. To get the most mileage, you need to understand why agile software methods work – and what’s different about hardware.
Working in Small Batches Shortens Feedback Loops
Agile software development methods work by dramatically shortening feedback loops. To see how this works, think of a development process as a system for turning ideas into saleable stuff. In traditional software methods, all the “stuff” moved together in one enormous batch through each activity in the development process. No feature could be coded until all had passed design freeze. No feature could go to testing until all had been coded. This created extremely long, slow feedback loops. After coding, it should be weeks or even months before that code was tested and defects found. The application wasn’t functional until close to the end of the project, so customers couldn’t provide timely feedback on what they liked (or didn’t like).
In agile, the same “stuff” is split into numerous small batches, where each batch delivers a few fully functional features. The team works on only one batch at a time, finishing it before starting another batch. Suddenly a feedback loop of many months has been cut to a few weeks. Bugs are found while the design is still fresh in the developer’s mind. It’s possible to show sample features to users and learn what they really want. Value is delivered earlier and with less effort.
In addition, the project is more flexible because each batch is relatively independent of the others. This makes it easy to change the order of batches, drop batches which haven’t yet been started, and add in new batches.
In short, agile methods get great results primarily because the work has been split into small, independent batches and each batch is finished and delivers its value before another batch is started. There’s more to it than that, but that’s the core principle. Much of the rest consists of creative ways to optimize the throughput of these small batches.
Why the Same Thing Doesn’t Work in Hardware
Many people have tried to split hardware projects into batches of features, just like software, and apply agile software methods verbatim. This usually runs into problems because those agile software development methods make some assumptions which aren’t necessarily true in hardware. Namely, agile software methods assume that:
- Batches of features are relatively independent of each other, so the order of batches can be changed, a batch can be dropped without disabling other batches, etc. This isn’t 100% true even in software, but it’s true enough for agile methods to work. However, hardware projects typically have many more interdependencies between batches. Some batches need to be done in a particular order. Design choices made in some batches affect the results of many other batches – for instance, changing the plastic used for a particular part might affect multiple different user-visible behaviors.
- A feature can be completely finished and delivered on its own. Again, often this isn’t 100% true even in software, but it’s much less true in hardware. Lab prototype hardware doesn’t behave the same as production prototype hardware, even though basically they are both a collection of the same features.
- Most features can be reworked for a reasonable cost. When there’s a low cost of change, “build it and see if they like it” is practical. That’s often not the case in hardware projects, where rework tends to be very expensive, despite many advances recently in simulating behavior. This is partly because hardware projects are really two concurrent projects – building a new object that has never existed before, and designing a manufacturing process to build many, many copies of that object.
So How Can Hardware Development Be Agile?
So how can we possibly achieve agility – flexibility and speed – in hardware development?
The same workflow management tools which are used in software development can provide a great deal of benefit in hardware projects – if they are used to manage the right kind of batch. The right kind of batch is one which can be finished and deliver value without waiting for every other batch to complete. A set of features just doesn’t seem to be the right kind of batch for hardware projects.
In the book Agile Gets Physical, Katherine Radeka and myself describe splitting hardware work into other kinds of batches.
- In early development, we split the investigative work and research into batches. Each batch delivers the knowledge to make an important product decision accurately, which shortens notoriously long, slow feedback loops.
- In middle development, we split routine development work into batches. These batches don’t deliver finished features, but rather deliverables which feed into the next step of development. Managing these deliverables with flow-based tools borrowed from agile software reduces management overhead, though it may not shorten feedback loops extensively. However, concepts from agile software which reduce dependencies between features can be applied very effectively in hardware projects to shorten feedback loops.
- In late development, we split the integration testing into smaller batches. Each batch delivers specific information about the quality of a set of features or attributes of the product. These smaller, more focused batches again shorten feedback loops.
If you want to read more about batches and why they work, continue with the blog post What is Queueing Theory and Why Should I Care? . If you want to know how agile methods can work in hardware development, take a look at our book Agile Gets Physical.