SCRUM for Hardware? Yes!
Here’s How to Plan Your Sprints.
SCRUM and Agile management techniques have become incredibly popular in the software development world, but their adoption has lagged in the world of hardware development.
Software and hardware are naturally different animals, but it is possible to adapt the best of what SCRUM and Agile have to offer into the practical realities of hardware development.
Breaking Down SCRUM and Agile
So what is SCRUM and what is Agile? Agile refers to the practice of frequently and iteratively shipping a “product,” while SCRUM is one particular style of Agile development. More on SCRUM in a moment.
The antithesis of Agile is “waterfall.” This is commonly seen on Gantt charts. Waterfall usually assumes an initial stage to gather all the requirements, whereas Agile techniques assume that the requirements will be generated collaboratively as the product is developed.
The shipped product might not be feature complete to start, but it grows and evolves with each iteration. It very much embodies the philosophy of “learning by doing.”
The SCRUM version of Agile breaks up each iteration of a “product” into a fixed time block called a “sprint.” The team keeps a running backlog of features to develop, and during each sprint, signs up to deliver a set number of those features.
Very rapidly, the team learns how many features it can deliver within each sprint, and gets better at estimating how long new features will take.
Hardware vs Software
If you’re mentally making comparisons to the hardware world and thinking “recompiling code isn’t the same as ordering a new PCB,” or “adding a new button in software isn’t that same as adding one in hardware,” well, you’re correct.
Hardware is different than software. The later in the development process you are with hardware, the harder it is to change course or add features. Despite this, you can still take a lot away from Agile principles.
In short, the sprint structure helps the team stay focused, organized, consistent, and on pace for their estimates. It also helps them improve estimates in the future.
It doesn’t mean you shouldn’t make an initial schedule or plan for hardware, but it will give you quick feedback on how realistic that plan is. With real feedback, it can become possible to manage, adjust resources or modify schedules as necessary.
Applying SCRUM or Agile Principles to Hardware
If you’d like to adapt SCRUM or other Agile processes to hardware, here are my two biggest tips.
1. Software sprints deliver features, hardware sprints deliver progress. For hardware, that can mean finishing block diagrams, routing portions of boards, finishing CAD models, completing a design review, or placing PO’s. The most important thing is to have a clear definition of milestones so you can tell what progress looks like.
2. Hardware sprints also need to be sequenced to plan for lead time. This is probably the biggest difference between hardware and software. A unit of effort in software leads to immediate results, but a unit of effort in hardware might not be fully realized until parts come in.
By at least loosely planning a sprint or two in advance, you can sequence, and use downtime while waiting for parts productively on other activities. Finally, it’s fine to tweak the sprint “length” by shrinking or stretching a week or two to get the planning cycles lined up with lead times.
At the end of the day, once you’re out of the prototype phases, you definitely won’t be shipping a new iteration of hardware product each sprint. What you will be doing, is showing that you are making steady progress towards a goal.
I’m not advocating for eliminating traditional hardware development techniques. I personally still use a model of prototyping, looks like/works like models, and production engineering as the overarching framework for my initial planning. That being said, I’ll use SCRUM on a more tactical day to day, week to week, and month to month basis.
