What is Agility in Hardware?

One area that I've been working through lately is how to relate the good habits of the Agile ideal to mixed hardware/software projects.
There are significant, good behaviors in Agile methodologies that relate directly to all product development:
1. We can't be 100% sure of what done looks like when we start, so stay flexible and have a constant conversation with stakeholders/product owners to ensure that the design is, in fact, meeting the needs.
2. Perfection is the enemy of good enough.  Don't add extra cost/time into solving problems that don't need to be solved.
3. Focus activity on maximizing feedback.  Spend time de-risking your approach as quickly as possible--addressing both technical and business risks as quickly as you can with actual implementation
4. Swarm activities.  Single piece flow is the key to optimizing the queues.  Activity should be focused on tangible outputs, at the expense of perfect efficiency in utilizing staff and project resources.

"Being agile" is fundamentally about managing "fixed points."  These fixed points include everything from getting buy-in (feedback) on decisions to architecting in such a way that designs can adapt.  This affects your approach to every stage of the project.  Here are some things I'm trying to work through:

How do you manage change from a hardware perspective?
How do you build in flexibility in hardware so you can enable that change?
How do I adopt a framework that will work for not only hardware--but software?  How truly applicable are Agile frameworks like Scrum, when I'm operating in an environment where getting MVP requires fixed-bid, multi-month project plans?

Below is my scratchpad of what I have so far.

• Requirements
• When developing marketing requirements, the goal is to capture what is needed now, but also to maximize your options for the future.
• Architecture
• Architect for high option value
• Portability, scalability, maintainability
• Have a wish list (technical roadmap) so the team can see where flexibility is required
• Allow flexibility to adapt to an evolving definition of what "success" means
• Most times, we don't know perfectly what will sell. This understanding will also evolve during a project.
• Architect for your economics
• In particular, consider whether your company is more sensitive to staffing or to unit cost
• Development
• Find--and take--one big risk per project
• You'll have plenty of risks, but refine your plan until you only have one "project killer"
• Keep in mind that risk usually originates from doing something new--which means you're learning! 
• Then, mitigate risk aggressively--almost irrespective of the project plan