13 Challenges When Applying Scrum to Hardware Design - Jonathan Cartu Internet, Mobile & Application Software Corporation
836
post-template-default,single,single-post,postid-836,single-format-standard,qode-quick-links-1.0,ajax_fade,page_not_loaded,,qode_grid_1300,qode-theme-ver-11.2,qode-theme-bridge,wpb-js-composer js-comp-ver-5.2.1,vc_responsive
 

13 Challenges When Applying Scrum to Hardware Design

13 Challenges When Applying Scrum to Hardware Design


Scrum has become a popular method for developing and designing software. And why not? There’s clear evidence it improves the resulting software’s quality, shortens time to market, and even increases team members’ job satisfaction.

The obvious question, then, is why isn’t Scrum used more widely for designing hardware? It can and should be, and is having success similar to what it has earned developing software. But, Scrum for hardware design—designing mechanical devices, PC boards, and everything else that is not software—is more challenging than designing software.

This article lists 13 challenges that make it more difficult to use Scrum for hardware development and suggests ways to overcome them.

This table compares Scrum and Waterfall software development. It shows that firms using Scrum dramatically reduced their failed projects (those canceled or never finished). At the same time, they nearly doubled the projects that came in on time, on budget, and with functions the customer wanted. The number of “challenged” projects (those missing some of their targets) remained essentially unchanged regardless of process.This table compares Scrum and Waterfall software development. It shows that firms using Scrum dramatically reduced their failed projects (those canceled or never finished). At the same time, they nearly doubled the projects that came in on time, on budget, and with functions the customer wanted. The number of “challenged” projects (those missing some of their targets) remained essentially unchanged regardless of process.

Making Hardware Modular

Software teams have long understood that modular architectures limit the ripple effect of changes. In software, modular architectures allow an application to be broken into chunks of code, each of which provides a small set of functions. Changes in one module rarely effect another module. Therefore, modules can be developed as practically independent design tasks.

In hardware, form and function overlap, making modularization more challenging. When one module is changed, other modules that work with the changed module to create a function might also have to be updated. These effects can largely be controlled by designing around known, stable interfaces between modules. As the design matures from constraints to configurations, to connections, and finally to components, interfaces can be designed that separate, as best as possible, the form-function interrelationships. This design philosophy forces product configuration or architecture to be established early, effectively defining functional modules. To accomplish this, connections or interfaces between modules need to be designed first. These become the known, stable interfaces between modules.

For example, Saab, during the design of its JAS 39 Gripen E fighter aircraft, used Scrum for hardware design. They overcame the modularity difficulties by focusing on the interfaces early in the process. The aircraft design effort was divided into teams aligned with the project organization. As the design progressed from concept to detailed design, teams worked almost autonomously within known, stable interfaces.

The trick is to define interfaces and make them as simple and stable (i.e., unchanging) as possible. This lets the design efforts proceed independently on both sides of the interface. Later, the interface can be redesigned if needed as a separate project or as part of the ongoing Scrum activities. Making modules plug-and-play with known stable interfaces is a goal encouraged by the Scrum framework.

The Tesla Pod is an extreme example of known, stable interfaces. To even consider such a modular car, the interfaces between the chassis and all the different body styles had to be clearly defined and unchanging for the concept to work. Not only must the physical surfaces be known and stable, but more importantly, all the functions—the flow of information and energy—that bridge the chassis and bodies, must be known and stable.The Tesla Pod is an extreme example of known, stable interfaces. To even consider such a modular car, the interfaces between the chassis and all the different body styles had to be clearly defined and unchanging for the concept to work. Not only must the physical surfaces be known and stable, but more importantly, all the functions—the flow of information and energy—that bridge the chassis and bodies, must be known and stable.

Difficult to Develop Hardware in Short Sprints

The ideal goal of each two- to three-week sprint in the Scrum method is “a potentially shippable increment of product functionality.” This goal is difficult to achieve in software and even more challenging in hardware. In fact, many software groups set more modest-yet-demonstrable acceptance criteria for each sprint that are not actually shippable. Setting realistic acceptance criteria for each sprint task is key to using Scrum to design hardware design.

Software development grows by combining small functional sections over time. Hardware often cannot follow this path. It is more commonly built out of components and assemblies that address specific features and functions. Thus, the goal of a hardware sprint may not be a functional but may focus on designing a component or assembly.

Scrum success depends on setting realistic sprint goals. Where the goal is a shippable increment, the reality may be the team demonstrating that “we understand the question,” “we have a demo of this function,” or “we have a working prototype of this feature.” The challenge is to write sprint goals with acceptance criteria that say “We have done enough for now.” In other words, the goals should describe small bites that lead toward “a potentially shippable increment of product function” that can be completed during the sprint. One approach is to identify the minimal viable product (MVP) for the current stage of development and work toward getting that product completed in the current sprint cycle.

For example, a sequence of three-week sprints for a specific module might show the task goals for each sprint, as shown below.G4 Sprintsequence

Hard to Add Features to Finished Hardware

Software products evolve through a series of releases, each adding new features. The functional independence of software modules makes it relatively easy to add and subtract features to meet changing requirements. This is seldom possible during hardware design because adding functions may can cause unintended consequences due to the interactions between form and function. In fact, “feature creep” (adding new features during the design process) can be fatal during hardware development due to this interaction and cause costs and delivery dates to spin out of control.

If a team tries to design hardware simply by adding features, it can end up with nail clippers such as those shown below. Clearly, adding ever more functions will only result in a worse mess.

An overdesigned nail clipper has way too many functions.An overdesigned nail clipper has way too many functions.The Mechanical Design Process, 6th Ed.

Hardware is More Difficult to Simplify

If a particular algorithm used for a software function is inefficient, it is not expensive to rewrite and update the…

[

Computer Network Development Jonathan Cartu

Source link

No Comments

Post A Comment