Scrum for Hardware and Systems Development

There are five types of sprint meetings (dark blue circles in the infographic). The number and types of meetings might seem excessive, but they are structured to save time as they keep communications open, brief, and on-point. Typically, these meetings take 10% to 15% of each team member’s time. This leaves 85% to 90% of their time to get work done.

Sprints are designed to result in artifacts (orange boxes) which are either information or physical objects. To make all this happen, there are 13 different activities (numbered circles) in the Scrum process. Before a project begins, there are a few organizational activities (1 through 4).

1. Assemble the team. Scrum teams have 4-9 members who carry out and self-manage all the design tasks: plan, conceive, analyze, build, test, decide, and document. Scrum teams are stable: Some at Saab have been together for more than 10 years.

2. Establish design goals. In the ideal software world, this upfront, macro-planning is minimized. However, for hardware and systems this is essential, just as it is in traditional design processes. This task focuses on establishing engineering specifications that need to be met and not so much on the timing. There are no detailed Gantt charts in Scrum; all the detail planning is pushed to the sprint and daily level. In Scrum-speak, design goals make up the product backlog, a list of all the design requirements that still need to be resolved during the design of the product.

3. Maintain scrum board: One feature common to most Agile methods, but totally foreign to traditional methods is the scrum moard. This is usually a physical board with sticky notes on it. The Scrum board can also be virtual and managed using one of the many software packages available for the task. Product backlog items (the design requirements) are written on sticky-notes and posted on the left side of the board. As they are resolved, they get moved to the right. In software design the backlog is represented in “stories,” as they are the stories customers tell to describe the features and functions they want. For hardware, customer stories need to be supplemented with methods like Quality Function Deployment (QFD) to get a complete picture of the goals. QFD is a method for capturing the customer’s voice and translating it into engineering specifications.

The Scrum Board is usually an actual board with sticky notes on it as seen in this view of a daily sprint meeting of the design team at Saab tasked with developing the oxygen subsystem for the Gripen. The Scrum board can also be managed using one of the many software packages available.

4. Product backlog grooming. Sprint planning begins with the product backlog meeting, the first of the five types of meetings. In this meeting design goals (listed in the product backlog) are rank-ordered based on dependency, uncertainty, and importance. This gives the team a long-term vision of what needs to be done during the design of the product and what is most important to do first.

5. Sprint planning meeting. The second type of meeting, sprint planning, kicks off each sprint. Here the team chooses from the product backlog which goals to address during the sprint. They only choose those they can complete during the sprint period. This selection process is iterative, as we shall see.

6. Setting measures, targets, and tests. One mission carried out during the sprint planning is to identify the tasks—what needs to be done to meet the highest-ranked goals. Each task is refined with measures, targets and tests that define when it is done. Defining tests up front is often referred to as “test-driven development.” In software design, the ideal is to have something customers can test at the end of every sprint. Most software projects do not meet this ideal.

Clearly, it is unrealistic to expect testable hardware at this point, especially after just the first couple of sprints. So, tasks are actually iterations where the test for the first sprint may be the number of concepts developed, the test in the second sprint may be selecting the best concept, a solid model may be the third sprint’s “test,” and so on.

There are three important actions happening in sprint planning: First, each goal or story gets broken down into the tasks needed to meet it. Second, each task is expected to generate something that can be tested at the end of each spring. Tasks worked on during each sprint must deliver something that shows the task is finished. Third, there is tight interaction with the customer. Instead of periodic design reviews at each gate, there are mini-design reviews at the end of each sprint. The increased interaction with the customer is crucial for project success.

7. Set duration of each task. The team next estimates the time each task will take. Part of the scrum philosophy is that a task not completed during a sprint might as well have not been started. This forces the team to break down the design effort into  “bite-sized” tasks or, more accurately, sprint-sized tasks.

8. Choose tasks to tackle. A major part of the sprint planning meeting is  choosing which tasks to take on during the sprint. These tasks are posted on the Scrum board and referred to as the Sprint Backlog. They are written on sticky notes posted in the “to-do” section of the Scrum board, just to the right of the product backlog.

9. Align team members with tasks. The final sprint planning step is to align team members with the tasks. The team self-organizes to best apply members’ technical skills to tasks. Notice that the word “align” is used rather than “assign.” While in highly technical fields, tasks may be assigned to individual team members with the expertise to resolve the issue, often there are many team members who can do the task and they self-align to get the work done. This “planning-in-the-small” makes the best use of each person’s time.

10. Stand-up meeting. In this daily 15-minute meeting, each team member answers three questions:

--What did I do yesterday to help finish the sprint?

--What will I do today to help finish the sprint?

--What obstacles are blocking the team from finishing the sprint?

The goal of these questions is not to judge anyone’s work, but to find what is and is not going well. If there are obstacles, the team addresses them so the task goals can be met by the end of the sprint. This meeting is “planning in the small.” Here the team plans their sprint every day as needed to complete the tasks during the sprint period.

11. Track tasks. During the design cycle, tasks’ sticky notes are updated. If it is being worked on, its sticky note is moved to the “Doing” column; if it is finished, the task is moved to the “Done” column. This way the sprint’s status is always on display.

12. Sprint review. At the end of each sprint, a one-hour design review is held to assess progress. It should not need to be any longer as it is held every 2-4 weeks.

13. Sprint retrospective. During the sprint retrospective the team focuses on the sprint process itself identifying what worked well and what could be done better. This is a strong feature of the Scrum method: frequent reflection and improvement of the work methods and tools used to support the work.

In the software industry, not all teams do all 13 activities. Those most used are: daily standup, 90%; sprint/iteration planning, 88%; retrospectives, 85%; sprint review, 80%; and two- to four-week iterations,69%.

Scrum for Hardware

Software companies that made the switch to using scrum to hone their development practices report major successes. The table below shows survey results on some of the benefits those companies have enjoyed.

From this survey, we can conclude that:

--The software industry has a high percentage of failed or challenged projects. There are no equivalent surveys for hardware/systems projects, but there is no reason to believe the failure/challenged rates are much different.

--The reasons software organizations use Scrum are the same for using it on hardware and systems projects, and the benefits should also be similar. Early hardware adopters such as Tesla, John Deere, Saab Aerospace, Raytheon, Oak Ridge National Labs, Bosch, and SpaceX report such benefits, but there are no surveys or statistics yet.

--Using scrum nearly doubles the chance for software project success. There is anecdotal evidence that it can have a similar effect on hardware/systems projects.

There are many potential benefits in implementing Scrum for hardware. Companies such as Saab, for example, have reduced bureaucracy and encouraged decision making at the lowest possible levels while delivering an aircraft for lower cost with more advanced performance and higher quality. On a personal level, each Saab team member knows what is expected of them, what is desired, not required, as that would stifle creativity, and they make decisions and feel enfranchised.

Saab’s results are impressive and promising for other organizations, but in moving to Scrum is not easy. Statistics on resistance to moving to Scrum in software organizations shows the need for organizational flexibility, and skill development through training and expert experience. Planning and decision making are moved down in the organization changing the control structure, so it is not surprising that organizations resist.

In spite of the organizational, training and discipline challenges, there is no reason to believe that hardware design organizations cannot experience similar dramatic improvements that have been realized in software development.

This article has just scratched the surface of what it takes to move to Scrum. Such a transition requires both organizational and design process changes. It is strongly suggested you get help when starting. Just be sure the help has experience in hardware design because software and hardware design are not the same. Many Scrum software trainers think that because they have had success in software organizations, this mirrors to hardware. It does not. These differences are detailed in the book Scrum for Hardware Design.

Where Did Scrum Come From?

Back in the 1980s and ’90s, the software industry had earned itself a bad reputation for delivering products late (if at all) and with plenty of bugs or defects. To counter that trend, Jeff Sutherland developed Scrum in the late 1990s as a formalized way to design software on schedule, on budget, and be relatively bug-free.

The software world had great incentives to improve its design process. Consultants at the Standish group in its annual Chaos Report on IT projects found that 31.1% of all IT projects in large organizations were cancelled before they were completed. Another 61.2% of projects were “challenged,” meaning they only met two of the three project success measures: cost, schedule, or scope. That meant only 9% of all IT projects were meeting all three measures.

Once the Agile/Scrum ideas attracted disciples and believers based on success, another consulting company surveyed software organizations and found that software projects using Agile were nearly twice as likely to succeed than those using the traditional waterfall or sequential methods.

Further Reading

The 2019 book Scrum for Hardware Design is available both as an ebook and hard copy. The book is a supplement to The Mechanical Design Process 6th edition and Case Studies for the Mechanical Design Process, also by David G. Ullman.

David G. Ullman is an engineer, educator, certified Scrum Master, and textbook author, having published “The Mechanical Design Process” now in its 6^th edition and, more recently, “Scrum for Hardware Design.” Joshua Tarbutton is a professor at the University of North Carolina at Charlotte and owns Bravo Team, an engineering design and product development firm. He is a certified Scrum Master and practices it with his students and staff at Bravo Team LLC.