The 2 Biggest Barriers to Agile Hardware

I think we have two fairly critical barriers to overcome before agile hardware gets any serious traction from semiconductor teams.

Agile Hardware Teams are Large

First is the idea that it’s 2028 and we already have the experience it took almost two decades for agile software developers to accumulate. That’s not going to work.

Consider where agile software development is today. All the technical practices have an established track record. Likewise for development frameworks like scrum and kanban. Infrastructure and tools have been built up. Minds have been changed. Not that agile has been a walk in the park or that practices have been perfected, but there’s been a lot of success.

The problem of the day for agile software has become finding solutions for agile at scale; there’s how to synchronize large development teams, there’s also making a commitment as an organization to transform everything, from contract negotiation and sales to marketing to large development teams, deployment and maintenance. Neither is the situation for which agile was originally intended. But large teams is what agile software has become and software teams are currently building (and sharing) this part of their history.

It feels like hardware developers have been sucked into identifying with today’s agile and it’s large scale problems:

SoC teams are large. We want to know how agile applies to a team of 200+ developers. That’s where our problems are. Tell me how that would work.

This is the kind of question we ask to close the gap between today’s hardware and today’s agile software. But that gap is immense. Aside from absolutely exceptional 1-in-a-million circumstances, I see starting with a 200+ person agile hardware teams as a failure waiting to happen. I doubt I’m the only one with that opinion, so if large scale agile is what we’ve got in mind, that’s a barrier. It doesn’t take much analysis to turn that view of agile hardware into a non-starter.

To break through the impossibility of agile hardware, it’s critical we see ourselves as being year 2000 agile developers adopting year 2000 agile software practices. That’s when agile was developer lead and the focus was on small teams. We crack the first barrier to agile development by nailing “small team” agile (to be clear, “small team” agile to me are subsystem, IP, ASIC, FPGA and SoC teams with 10 or fewer developers.). From there we can grow to larger teams. If all goes well, by 2028 we’ll be transforming entire organizations.

Hardware Development is Purely Technical

Beyond the first barrier is the idea that hardware development is a purely technical exercise. But a purely technical view of hardware development ignores the fact that hardware developers are… people!

Surprise!

People come with baggage; all kinds of baggage. We have strengths and weaknesses, good days and bad. To overcome the second barrier is to recognize the non-technical aspects of hardware development (aka: people) and the role agile practices can play in supporting and strengthening these aspects (repeat: people).

As a litmus test to show we’ve overcome the idea that hardware development is purely technical, I’ll point out two agile practices in particular. One is that we’re pair programming. Pairing is a sign we’re building a long term productivity paradigm to replace our industry standard – yet short sighted – efficiency paradigm. Another is that we’ve ditched cubicles for shared workspaces. That’s a sign we’ve embraced the idea that teams can be stronger than a bunch of individuals, that my privacy is less important than the team’s success and that we’re optimizing for the whole.

Not that we need to start with pairing and shared workspaces, but I do think we should consider those to be necessary steps to becoming agile teams.


Boiling it down, I see the perceived scale of agile and our own technical biases as being the greatest barriers to agile hardware development. I’m sure others will pop-up after we clear those… but by that time we’ll be well on our way!

-neil

4 thoughts on “The 2 Biggest Barriers to Agile Hardware

  1. I’m not really sure what to think w.r.t. shared workspaces. The biggest complaint I hear isn’t about privacy, but about noise leading to difficulty in concentration.

    1. so pairing and shared workspace is me speaking from other people’s experience. I’ve done some pairing but never done the shared workspace. I’ll admit that I’m a bit skeptical as well, on both. but for all the people that describe them as key, I’d sure like to give them a shot.

      -neil

  2. Hi Neil!

    I think that Agile is a state of mind first and foremost and, implicitly, the most important barrier in adopting agile methodologies are the people themselves. Of course a shared work space and pair-programming can help, but only to the extent people involved are open to these. To provide engineers with the recommended agile work space setup, software, tools, training programs etc. is the easy part. The hard part is to grow new, agile, habits or otherwise they will live in the “agile fantasy world”…..for a while.

    The real question is: how can people grow to this state-of-mind? Of course there is no universal answer to this question, but still every manager should ask himself this question and try to find the answer on a case-by-case basis.
    A manager that haven’t achieved this state of mind should try to achieve it before leading others on the agile path.

    – stefan

    1. stefan, I agree on the state-of-mind point. and for me, pairing and shared workspace wouldn’t necessarily be a way to develop the mindset. Instead, they’d be a sign that a team is already on its way to developing the mindset. they are radical enough (relative to where we are today) that I don’t think they can be imposed. so seeing a team consent to using them, to me, is a sign that they’ve moved to a different level.

      thanks for the comment!

      -neil

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.