To the average person, “agile” means “able to move quickly and easily.” Product development is often perceived to be too slow, take too long, and lack the ability to respond to new information that may come in late in a program. 

The idea that a product development team could move faster and more easily is an appealing one. This is why Agile Product Development has become a strategic imperative for some organizations.

Product developers need to be able to react quickly to new information. Who doesn’t want a product development organization that has the ability to respond to customer needs and competitor challenges like that? We want our teams to demonstrate agility in response to changing customer and business needs.  The images that come to mind are gymnasts in the midst of tumbling runs, football players dodging tackles or tennis players rapidly adapting to opponents’ shot placements. But when we ask for “agile” we sometimes get something else.

What Developers Hear When They’re Asked to Be Agile

The problem is that “Agile” also has a specific meaning in the development community, especially among software developers. In that world, it means the Agile Software Development system that emerged in the software community in the late 1990s, to address the challenges posed by development in that time. During that period, software transformed from programs installed on a standalone PC or mainframe towards software that runs on Internet technology.

The technology was unstable. The standards we take for granted today for encryption, browser behavior and UI design were being created. The utilities for secure payment processing, managing logins and passwords, search engines, app stores and social networks were being built. We had a lot to learn about customer value and business models too.

The Instability Drove Agile Development

The Agile Manifesto consolidated a lot of work being done to learn how to develop software in this new environment, when many painful experiences showed that traditional project management methods could not handle all of this uncertainty. Schedules changed day-by-day, documentation was out-of-date as soon as it was written (and often before it was approved), and all the constant redirection made decision-making too slow if it wasn’t pushed all the way down to the team level.

At the same time, Internet technology drove the cost-of-change for software towards zero. Updates could be pushed out to users at will; the next time a user logged into a site, the site could run updated software and the user would not even need to know there had been an update, if the UI didn’t change. With even standalone programs available via instant download, teams gained the ability to release software early and often.

Agile itself encourages teams to do whatever they can to drive the cost-of-change towards zero by encouraging teams to write independent user stories and develop modular architectures. Then it encourages teams to use planning methods that assume there are no dependencies between units of work and no differences in software team members’ ability to work on any task.

For a Tangible Product, “Agile” is not agile

Agile Software Development methods were built for a world of extreme uncertainty — and extremely low cost-of-change. In this environment, it’s best to build something — almost anything, no matter how small — and get it immediately into users’ hands so that they can give feedback. Then teams can iterate on the software from there. This is how Agile Software Development makes software teams agile.

These ideas translate less well when a product has high cost-of-change. You can’t iterate on a forklift the way that you can iterate on an Android app. Even the roughest prototype build takes weeks, not seconds. If an app has a user interface that drives a user to do something unexpected, it can be fixed in the next release and usually, the long-term consequences are trivial. If a forklift’s controls lead an operator to make a mistake, they could do some serious damage and the problem is not easily fixed in the field.

The fundamental assumption of Agile — low cost-of-change — is not true for tangible products that have to be mass-produced, sent through distribution networks to customers and supported in the field. Team decisions lead to purchasing tools, establishing production lines and filling channels with products. If these decisions later prove to be wrong, they trigger expensive rework loops as the best-case scenario. Agile project management methods have no provision for managing complex dependency chains, ensuring high quality decisions at the right time, or managing the risks that are an inherent part of building a tangible product.

Known Issues with Agile Product Development

For a hardware team, “Agile” is not agile. Here are some of the effects of using Agile to manage programs that have high cost-of-change that have been experienced when hardware teams use Agile, and how it slows them down:

• It drives teams to manage their tasks in pieces that are too small for the flow of work in hardware development.  In software, it makes sense to manage tasks in two-hour to two-day pieces.  In hardware, that leads to micromanagement of tasks that individual engineers usually manage on their own.
• It leads to the creation of “shadow” systems to manage dependencies. Since Agile assumes task independence and has no way to manage dependencies, Project Leaders feel compelled to maintain separate project schedules (GANTT charts) to ensure that the team is working on the right things. Since they’ve been told NOT to use these “old” tools, the plans go underground where the team can’t easily see them. Project Leaders using Agile for hardware development have told me, nearly universally, that they had their own plans running in parallel with the Agile process because they didn’t trust it to handle sequences and dependencies.
• It drives teams away from modeling towards physical builds, even when that’s not the fastest way to learn. In software, the fastest way to learn something is to build it and see what happens. Software builds are fast and almost free. So that’s what Agile methods emphasize, with hands-on demos as the primary way for teams to show progress. In hardware, we try to learn everything we can without building anything, and then we start building models first before building prototypes. Since full prototypes are so costly and take so long, we only build them when we’ve exhausted the possibilities for learning in any other way.
• It drives teams to meet too often, for too long. Agile methods call for daily stand-up meetings, because in the software world, that’s how often teams need to meet. It calls for lengthy Sprint planning sessions, because that’s the best way to prioritize work to maximize business value. Most hardware teams don’t need to meet as often, or for as long.

It doesn’t solve the root causes of slow product development

All of that might be worth it if it accelerated hardware development — but it doesn’t.

Agile does not solve the primary root causes of slow development for tangible products: decisions that get revisited late in a program, causing long, slow loopbacks. Since this is not a problem in software development with low cost-of-change, Agile does not address it.

This is why I encourage hardware teams to push back on efforts to “just use Agile” and replace them with Rapid Learning Cycles instead. The Rapid Learning Cycles framework was built from the beginning to solve the root causes of those long, slow loopbacks, and to integrate well with phase gate Product Development Processes, as long as the PDPs have a reasonable amount of flexibility.

If you’ve been trying to use Agile product development and you have been struggling, know that you’re not alone and the struggle is real. The good news is that this experience has taught your team things about working in Sprints that will be valuable when they make the shift to Rapid Learning Cycles.