• How We Do Agile Hardware Development at Meld



    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.

    Key Learnings

    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.

    Sprint Board

    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.

    Eval Board

    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.

    SMT Adapter

    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.

    Sprint Board

    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.]
  • Here are the under-hyped areas of IoT (based on hundreds of hours of hacking)

    Over the last couple of years I’ve done a ton of home automation hacking, as well as a lot of reading and tracking of emerging products in the IoT and home automation space. In the process, I’ve been able to identify some under-hyped areas of opportunity in the space.


    There are many scenarios where it’s useful to know if a person is home or not. That information can be used to make sure music is off when you’re away, turn lights off — or even to make a house appear to be occupied if people have been away for a long time. I haven’t found anyone really talking about this, but now that I’ve implemented it for myself, I know how useful it is.

    To my knowledge, no product today makes it easy to sense presence passively and make that information available to implement useful automation scenarios.

    iBeacons are an option, but they tie to the phone, which isn’t always useful if your phone isn’t with you always. And iBeaons are immature. I’ve testing many of the leading brands including Estimote, Gimbal and a handful of Chinese iBeacons; battery life is a disaster and configuration is arduous. There’s no management layer, so building a presence app is non-trivial effort.
    Nest (and it’s API) includes home and away detection, but I’m not sure how accurate or realtime it is.

    Voice Control

    The smartphone is the defacto user interface for IoT, and that’s usually a good thing. But phones get left in bags or set on counters to charge. It would be incredibly useful to talk to your house (“set the lights to movie mode”) no matter where you happen to be standing or sitting.
    Amazon Echo has done the best job so far of creating a passive voice recognition ability that works in noisy environments and from across the room.
    But at least for now, it’s a completely closed system…unless you want to hijack your shopping list and use that to trigger commands.

    Scripting / APIs 

    I haven’t found a user-friendly system that helps tie together various IoT systems into something cohesive.

    Revolv may have been the great hope for his, but they didn’t offer an API and they’ve been acquired by Nest and don’t appear to be on the market any more.

    I ended up writing my own server running on a Mac Mini that connects directly to various systems (lighting controllers, security panel, Sonos, Nest, Spotify) to monitor and run scripts and to accept commands from my own iPhone app.

    For example, when I open the door to my home gym in the morning, my Spotify workout playlist automatically starts playing on the Sonos in that room.

    When I press “movie mode” on my app, music (if playing) stops playing and lights reconfigure to reduce outside glare and dim downstairs.
    If it has been hot during the day and windows were left open, but the weather report predicts temperatures below 65 during the night, a push notification reminds me to close the windows.
    When the house is empty, the alarm system is automatically armed. I don’t have to think about it. SMS notifications? Cameras? Check.
    When I open the front door late at night, the entry lights inside the house turn on (but dimly), and then turn off again after a bit. Avoid eye strain and reduce cognitive load. Less stress is a big thing.
    All of these scenarios are incredibly useful and were impossible to achieve without writing my own service, hacking into devices that don’t have official APIs and (in some cases) issuing telnet commands. The hardware is there and the software algorithms are simple. Getting things to talk to each other? That’s the hard part.
    Somebody ought to wrap all this stuff into a visual scripting tool. And support IFTTT. Of course none of this will be possible unless vendors decide that opening up is good for business. Currently it seems that most (even Kickstarter) projects forgo open APIs. Perhaps HomeKit will usher in more interop.
    No, most consumers will not directly use APIs or scripting interfaces. However if more manufacturers supported open interfaces and offered APIs, we’ll see useful innovation that can be shared and purchased. Things are often  better when they work together and the devices that play nicely will get purchased more often.

    Too Much Hype? Not Enough Vision?

    Overall, I think IoT and home automation is over-hyped, and I’ve come to the conclusion that many of the industry’s so-called leaders lack vision. The prime example of this is Nest and their “Works with Nest” program.
    Months after their $3.2B acquisition by Google, and presumably armed with a major PR push, months of significant planning, big name strategic partners and top-notch video production, the best they could do to outline the vision of the future for home automation was:
    #1:  Your Jawbone UP knows you woke up, so your Nest thermostat can turn the heat up. An savings of about 15 seconds from the tim when you will walk by the thermostat and it detects you walking by. And in the 15 seconds, the heater will have affect the ambient temperature in your room by how much?
    #2: Thermostat + Washing Machine = ? Spoiler alert! —> In the video, the President of Whirlpool asks “why would we ever bring the thermostat and the washer together? that’s a good question”. Then he talks for a bit and never really answers the question.
    #3: If fire detector goes off, lights flash red so your neighbors can see there is trouble. It helps save lives. Um, okay.
    #4: The president of R&D for Mercedes outlines their vision for interfacing the car (using time of arrival information) to tell the Nest to turn on so your house can be warm when you get home. This can be implemented trivially in the Nest app. What does the car have to do with it? And who cares anyway. Nest learns when you usually arrive home. This is an optimization for the unusual case of a different time of arriving home.
    These are not game-changers. They aren’t revolutionary.  But they are the top scenarios outlined by the apparent leader in the space. Ouch.
    Given hardware ship and replacement cycles, the time it takes to evolve and adopt standards and, frankly, the lack of vision from industry, I think it will take quite a bit of time before useful mass-market IoT and home automation really takes off.
    In the meantime though…happy hacking.