“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Agile Manifesto, Principle #2
Innovation is, by definition, uncertain. Ideas transform as they move through development, and even after a team launches its first product.
If anything, the streams of new information intensify the closer the product is to launch. Preview customers share about the areas that worked well, and the areas that caused confusion. Production facilities begin to understand what it will take to make the product at scale. Channel partners deliver feedback on market acceptance.
Streams of new knowledge create the desire to change the product a little, or a lot.
Harnessing change is key to successful innovation.
The ability to manage — even harness — change to deliver more customer value is the reason to seek agility, from a business and customer perspective. A team that can integrate new information into a product is a team that is more likely to deliver the right product to market at the right time.
We have the authors of the Agile Manifesto, their predecessors and their peers to thank for this insight. In traditional waterfall software engineering, teams defined all the requirements early and then put them under strict change control, making it hard to respond to feedback. They wrote a lot of documentation and made lots of system models before they wrote a line of code.
The intention behind all that effort was to design a system that could be broken into pieces to divide work among programmers and then integrated, verified and validated to demonstrate that the system met the requirements. In this structure, lines of defective code are expensive, because they cause problems in late integration that are hard to track down. Teams put a lot of emphasis on writing the right code the first time, by getting the requirements, specs and models right first.
What If We Didn’t Try So Hard to Write the Right Code?
The early thought leaders in Agile Software turned this on its head: what if writing code was the least expensive thing to do? What if we could go faster by just writing code?
What if we designed the development system to make change easy?
That’s the key thing that Agile Software Development methods do — make change easy. All the other principles in the Agile Manifesto depend upon the fact that teams can react quickly to new information. Agile Software Development methods do three key things to make change as easy as possible:
- Minimize documentation outside of the working code and the tests that validate the code.
- Design code and tests from the perspective that they will probably change, using automation wherever possible to speed up build-test cycles.
- Limit detailed planning to a short, visible horizon.
Software code and tests can be relatively easy to change, once all the documentation doesn’t have to be maintained alongside it, once the plans only stretch as far out as the team can see, and once there are reliable tests to make sure the team hasn’t broken anything.
To increase their ability to harness change, they’ve driven the cost-of-change as low as possible in order to be able to react immediately to new information.
How Physical Product Teams Embrace Change
It’s not nearly as easy for a physical product to change, especially once the product gets close to production. But that does not mean that physical products have to follow the failed waterfall model, either. Instead, we seek to preserve design flexibility so that we can incorporate new information with less disruption.
A prototype does not embody hardware design the way a code library embodies software design. We need documentation to understand our design and communicate it to others: CAD models, BOMs, RFPs, DVPs and more. When we send the documentation off to our downstream partners, we trigger a series of activities to implement our decisions that are not easy to redirect.
This makes it harder to welcome changing requirements, especially late in development. But there are four things that physical product teams can do to accommodate more change, later in the program:
- Use simulations, models and physical experiments to build knowledge early, providing the team with options that are well-understood and preserve design flexibility.
- Freeze necessary documentation over time vs. all at once.
- Do enough planning to identify the Last Responsible Moments for major decisions, and then hold those decisions until their Last Responsible Moments.
- Seek to delay the Last Responsible Moment with techniques like modular design, concurrent engineering and flexible manufacturing.
Just as the software teams drove down cost-of-change by automating builds and tests, physical product teams also have opportunities to increase flexibility by keeping decisions open as long as possible — until the Last Responsible Moment.
The Last Responsible Moment Preserves Flexibility
The Last Responsible Moment is the last point in time when a decision can be made without impacting downstream partners or adding cost. This concept gives teams the power to harness change for as long as possible. It gives them more time to learn, and it gives a dynamic situation more time to evolve.
When teams make their major decisions at the Last Responsible Moment, they gain the ability to incorporate all this new information into their decisions, without incurring the cost of changing those decisions. In the world of physical products, decisions lead to actions like signing supplier contracts and cutting tools that are expensive to rework. When we delay these decisions as long as we can, we send a signal that we are still able to respond to changes.
The Last Responsible Moment is specific to a given decision. To find it, ask “what will happen after we make this decision” and then find out when those actions need to be taken so that the program stays on time. Distinguish between when people want the decision and when they actually need the decision — especially if they say they want a large batch of decisions up front before they will do anything.
Such downstream partners may be acting from the false belief that a Design Freeze is an event. In reality, no matter what a team claims to have done or what the process calls for, decisions freeze over time.
Design Freezes Like a Small Lake
When it’s below freezing outside, bodies of water don’t flash-freeze. Instead, the edges closer to land freeze first, filling up the middle until the entire surface is frozen. Then the ice thickens from the top down. It takes several days or weeks of sub-zero weather for small lakes to freeze solid. Larger lakes and rivers never freeze all the way to the bottom.
Designs freeze in the same way: the easy stuff freezes first, and the hardest stuff freezes late. Agile teams don’t try to counter this natural process — we embrace it to give ourselves the flexibility we need to harness change.
A pure software program freezes like a river: some parts of the design are so fluid and flexible that they will never freeze. A simple physical product destined for mass production is more like a tiny pond: it will freeze rapidly and completely. But neither of them freezes instantaneously.
Slow Down Freezing to Harness Change
To harness change, understand where your product freezes naturally, and then seek to extend the window before things freeze completely by finding ways to delay the Last Responsible Moment for major decisions.
Here are some ways you can extend the Last Responsible Moment for major decisions:
- Shorten the lead times for qualifying suppliers, ordering key components or cutting tools.
- Give trusted suppliers partial information to work with, so that you can continue to evolve the details. For example, the entire wind turbine design doesn’t need to be final before you order the materials to make them, once you know how large they will be.
- Push more of the user experience into software, such as touchscreens instead of physical buttons. These take more time to code at first, but they can be more easily changed in response to user feedback.
- For high-risk decisions, consider carrying more than one option in development until it’s clear that at least one of the options will work.
Additive Manufacturing may eventually do for some types of physical products what automated build and test tools did for software development: drive the cost-of-change so low that rapid iteration and immediate customer feedback is possible, by pushing the Last Responsible Moment all the way down to the moment of production. Until then, we have to work within the windows of change that we have, before our design freezes.
The Second Principle for Physical Products:
Since physical products do have a limited horizon for change, it’s not realistic to welcome late requirements — only the most critical issues will be fixed at the very end. But the Last Responsible Moment can help you understand and protect the flexibility you have to accommodate change for as long as you have it.
For physical products, the 2nd Principle is something like this:
“Welcome new information up to the Last Responsible Moments for making major decisions, in order to stay flexible enough to harness change for the customer’s competitive advantage as long as possible.”
