5 Ways Agile Improves New Product Development (Pt. 2)

In our first part of this two-part blog series, we asked the question, should you consider an agile methodology to support new product development, beyond just software?

Let’s continue to explore that question.

In part one, we explained what agile is. Then we listed the first two reasons to consider an agile methodology:

1. 1. Support Evolving Requirements.
   2. Meet Customer Needs

Now let’s continue with the list and reveal the next three reasons:

3. Find Problems Sooner

It’s no secret problems found late in the development cycle can have a very negative impact on both the schedule and budget. As products grow in complexity, there are more interdependencies across components. Even small changes can significantly impact the rest of the product. The later you find problems, the bigger the impact. By moving in smaller iterations and testing along the way, you can catch more problems early on, when they are easiest to fix.

However, mechanical components are not like software. With software, it is easy to run tests regularly. With a mechanical part, it takes time to build a prototype. Plus, it would be cost prohibitive to constantly build a prototype every few weeks. However, this is where simulation-driven design comes in. By regularly testing models with simulation, engineers will get the needed early insight to validate the design. Further, for physical prototypes, 3D printing offers a quick and cost-effective way for building prototypes.

4. Tap into the Expertise of the Complete Team

One of the biggest challenges of system development is the inherent knowledge silos across disciplines. Collaboration across the team can be a significant challenge. Traditionally, a “throw it over the wall” mentality influences how hand-offs transfer ownership to someone else. Subsequent challenges often become someone else’s problem.However, as products become smarter, and technology more pervasive, perspectives from different engineering disciplines will lead to better solutions.

Agile embraces a more collaborative approach. First, it requires daily stand-up or scrum meetings, where engineers present the work they did the previous day. These meetings let the team know about each other’s progress and identify potential risks. While the idea of more meetings may be an anathema to many engineers, the meetings should be quick, targeted to last 15 minutes. They may expose opportunities to brainstorm with others for potential solutions or identify additional skills the team may need. Also, agile encourages individual interactions over process, so teams are encouraged to be self-organizing, self-directed, and product focused. This way, individuals assume more ownership and feel more empowered to make decisions rather than wait for approvals. Product complexity can make it impossible to stay on top of everything or possess all the technical skills to make the right decisions. Therefore, management and hierarchy can be a bottleneck. Agile addresses this by shifting more power to the technical talent who has the expertise to understand the problem best.

5. It Doesn’t Mean There Are No Requirements

Many shy away from an agile process because they believe it means getting rid of requirements. While agile does value a working product over documentation, it doesn’t mean there are not any requirements. The difference is in how requirements are defined and documented. Agile focuses on customer needs, so requirements are in the form of user stories which detail the requirement from the customer’s perspective. Also, user stories must include acceptance or test criteria. Agile also avoids fully documenting all requirements up front. The idea being, why invest a lot of effort documenting something that will change anyway. What you will have is a backlog of user stories that the team will develop over time. The user stories may start at a very high level, and then as the design progresses, you may need to break them down into more detailed user stories.

Adapting Agile with a Requirements Management Solution

While many of the principles of an agile approach can apply to other parts of development beyond software, software and mechanical design are different and you will need to make some adjustments. For example, with software development, agile encourages teams to be located together, and sticky notes are often used to document user stories and associated the tests. However, when you extend agile beyond software, co-locating becomes less feasible. Sticky notes will not work with distributed teams. Instead, you need a system that will allow everyone central access to the user stories. You will need traceability across user stories, especially as they become more detailed so you can trace back to the customer need. You will also need traceability to the test criteria. With the team assuming more ownership, you should have visibility into who is doing what as well as a record of who did what. Finally, you need a system that supports frequent change.All of this points to a requirements management solution that supports multiple engineering disciplines and enables the required traceability. With the right requirements management solution, you can support an agile process and make it work across multiple engineering disciplines.

To learn more about selecting the right requirements management solution, access the on-demand webinar, Better Requirements Management to Save Your Bottom Line. The following video provides a brief introduction to the webinar.