Below is an adaptation of the original Principles Behind Agile Manifesto, with “software” changed to product and emphasis added, along with TCGen commentary on how we apply this more generally to product development.

Many people bastardize Agile and focus on its processes (SCRUM, product owner). We think that misses the point. These principles are timeless and mostly applicable to hardware.

• Individuals and interactions over processes and tools
• Working product over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

This principle applies to all product — customer satisfaction as demonstrated through active use and value creation — is always the ultimate goal. Agile recognizes that direct observation of usage is key; while it’s always good to listen to what people say they want (or the PM’s interpretation of what’s needed), a good product team always gives primacy to the “proof in the pudding” of direct observation.

Note that continuous delivery is usually not possible with hardware, and so proxies must be adopted. | | Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. | The attitude is right — product development should be viewed as a constant iterative learning cycle to understand what it will take to create value.

However, a change must be weighed against cost and risk. In software best practices, risk of late changes can be mitigated through rigorous unit tests, A/B tests, and an ability to push new software within weeks. In hardware, the risks are much harder to mitigate and thus need to be weighed differently. | | Deliver working product frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. | This again focuses on end-to-end product as the gold standard from which to learn through direct observation.

In hardware teams often must determine the best proxies for this, which could involve simulations, prototypes, or testers. And be sure to get them into outside environments and external users’ hands — so often products fail because the assumptions about how and where and when they will be used prove incorrect. | | Business people and developers must work together daily throughout the project. | We agree, with caveats. Ideally, both parties are looking at direct evidence from customers and both offering perspectives on what is valuable and how it can be conveyed effectively. Even better if the business people are helping to facilitate direct connections between developers and customers.

This principle can be misused if information is flowing from customer to business person to developer — that undermines so much of the value that the principles around delivering working product create. | | Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. | Peter Drucker said “culture eats strategy for breakfast,” and this gets to the heart of it. Seeing working product is great motivation, and the best teams have clear line of sight to how their work every day helps make life better for customers.

We often distinguish between trust and confidence. Leaders must extend trust, but teams absolutely should be delivering the results that build confidence. Working product delivered regularly is the best way to do this, but (especially in hardware) it’s important to agree on the proxies that will be used. | | The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. | We don’t agree with this one. Face-to-face conversation helps build relationships that are super important, and in many cases are efficient and effective for conveying information. But clear documentation is far easier to consume and reference than a conversation, and can be shared more broadly. Video updates can be watched at 1.5x speed and then slowed down for dense areas. Slack updates for quick FYIs work well.

Conveying information requires tailoring the message and the medium and is an art not a science. | | Working product is the primary measure of progress. | Absolutely. In a software world where this can be done every two weeks, this works very well. (And even then, some secondary metrics are often valuable.)

In a hardware world where updates to working product may take months or years, proxy measures must be relied upon more deeply. | | Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. | Yes, teams need cycles of planning, hard work, celebration, and rest. Just like 7 days for a week has become standard for most cultures, team productivity standards are so often in the 2-4 weeks range that this cadence should be considered a default and deviated from only with specific purpose. | | Continuous attention to technical excellence and good design enhances agility. | Yes, these are good proxies for avoiding technical debt and reducing latent risk. Plus, everyone hates wading through sloppy code or poor design in order to do their work. “Cleanliness is next to godliness.” | | Simplicity--the art of maximizing the amount of work not done--is essential. | Yes. Simplicity brings focus, which creates effective teams. Marie Kondo your project plans, backlogs, and work products. There are so many other psychological impacts that come from simplicity. | | The best architectures, requirements, and designs emerge from self-organizing teams. | Yes. This applies equally to hardware and software. But don’t confuse self-organizing with unaccountable. Teams are formed to have a goal and accountability to communicating progress toward it. And remember that this works in conjunction with the principle that the primary measure of progress is working product. | | At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. | Yes. Continuous improvement cycles are essential. Teams exist in a constantly changing landscape, so even a well-honed process must evolve regularly to stay relevant. Classic intervals include the sprint cadence and a quarterly or annual reviews. |