SCRUM for Hardware Design and Development

Summary of how agile product design & development using the SCRUM for hardware methodology can work

If you are interested, watch a review of a good book on this same topic.

Here is my effort at summarizing this approach in a few bullet points:

• When starting to design a new product, there is a lot of uncertainty (e.g. where will difficulties & challenges come up, what components will be a good fit, etc.) and exploration, so any plan is necessarily wrong
• It is very good practice to document some high-level requirements before starting to design a new product, and it is very important to focus on what the target users/customers find most important. Designers should try and provide value in the eyes of those target users, and collect feedback along the way — which may lead to changes in the requirements and priorities. Precise specifications can be written down when the product design has taken shape and is relatively mature, not at the very beginning.
• Traditional “waterfall” project management, with a big planning effort at the start, tends to be late (or very, very late) most of the time. It also tends to let the costs balloon with little control.
• More concerning for a “version 1” product, the traditional approach encourages people to plan for an over-complicated product. The objective of “version 1” should usually be to get to market quickly with a product that is good enough to satisfy early adopters (not the majority of potential customers) and to get sufficient feedback to iterate into a much better “version 2”. Going fast and keeping investment low trumps the pride of delivering a product that is great from every angle. Even Apple’s first iPhone was severely limited, but Steve Jobs set a date and the company had to ship the iPhone 1 by that date.
• That form of traditional “waterfall” project management is not bad in itself. It is always needed, to a certain extent. Taking the time to document the product requirements at the very start, for example, is important.
• In the early exploratory phase of a design effort, an agile approach is preferable. A team follows a rhythm of 1 cycle every X weeks. (Typically 2, 3, or 4 weeks.) It is “time-boxed”. Every time the team completes a cycle, it chooses what can fit in the next cycle.
• In each cycle, the team plans on what to do, does design work, gets to some type of mockup or prototype, and gets that mockup or prototype tested — and, if possible, reviewed by target users. The findings (tests, user reviews, etc.) are then inputs to the planning phase of the next cycle.
• All is tracked on a kanban board. Here is an example from Atlassian:

• On the board, each entry is called a “story”. It mentions some form of product feature, but it always mentions (1) who needs to do (2) what and (3) for what benefit. It should be relatively obvious how to test it and confirm it is acceptable, too. The who doesn’t have to be a user/customer, as it may be needed to enable some other features or drive value in another manner.
• The workload of each story is estimated. If it is too large (for example, it needs several engineers’ work for several weeks), it needs to be broken down into small chunks of work, otherwise, it is very hard to estimate and it may not be possible to complete within 1 cycle.
• The stories that represent important assumptions to test, or that represent a lot of risk to the project, are tackled first.
• Only what can be finished during the cycle is started. The rest is kept in a backlog. Here is an example from the above-mentioned book:

• Each team follows a certain structure. Not just the cycles (exact same number of weeks each time), but also daily communication during the cycle, etc.
• The “product owner” (maybe a project manager) needs to be well aware of the user needs & requirements and works closely with our customer.
• Someone, usually in the engineering department, needs to ensure the process is followed the right way and helps them be productive (protects the team from interruptions if possible, helps remove obstacles…).
• The general organization aims at maximizing the engineers’ efficiency. A quick daily meeting at 9 am eliminates a lot of (ideally all) communication during the day. Each engineer works on 1 thing at a time, as much as possible. The team has a say in prioritizing the stories they will work on in the next cycle (more buy-in means more motivation).
• The engineers (a team of 2 to 7 people) do the job.
• At a high level, this is the scrum for hardware design framework:

• As much as possible, end user/customer feedback is gathered after a cycle. The needs often change based on that. Agile development makes it possible in a relatively smooth manner. Working closely with a few target users is important to gather good feedback quickly.
• There needs to be an effort at keeping the product requirement document updated, otherwise, after a few cycles it is completely useless… that document is very important as the product gets closer to mass production.
• When the team gets to final prototypes and the product design is approved and frozen, the pendulum swings back to waterfall planning. The next steps are usually well-known (less dependent on a product’s specific features). A strict set of approvals must come into play.