Some Solutions to the Agile Hardware Quandary

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

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 4 comments

Sunday September 27th, 2015 10:55 AM by Jaison

Thank you very much. Great advice and I have setartd investigating that path. How much do you value the importance of a PMP certification? I notice many job postings requiring it or at least showing a preference for candidates who are certified. I never put too much stock into certifications when I hire personnel. It's experience and knowledge that influences my decision but I see that is not always the case with recruiters.VA:F [1.9.22_1171] +7Was this answer helpful?

Wednesday October 28th, 2015 11:29 AM by Vani

/ Hi Phat, Scrum or agile principles won't give you the anwser. I think this is a broad and difficult topic which can't be discussed here on the website because your issue needs more insights about your organization and your individual case. Which skills are you referring to? Programming, Project Management, Communication, etc.? Firing a person depends on your management style, philosophy and policies.You may ask HR companies consultants who have much more experience than us or just drop by at the next agile Vietnam forum and ask some members with years of management experience.Thanks for reading our website!Nhan

Wednesday December 23rd, 2015 01:37 PM by Ervin

I prefer Team Leader, or Team Coach. Project ledear implies a team can only be on one project, which is not always true, especially in support situations.Coach is a great term because a coach is a person that is invested in success/failure (winning/losing), but isn't on the field doing the work. Their job is to provide the mentoring and tools (and environment) for the team to be able to succeed.

Monday December 28th, 2015 11:32 AM by John J. Smith

Ervin, I appreciate your comment, but I must disagree. IMHO, team and project are completely separate. A project is a task, and a team is a group of people who work on the task. A team should have a leader (of course), but a project should also have a leader to serve as it's champion. They need not be the same person.

I also shy away from the term 'coach'. A leader may or may not be on the field, knee-deep in the battle. I have often seen that some of the best leaders will lead by example... something that I wouldn't associate with a coach.

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. www.example.com/index) are allowable. All tags will be automatically stripped

Name (optional) :

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