What Most Agile "Gurus" Get Wrong About Hardware Development

Agile methodology, rooted in the world of software development, has been hailed as a transformative force in the tech industry. However, as we venture into hardware and electronics development, the seemingly smooth adaptation of Agile principles encounters a labyrinth of challenges and misconceptions. In our first installment of this three-part exploration, we analyzed Agile challenges arising from differences between hardware and software development. In this article, we examine the myths propagated by Agile "gurus."

Before we delve into the intricacies of Agile in electronics hardware development, it's important to clarify that our intent is not to disparage Agile coaches and consultants. We recognize and appreciate their good intentions and enthusiasm to assist customers in reaping the benefits of Agile methodologies. While some critiques may arise from a limited understanding of hardware nuances, the intent is not to criticize but to adapt Agile principles effectively to meet the specific demands of hardware development. Our focus is tailoring Agile tactics to harness its benefits in this unique context, modifying the approach but preserving the principles.

Myth #1: You Must Stay Flexible and Adapt

Agile gurus correctly extol the virtues of iterative execution, feedback loops, and rapid adaptability that have thrived in the digital realm of software. However, the transition of these principles to the tangible landscape of hardware and electronics introduces a layer of complexity not found in the pure digital spectrum. Physical solutions, unlike their software counterparts, need to be "done" to order parts, fabricate molds, and meet stringent manufacturing needs. Agile's call for constant change collides with the unforgiving nature of hardware’s ripple effect when even minor changes are required late in the game.

In response, modifying Agile for hardware development requires a paradigm shift. It's not about ceaseless modifications but informed, strategic adaptations and prototyping. These are based on rapid learning and execution cycles that aim to maximize value within the constraints of time, budget, and resources. The dance between Agile agility and the demands of physical product finality requires more conscientious iteration planning and a deep commitment to risk reduction throughout the project.

Myth #2: You Must Develop a Working Prototype Every Sprint

While developing a fully functioning prototype every two-to-three week "sprint" is often propagated by Agile purists as a universal "must" to be Agile, the practical feasibility of this approach crumbles in the face of hardware and electronics development (and budget) reality. The idea to build something, demonstrate progress, and use this outcome to gain valuable technical and commercial feedback to inform your next iteration is right. However, each hardware project is a distinct entity with its own goals, dependencies, lead time constraints, areas of needed innovation, and risk. And each project deserves its own unique approach to prototyping and learning.

To truly embrace Agile hardware product development, teams must shed the one-size-fits-all mindset. Instead, they must make a careful examination of project needs and then collaborate to derive a creative, learning, and prototyping strategy. It’s important to recognize that a "prototype" can be any demonstrable output ranging from a preliminary brochure to a foam mockup (like Steve Jobs’ famous iPod mockup that fits "1000 songs in your pocket"), and even include partially or fully functioning prototypes.

Myth #3: Add Stories to The Backlog and Just Get Started

An inherent strength of Agile methodologies lies in their capacity to kickstart a project much faster than traditional waterfall approaches. In fact, for Agile hardware electronic projects, we’ve seen a significant reduction in the period from concept identification to development initiation. This period, which often spanned many months or even years under a traditional phased approach, has been condensed to a matter of weeks or days with Agile methods. Of course, part of this dramatic outcome is how we define "development initiation."

For software, this is straightforward. Agile gurus champion the writing of User Stories to define software features, prioritize them into a backlog, and kick off a Sprint. However, in hardware, at least a minimum of upfront planning is necessary to guide the project in the right direction with an understanding of the architecture, key desired attributes, constraints, and other factors. This upfront effort can seemingly clash with the Agile principles of "working software is the primary measure of progress" and "welcome changing requirements, even late in development."

Reconciliation lies in finding a balance by adapting commonly understood Agile tactics to the front end of product development. Agile project management for hardware allows for swift initiation by aligning to the strategic intent of the project and accepting far more unknowns than traditional approaches. Teams can then collaborate using Agile’s iterative learning to define the optimal solution, coupled with a mindset open to strategic changes that enhance the product value while staying within schedule and resource constraints.

Myth #4: Define All of Your Work Items as User Stories

One critical directive many Agile gurus espouse is that all development work should be defined as User Stories. The advice continues to say that system components, interfaces, other engineers, etc., should be treated as "Users." This advice has most electronics and hardware developers scratching their heads and struggling to comply.

One primary reason software teams have so readily adopted Agile practices is because documenting customer needs with traditional requirements documents and detailed use cases was extremely wasteful and added little value to the team. Why not just declare what the user is trying to do, write a User Story to document the feature, and then treat this as a development task? It’s not only self-documenting, but if these stories are consistently prioritized and validated with customers, we have the perfect closed-loop system for responding to change and optimizing value. Nice!

This attempt to write User Stories directly as work items for hardware development while tracing them to valuable customer outputs is often the Agile breaking point for many hardware teams. Defining hardware is just different than defining software. Traditional Product Requirements Documents (PRDs) and functional specifications are not only comforting to hardware developers but also provide the details necessary to break down and deliver their work. Asking developers to write a User Story such as: "As a processing unit, I need voltage regulation to ensure clean input…" defeats the purpose of capturing customer value through User Stories and adds non-value waste that software developers were so anxious to remove with Agile principles.

As Mike Cohn, an early thought leader in Agile for software, defines it: "A User Story is a short, simple description of a feature told from the perspective of the person." The key word here is "person". Agile for hardware teams can get significant value from writing User Stories but must use them to capture customer needs from people, not define work items. These stories must then be translated to product attributes and related work items that satisfy the desired outcomes with techniques that make sense for hardware developers.

Myth #5: You Must Have Dedicated Team Members

A LinkedIn poll by Vitality Chicago showed that 54% of Agile practitioners say having a dedicated Scrum or Agile team (implying dedicated team members) is an essential Agile rule. While there is no discussion of dedicated teams in the Agile Manifesto, Agile gurus often treat this as a rule, and it’s hard to argue there would not be many benefits to having team members 100% focused on a project. There would be few excuses for not hitting commitments, nothing to distract success, and no one saying: "This other project is a higher priority this week!"

However, if you’ve ever worked in a hardware development environment, you know that having dedicated team members would be a luxury few organizations can afford. The nature of hardware development is that architects, lead designers, and other subject matter experts (SMEs) are often needed on multiple projects. A company might have one radio frequency expert who is called upon when their expertise is needed, a layout specialist who is needed at key times, etc. Hardware development teams can still embrace and leverage Agile methods, but having dedicated team members is typically not an option. Therefore, having an Agile-supportive resource management approach is critical to long-term Agile success.

#Myth 6: Agile Is the Sum of Its Defined Roles, Rituals, Ceremonies, and Vocabulary

Two teams are working side-by-side in a company: a hardware team using a traditional waterfall approach and a software team using Scrum methods. A hardware developer walks by the conference room where software developers are gathered in a circle and hears, "Ok, welcome to our standup. During the last sprint, we struggled with user story point estimations and acceptance criteria. Our scrum master shared our latest burn-up and facilitated a retrospective to address the issues in our backlog grooming so we can increase velocity. Let’s fist-to-five on how we’re feeling about the changes." A range of fist and finger configurations quickly rise.

The hardware developer, although intrigued, can’t help but feel a bit perplexed by this bizarre ritual and abundance of unfamiliar terms, wondering how these Agile methodologies could possibly translate into his world of tangible hardware development. "Did I stumble into a cult?!" he wonders to himself.

Often, Agile gurus are so steeped in the language and culture of Agile for software that they believe hardware teams must adopt the very same ceremonies, roles, tools, and language to truly "be Agile." Ironically, the first principle in the Agile Manifesto states, "Individuals and interactions over processes and tools." I think we can build on this and further state, "Individuals and interactions over processes, tools, rituals, and dogma." While agreeing on language, meeting formats, and specific activities to build an Agile mindset and systematic way of working are all critical for success, adopting the specific rituals and vocabulary of Scrum or Agile for software is not. Hardware teams must look at the purpose and intention of each Agile element, ceremony, and role and determine what and how each one can best meet their needs.

Bridging the Agile-Hardware Gap

As you contemplate if an Agile approach is right for your hardware and electronics development efforts, the conventional "wisdom" propagated by well-intentioned Agile gurus often falls short in guiding the more nuanced, adaptive approach needed by physical product development. The path to successful Agile implementation in hardware involves a thoughtful blend of flexibility, upfront preparation, iterative planning, and a conscientious approach to converging on the most valuable solution possible in the shortest amount of time.

In the concluding segment of our three-part series, we will delve further into harnessing the advantages of modified Agile for electronics hardware development, all while upholding the core principles of the Agile methodology. Are you interested in exploring the topic in more detail? Watch the webinar!