The Great Agile Hardware Myth

What’s completely clear is that agile was created by software developers for other software developers that write software. Agile was not created for hardware developers that build hardware so there can be no such thing as agile hardware, right?

Nope. Wrong. I’ve heard a few comments to that effect over the years from people that are just mildly familiar with agile. I’ve heard similar comments from others honestly trying to wrap their heads around it while tripping over preconceived notions and losing themselves in hearsay. Truth is, what it means to be agile is not cut-and-dried, even within software nevermind hardware. I figured it’s finally time to take a step back to clear a few things up so that people new to the discussion can form a healthy definition for “agile hardware”.

Myth Reality
Agile is just for software. Agile started in software but it’s being adopted and applied in other kinds of organizations like marketing, project management and hardware.
There’s a strict definition that you must follow in order to call yourself agile. The spirit of agile software is derived from the agile manifesto which is a list of 4 values and 12 principles. The details regarding how you abide by those values and principles are up to you.
All agile teams do exactly the same things in exactly the same way. There’s a lot of variation when it comes to agile teams. Ultimately, teams chose the framework(s) and practice(s) that work for them, their customers and their products. No two teams are exactly the same.
Agile software practices must be applied in hardware the same way they’re applied in software. Even within software development, teams tailor practices to suit their own needs and abilities so we should be expecting the same. Some practices will be completely portable, others will require modification and a few may not be worth the trouble.
Agile adoption is an all-or-nothing endeavor. You can take on agile practices at a rate you’re comfortable with. You can test the water by picking up 1 practice at a time or jump right into the deep end. There is no wrong way to get started.
To adopt agile, you need permission from management. While some practices are more visible than others and do require a “heads-up” with management and/or teammates, you’ll be able to experiment with many of them without anyone noticing at all.
Agile adoption should be initiated by management. Agile was created by developers for developers. A little help from management won’t hurt but it’s probably best to have developers driving the bus.
Agile adoption is a major change that affects everyone. See above. Even as an individual you’ll find opportunities to pick-up agile practices without requiring any change from management or teammates.
Agile is scrum. Agile is not scrum. Scrum is a framework that many agile teams use but there is much more to agile than just scrum (See: extreme programming).
I need to do pair programming to be agile. Pair programming is a practice that many agile teams find valuable but you don’t need to do anything.
I need to do TDD to be agile. Many teams find TDD valuable but again, you don’t need to do anything.
I need to ship hardware to our customer every week/month to be agile. Iterative/incremental development are practices that many people consider to be fundamental to agile development. It is not required, though, to ship product to your customer iteratively. While many agile software teams deploy product incrementally, others don’t.
I need to do X to be agile. I think you probably get the idea now… there are no practices that you need to do to call yourself agile.
Agile hardware means we need to tape-out an ASIC every month and send it to our customer. Seriously?
Agile and lean are the same thing. Agile is agile and lean is lean. There are similarities but ultimately they are different.
Agile can only be applied in hardware verification because verification is like software development. Many people believe verification is a great place to start but that doesn’t mean it’s the only discipline to which agile can be applied.
Agile can’t be applied in physical design because the tools take so long to run. TBD. You already hear people say “incremental” when it comes to physical design so I don’t think it’s as crazy as some people think.
We don’t need agile development because everything is fine in hardware development. Everything is fine in organizations where they ship defect-free products on time while their employees avoid burnout by putting in a reasonable workweek (i.e. ~40hrs). Unless that’s your organization, everything is not fine.
Only small organizations and teams can be agile. Our company is too big. Some practices are better suited to small teams but any size team or organization can be agile.
Only large organizations and teams can be agile. Our company is too small. See above.
We’re already agile because we concurrently do design, verification, software and implementation. Concurrent development is not agile development.
Adopting agile is a high risk decision that threatens your ability to deliver products. Dismissing agile is a high risk decision that threatens your ability to deliver products :).
My buddy had a bad experience with agile so that means I’ll have a bad experience, too. Not everyone has fun at Disneyland. Some people get bad sunburns or are abducted by Mickey Mouse and kept in an underground lair for weeks on end with only bamboo shoots and warm Dr Pepper, but many of us aren’t. It’s the same with agile.

I think that pretty much covers the basics. If there’s any myths that I’ve mithed, feel free to add them in the comments. If we have enough, maybe someday we can come back for a round 2!


2 thoughts on “The Great Agile Hardware Myth

  1. Always interesting to read about folks trying to make hardware development more agile. Personally, I think that there is one limiting factor to agility with current design flows: the languages that are used for design. For example, when developing incrementally, you sometimes need to do some refactoring, which is well supported by many languages and tools for software. This happens frequently when designing hardware too, where you might want to split a module in two, add/remove ports, rework the hierarchy; except it’s inefficient and painful to do that with Verilog/VHDL.

    As a matter of fact, we’ve developed a new C-like language for hardware design, and while refactoring was not a design goal, it turns out it’s much faster to do it with that language than with HDLs. Feel free to let us know what you think on our forum!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.