As more electronic hardware and software are incorporated into traditional mechanical products, manufacturers are seeking better ways to integrate design activities across engineering disciplines. As a result, many design and development practices are exchanged. One such initiative, Agile Product Development, involves the application of agile methodologies to mechanical design, electrical design and broader product development.
Defining Agile for Hardware
A good place to begin to understand how agile methodologies apply to product development is the Wikipedia entry on Agile Software Development.
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, and a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
Source: Wikipedia entry on Agile Software Development
Interestingly, these characteristics stand in direct contrast to traditional product development approaches, as they did with many software development methods ten years ago. Product requirements are often frozen early on. Engineering organizations are often rigidly structured with clear lines of authority. Development schedules are often laid out far in advance.
Yet, Agile Software Development has met widespread success. Today, most software development organizations use some variation of this framework. But its applicability to product development requires some translation. In Table 1 below, the left column shows core principles of the Agile Manifesto per the Wikipedia entry on Agile Software Development. The right column shows the translation of these principles into Agile Product Development.
Agile Manifesto Principles | Equivalent in Agile Product Development |
Individuals and interactions over processes and tools. Individuals and Interactions: In agile development, self-organization and motivation are important, as are interactions like co-location and pair programming. | Collaboration and problem solving are more important than following a specific process or procedure. Because mechatronic issues span disciplines, engineers will need to organize into the best teams. Furthermore, these teams should be empowered to pursue and resolve issues. |
Working software over comprehensive documentation. Working software: Working software will be more useful and welcome than simply presenting documents to clients in meetings. | Working prototypes, both physical and digital, are more important than engineering deliverables that will eventually be handed off at design release. The focus should be on satisfying the requirements for performance and other characteristics. |
Customer collaboration over contract negotiation. Customer collaboration: Requirements cannot be fully collected at the beginning of the software development cycle, so continuous customer/stakeholder involvement is very important. | A customer or equivalent internal representative needs to be intimately involved in the development process. Because issues will arise time and again during the design of mechatronic products, there will need to be verification and validation steps along the way. This will result in the refinement of mechatronic requirements during the development process. |
Responding to change over following a plan. Responding to change: Agile development is focused on quick responses to change and continuous development. | Emphasis should be placed on the organization’s ability to respond to the development issues over its ability to adhere to a specific process or procedure. The organization should, therefore, be able to respond to issues in mechatronic development in an agile and flexible manner. |
Challenges Addressed by Agile
Obviously, there are some interesting implications arising from Agile Product Development. However, adopting it directly addresses two challenges addressed below.
Trend | Challenge Addressed | Advantage Provided |
The Visibility Mandate for Engineering Operations | Engineering managers must derive new design-based metrics that measure the progress of well-engineered products. | The emphasis on working prototypes over deliverables shifts executives’ thinking on deliverable-based metrics. This emphasis sets the stage to define new design-based metrics. |
The Coming War for Engineering Talent | Engineering managers must find ways to recruit Gen-Y engineers, using benefits other than monetary compensation. | Gen-Yers are a collaborative generational cohort by nature and desire to make an immediate impact. The emphasis on interactions appeals to their natural tendencies. The opportunity to contribute in this framework lets them make an impact immediately. |
Steps to Pursue Agile
There are published reports and consultants that have extensive guidance on how to deploy agile methodologies. However, most of these guiding principles address the needs of a software development organization, rather than an engineering organization developing mechatronic products. Many of the steps are similar, but there are some important differences:
- Involve More Stakeholders: From a people perspective, the development of a mechatronic product requires the involvement of mechanical, electrical and software engineers, as well as manufacturing, quality, sourcing and service organizations. This is a significantly more diverse technical set of people than those that participate in Agile Software Development, which primarily consists of software developers, testing and more. The engineering manager will need to recognize this necessary organizational complexity and assist teams as they self-organize.
- Self-Organizing Structure: At first glance, one might assume that Agile Product Development is chaotic, due to the need to self-organize and de-emphasize formal processes. But just because there is not a formal process, doesn’t mean Agile Product Development isn’t structured. The reality is quite the contrary. Despite this structure, though, there is a transition away from a formalized process. Engineering managers will need to enable their engineers through that transition.