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!
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!