Agile methods such as Scrum are popular among software developers, but if you trace their history, you inventively discover that the core concepts of agile methods originally come from the Toyota Production System. Needless to say, building cars is a lot different kind of engineering than building software, but they have enough in common that agile techniques work for both of them. At Meld, our goal was to launch a line of products that are somewhere in between software and a car, so we wanted to see what agile could do for us. Along the way, we learned a lot about what tools are appropriate at what stages of hardware development, and how best to employ them–or at least how to employ them well enough to get as far as we did. That’s what this series of posts is all about.
I’m not, and never have been, a religious zealot when it comes to agile methodologies. Honestly, although I have used agile methods for years, nothing bores me to tears more quickly than listening to a nit-picking debate over the pros and cons of minor details of Scrum vs. Kanban. The main thing I want out of agile development is the ability to iterate quickly and deliver partial solutions along the way to a fully featured product. So while I don’t want to be anywhere near the waterfall end of the pool, as long as things are iterative and test-driven, I’m pretty happy.
Starting from zero, I wanted our Meld Knob and the embedded software that runs on it to start doing something useful as quickly as possible. And from there, I wanted to make sure we could iterate in two critical directions: first, to add features, and second to ensure that we could feasibly and cost-effectively manufacture version 1.0 of the product.
The process started in early 2014 and took right about a year to get to version 1.0 of two separate boards. That’s longer than I would have liked, but it’s not entirely unreasonable given that we were small and bootstrapping the entire time. If we had three hardware engineers instead of about half of one, we could have very likely gotten through the whole process in three to six months.
In the hopes of inspiring future hardware startups, and getting feedback from others who may have done things better than we did, we decided to blog about the experience.
We learned an awful lot over the course of the year. We have posted and will continue to post more low-level details over on the Meld Tech Blog. But here I want to go over the key things that worked well for us. They were:
Coupled hardware and software sprints
We started with a two-week sprint but then tightened up to a single week. Since we were a very small team, we didn’t bother digitizing our sprints. We literally used sticky notes on a white board,with different colors indicating different hardware and software components as you see here.
In every sprint we built both hardware and software. This doesn’t mean we had a fully fabricated new board rev once a week. That is neither necessary nor cost effective, especially early on with a small team. What did we do instead?
Get the most out of eval-boards
We couldn’t build a complete new board every week, and early on we didn’t even know for sure what parts we wanted in our final BOM (Bill of Materials) so we used eval boards. Eval boards put a microcontroller and a handful of buttons, LEDs and other parts on a single board and expose most or all of the I/O pins via headers. Here’s one of the early eval boards we used.
Transition to real SMT parts sooner rather than later
Once you get going with an eval board, you almost immediately want to add peripheral parts like sensors and controllers. If you want to use a breadboard, you need parts with 0.1″ through hole pin spacing. But a lot of modern parts come only in SMT (surface mount) versions. And certainly in your final design you want to be basically all SMT. We solved the problem by of doing early designs with SMTs using some clever SMT to breadboard adapters from a company called ProtoAdvantage. Here’s what one looks like, populated with one of the SMT chips we were testing.
Test hardware and software together
Unit testing is a standard part of agile software development. We think it should be a part of hardware development too. Unit tests that can run on a host computer should, to speed development, but all unit tests should eventually run on the embedded hardware itself. We developed, and subsequently open-sourced a unit testing framework for the Nordic chips we were using. It is called NrfUnit.
Invest in quick-turn boards as you approach a final design
Once your parts are selected, or even before you have 100% finalized them, start laying out boards in the form factor you want for your final product. We used EAGLE for this, but you may or may not prefer some of the alternatives that are out there. The key thing you are looking for here is validation that the collection of parts you have chosen will fit properly on a board of the right size and shape to go into your final packaging. It’s better to start this process sooner rather than later, and work closely with whoever on your team is doing Industrial Design and Mechanical Engineering. If you don’t have people doing those things, you probably should.
Here is one of our early quick-turn boards in a 3D printed housing. It did not have all the final components on board, but it had enough to embed in an early package design and test and use.
We ended up revving our boards once every four to six sprints and sending them out to a prototype fab to be assembled. We used Sunstone, Schippers, and Screaming Circuits at various times and had great experiences with all of them.
It is absolutely possible to do agile hardware development, and perhaps even more importantly, agile hardware/software co-development. It’s important not to be religious, but to take the best that methods like Scrum have to offer, and apply them in ways that make sense. Agile hardware doesn’t mean a new board every sprint, but it means demonstrable forward progress through the sequence of steps from part selection to interfacing to integration. In our world, we try to make sure that every sprint has a set of goals that move us forward along that path.
[Note: The extended collection of posts on which this is based, which go into more detail on agile hardware development can be found on the Meld Tech Blog.]