The myths about Agile generally come from two groups. The first, and high in number, are the Agilists who have almost a religious view of ‘Capital A’ Agile. The second group is comprised of more tenured hardware engineers and their managers. They are both wrong, but for different reasons. They’re correct that a rigid application of Agile software techniques within a hardware development project breaks down quickly. However, when modified for the unique characteristics of hardware design and manufacturing, key elements of Agile allow teams to gain the speed, predictability and product definition advantages that their software counterparts enjoy. Our experience with clients, as well as our primary research, explode the myth that Agile is all or nothing and that it is inapplicable to tangible products. The Agile manifesto itself refutes the notion that Phase-Gate/Milestone and Agile are mutually exclusive. Of the twelve Agile principles contained in the Manifesto, 75 percent are not specific to software. For example, such concepts as “Business people and developers work together daily”; “Projects require motivated individuals, support & trust” or “Face-to-face conversation is most efficient” are not software specific. There’s no reason that these principles cannot operate in any product development environment. Segments such as Medical devices, with hardware and software elements, within a highly regulated environment, benefit from nesting Agile within a Waterfall process.

Embedding Agile - Tips and Tricks

Use Release Planning to manage dependencies: In working on system level products that involve operations, purchasing, safety & regulatory in addition to many other functions, there are often external dependencies and decisions (such as approving a new supplier). Some of these activities don’t normally surface in the sprint level planning. At the beginning of each phase (or phases), use a sprint planning session to determine which sprint resolves external dependencies.

Eliminate status meetings: With an iterative approach, with progress tracking inside sprints, and demos at the end of each sprint, management is better informed about the team’s progress. There is no need for weekly status meetings.

Modify The Definition of ‘Done’: Some hardware deliverables span more than one sprint; so how do you deal with these deliverables when you plan sprints and write your end of sprint ‘Acceptance Criteria’? The solution is to require senior technical people to break down long lead time items (such as tooling Printed Circuit Boards) into smaller measurable pieces. For example, have your PCB partner describe several of their internal milestones and reveal them to you.

Adopt Agile Principles Incrementally

At its heart, adopting Agile methodologies requires organizational change management. It does not happen over-night, and in large organizations, not even quickly. A proven approach is to pilot a project, using team members that have a track record for embracing improvement. Organizations learn quickly from a pilot and then improve incrementally. Agile gurus and guidebooks are sometimes too rigid, imposing an orthodoxy that doesn’t make sense for your culture or your products. Start small, learn the basics, and then improve by modifying the tools to fit your environment.

Finally, give yourself adequate time to pilot and adopt Agile principles to your environment. Corporate culture tends to play a larger role in companies that develop tangible products and change takes time. The culture must adapt to the fact that, when you bring Agile tools to the work, functional managers must cede some control. Since teams that develop tangible products tend to be cross-functional, there are more functional managers, that is, more cooks in the kitchen. This can be a challenge when your team is trying to pilot sprints, daily meetings, and other Agile tools that help to accelerate your teams. Again, the key is to start small, build incrementally, and remain persistent with your Agile adoption. Learn more at TCGen Inc. John Carter is a Founder and a Principal of TCGen Inc.

Photo by rawpixel on Unsplash