Hardware in 30 Days or Less?

In the past few months I've been working with a company whose products are most hardware, circuit boards, and firmware. There is some software, but it's "less than 10% of the cost and time required to release new product." So the purpose in bringing me in was speed up the hardware side of things, and just leave the software side alone. 

Here are some key lessons from this engagement:

  • You can indeed make meaningful and valuable changes to hardware in 1-month Sprints. Use of rapid prototyping, 3D printing, and micro-onsite-manufacturing-labs are worth the cost of investment. Design by contract and componentization is key. The ability to get from idea to done in 1-month allows for better products, quality, and innovation. You can still send your final "box it up and send it to the store" bill of materials to an offshore manufacturing facility for economies of scale. 
  • For those technologies and teams that simply cannot get anything done in "less than 6 months," and yes that's a direct quote and I believe them, it still pays to get together every few weeks to inspect and adapt. This feels like micromanagement to those involved, as they are not used to having to show work more than every few months. This is an important realization to make early and coach through. 
  • For products that require both hardware and software, you are automatically in a scaled-Scrum situation. The company was surprised how little these teams communicate on a typical project. So using the Nexus framework makes alot of sense here. Even if one team isn't using Scrum, the Nexus Framework and communication mechanisms built into it are helpful. 
  • You need to become a software company. The pace of tooling, techniques, and technologies in software is advancing and changing at a pace exponentially faster than hardware. Even given all the modern hardware fabrication techniques this company has at their disposal, it's slooooooow compared to software. It didn't take long after shortening cycles for the company to realize a shift in strategy is needed. If we built multi-use-generalized-hardware platforms, we could release new products via writing software features only. 

Hardware and Scrum has always been something we talk about, and I'm starting to see the challenges and opportunities in this space. 

Why don't we do this all the time?

One of my favorite moments in teaching is asking the question: "why don't we work like this all the time?"

In a training environment, teams are so surprised at the amount of done, working product they can produce during the few short days of class. Getting teams working closely together, sitting around a table, under the pressure of a strict timebox, and working on a single interesting piece of work without interruption. Turns out people not only perform better and are more productive in this environment, they actually like it, find it enjoyable, and are more engaged.  

So I ask you: why aren't we working like this all the time?