In this concluding segment of our Demystifying Agile series, we navigate the intricate landscape where hardware development intersects with Agile methodologies. While the core principles of Agile offer a solid foundation, the need for a reevaluation of tactics becomes imperative when applied to the unique challenges of electronics hardware. In our journey of exploration, we will unravel the common elements and rituals of Agile and how we can transform them in the context of tangible product development.
Prior to delving into the tactical adjustments that can elevate daily software Agile practices to a potent advantage for hardware development, it's crucial to initially embrace the fundamental tenets of an Agile mindset. A good place to start may be considering the intentions of the Agile Manifesto and modifying the language to meet the needs of hardware development. The following table offers one potential Manifesto for Hardware Development.
A simple summary of each manifesto intention might be, "Let’s work together and use an iterative development and learning approach to discover and deliver what customers really value." Of course, this would make sense for almost any project, and it’s critical to keep these basic tenets in mind as teams get ensconced in the day-to-day development tactics.
Agile's iterative nature may sometimes give the impression that early planning takes a back seat to just getting started. However, a certain level of upfront planning is essential in hardware development to navigate the intricate process of designing and developing physical and electronic products. Instead of an exhaustive upfront plan, think of it as a roadmap that guides the team on a development journey through iterative learning and execution.
Early planning in Agile hardware development involves setting clear goals, defining milestones, and conducting a risk assessment mitigated through a thoughtful prototyping and feedback strategy. By doing so, teams can strike a balance between Agile's adaptability and the structured planning needed for successful hardware development.
As discussed in our previous article in this series, Agile "gurus" often urge hardware teams to fill their backlogs with User Stories to define tasks. Let’s consider a User Story for hardware and assume you’re planning to develop a new forklift. You write the following User Story:
"As a user, I want to be able to quickly pick up my material so that I can save time moving inventory."
Does a hardware developer know what to do? Probably not. There are too many facets of the problem to solve. The implementation might involve the speed of the forklift, the accuracy of the fork attachment, intelligent inventory sensing, the orientation of the inventory, and many other factors. Rather than specific features or tasks, these User Stories for hardware should become customer goals rather than product requirements and work items.
User stories have their place in Agile hardware design flow to focus on the needs of customers and clarify results customers are trying to achieve. However, since User Stories for physical products cannot be directly translated into features, attributes, or tasks, they become the starting point for developing a task backlog rather than backlog items themselves.
Calculated prototyping is a linchpin in hardware development, and its significance cannot be overstated. Agile evangelists tout the virtues of rapid software releases, but in the hardware realm, the emphasis should be on strategic prototyping. Each iteration should be purposeful, addressing specific design challenges that resolve both technical and commercial issues to reduce risk and bring the product closer to optimal value.
Consider prototyping as a series of deliberate steps, each contributing to the overall product development process. The Agile principles of iterative development and customer collaboration over contract negotiation remain intact, but the focus shifts towards collaborative prototyping sessions, where customer feedback and technical validation play a pivotal role in refining the physical product.
Agile methodologies advocate for flexibility in adapting to changing requirements, but in the hardware world, this flexibility should extend to the iteration cycles themselves. Rather than adhering strictly to fixed-length sprints, hardware development benefits from a more fluid approach.
Sprint planning, typically established as one to three weeks for software Agile, provides the engine for both planning and execution. In contrast, Agile project management for hardware requires a more strategic approach. This involves employing longer, flexible iteration cycles for strategic guidance and shorter execution sprints, allowing each discipline or sub-system to focus on achieving the iteration goals with minimal distractions.
Flexible iterations allow the team to adjust timelines based on the complexity of the hardware development phase. For instance, early stages may benefit from shorter evaluation and concept development cycles. Conversely, a valuable learning prototype may require a longer iteration cycle to accommodate lead times and integration. Additionally, other iteration cycle times might vary to align with the specific problem trying to be solved. This adaptive approach ensures that the team has clear learning and execution milestones, maintaining momentum, driving a consistent sense of urgency, and reducing wasted effort without sacrificing quality.
Agile's commitment to customer collaboration remains pivotal in hardware development. However, the challenge lies in adapting customer feedback loops to the physical nature of the product. Customer input is not just about software features; it extends to the look, feel, and functionality.
Hardware teams should establish continuous feedback mechanisms that go beyond digital interfaces. Customer involvement in hands-on product testing sessions, prototype unveilings, and collaborative design workshops becomes indispensable. This approach not only aligns with Agile principles but also enhances the customer's role in shaping the physical product.
The daily stand-up, sprint planning, and retrospectives–these are the rituals that define Agile. In hardware development, however, a reevaluation of these rituals is necessary for seamless integration. The daily stand-up, for instance, should transcend digital progress updates to include discussions about physical prototypes, supply chain challenges, and testing outcomes. The structure and timing should also be reconsidered to ensure they are valuable to the team. Some teams find daily discipline standups sandwiched with semi-weekly cross-discipline standups for a good balance, while others meet as an entire cross-discipline team three times a week.
Retrospectives should also be reconsidered as hardware teams must delve into the effectiveness of physical iterations, manufacturing processes, and collaboration between hardware and software teams.
As we navigate the intricate dance between Agile principles and hardware development tactics, the key lies in finding a harmonious blend that capitalizes on the strengths of both. Deliberate but rapid upfront planning sets the stage, prototyping strategies refine the product, flexible iterations maintain momentum, customer feedback loops guide the way, and rethought Agile rituals provide a framework for collaboration.
As we conclude our Demystifying Agile series, the fusion of Agile principles with hardware development tactics emerges as a journey of exploration and adaptation. Yes, Agile can work for hardware development. The principles are sound, but the tactics need a re-think to harmonize with the intricacies of tangible product development.
Want to learn more about the world of hardware development through the lens of agile methodologies? Watch the webinar and learn what you need to succeed in the field!