Some Solutions to the Agile Hardware Quandary

by John J. Smith on Saturday November 08th, 2014 04:41 PM

Introducing Agile into a hardware development process presents quite a few problems that just aren't found in a software-only scenario. Some of these are the nature of the beast, others are remnants of days gone by. Some require the retraining of team members. Others require a small change in definition. In all cases, there are ways around the problem.

To be clear, there are scenarios where hardware development can fit into Scrum sprints. Designing FPGA firmware is one scenario, but the development process for it is so close to software that it is an easy fit. Another scenario is combining Commercial-Off-The-Shelf (COTS) cards into a working device. Though some software groups consider this a form of hardware design, it is really just integration. The hardware development scenario I am talking about is anything that requires a custom PCB.

Redefine Working Hardware
On of the tried-and-true precepts of Agile development is that each "sprint", or "cycle", should result in a releasable product... usually within 2 to 4 weeks. This can be extremely difficult in a hardware scenario, especially if your Contract Manufacturer (CM) tells you that it will take 6 weeks to build your boards.

Rather than sticking to this notion, it is better to define a set of milestones that can be met at the end of a cycle. All necessary team members should concentrate on this to the exclusion of all else.

Break the project into sub-projects
If your custom PCB is complex enough, it might be better to break it into sub-sections that can be completed as individual prototypes. These sub-sections can be tied together by a backplane board or cables as a temporary form of interconnect. When all modules are completed, they can be efficiently combined into a cohesive unit. There are many advantages to this:

Vary the length of cycles when necessary
This is one of the major points that causes Scrum advocates and hardware developers to butt heads. Scrum advocates will tell you that everything can be broken down into tasks that take less than one week. Hardware developers will tell you that this isn't always true. In a way, they are both correct. However, hardware tasks don't tend to break down as easily as software tasks. Some tasks, like PCB placement of high-speed components, are far more efficient if you adopt a holistic approach. Every component placement depends on all other placements. Breaking this down would cause nightmares.

Avoid analysis paralysis using small teams
Having a daily standup that includes 15 team members is OK, as long as you can keep them to less than 15 minutes. However, planning with a team of 15 gets to be unwieldy very quickly. Keep the number of team members close to 5 if possible. If you do end up with 15 team members, it is probably better to break them into temporary groups of 4 or 5 for planning meetings. You can then substitute a weekly meeting of about 1 hour where the entire 15 member team is presented with progress and planning objectives of the smaller groups.

The reason for this suggestion is that a hardware development team should contain members from a wide variety of disciplines. You will need hardware designers, software engineers, QA engineers, product engineers, etc. Having all of the members from all of the disciplines present at all of the meetings will be a waste. Keep the scope of most meetings narrow, with only the necessary members in attendance. The weekly team meeting provides plenty of time for members to catch up and add their opinion.

Always remember: Don"t work for your process. Make your process work for you.
An old saying, but a good one. I've seen too many failures cause by teams trying to fit their projects into a process (and yes... IMHO Scrum IS a process because it REQUIRES you to do things. Frameworks don't do that... they just provide tools). It's far better to use what makes sense in your environment than to adhere to the letter of some script thought up by someone who has no idea what your day-to-day requirements are. Look around for ideas on how to improve your process, but don't be afraid to abandon them if they fail. In the end, you will be much better off.

There are no comments yet

Add Your Comment

Note: This is an anonymous comment page, so we've taken drastic measures to eliminate spamments. Any comment that looks like it contains a link (href=[anything]) or a URL ([anything]://[anything]) will be shunted to a secondary page, where you will have the opportunity to remove the unallowed text.

General references to web sites or pages that would not result in an SEO-friendly link (i.e. are allowable. All tags will be automatically stripped

Name (optional) :

Email (optional, not publicly displayed, but available to post author for offline discussion):