Guest Blog: What’s All This Hardware Scrum Sprint Demo Stuff, Anyhow?

If you read about Scrum from the software world, you learn how important it is to make the sprint demo as close as possible to the real product in a realistic user scenario. Some obsess over it to a point, where this becomes a problem for adapting Scrum to hardware development. I want to change that – a demo need NOT be the working product, in order to be valuable and useful.

In device development, where products often combine custom hardware, test systems, embedded software, FPGA/ASIC code etc. etc., making a demo after the first 3 week sprint that looks anything like the real product seems dead impossible. I agree, but that does not mean you shouldn’t try or can’t benefit from Scrum.

You can easily get many – if not all – of the benefits of Scrum simply by adopting a broader definition of what a good sprint demo is. I know this is very difficult envision at first, but take a look at what we considered good demos along the way in some example projects.

Examples

Two real-life communication examples from some of the technology projects (more about how to make Technology Projects more productive through demos) we have done may be good to illustrate what can be demonstrated. The projects are from opposite ends of the spectrum in many ways: short/long, easy/hard and tight/loose schedule etc.

Project 1: More data through a long and bad cable

Customer: “How can we transmit data though this power cable? Can we do better than the 10 kbit/s we did in a simple test?”

Us: “Don’t know, but let’s find out”.

This was a very long and heavy cable, that required a fork lift to move around. So the first demonstrations were about creating an easier testbed. This is examples of what was actually demonstrated:

On-site measurements with a network analyzer to characterize the cable. “Hey, not much progress to show there!”. You are right, but getting out there and actually doing the physical measurements early on is very much better than not doing it. Much valuable knowledge is gained this way, and all become aware of the real issues involved like how to connect to this cable.

Simulation results from trying different modulation schemes though the cable. “Hey, not a very physical demo”. You are right, but better show the progress early and for all. We are breaking new ground, so the more engineers that can easily comprehend what you do, the more qualified suggestions and tips will you get. That’s very useful. Make the difficult tasks something all can contribute to by showing the challenge and results.

Breadboard (in a box for shielding) of a cable loss simulator. Not really good in terms of progress on the main task, but a very important step to get the testing time down by moving it onto the desk and into the lab.

More breadboards for the coupling to/from the cable to isolate power and signal sharing the same cable.

DSP algorithms implemented on an eval board doing loop-back with no loss, with the cable loss simulator and with the power/data isolation as well. This required a number of iterations and multiple demos to get good enough.

Custom board design as artwork. Just showing the PCB artwork on paper is much better than a line in a status report. It’s so much easier to understand and appreciate, when you actually see it.

Mounted custom board.

Working custom board with progressively more features tested. At that point many of the earlier demos could be moved onto the custom board, which eventually became the physical deliverable demonstrator.

The final demonstrator delivered consisted of two custom boards running data through the real cable in a realistic scenario – still in not in actual use and still not with the actual applications sending and receiving the data. Both of these “shortcuts” were deemed okay because this was a technology project.

Project 2: Lots of data though thin cable

Customer: “How can we cheaply move lots of data fast through this very thin coaxial cable so it can go though a hinge in our next product?”

Us: “Don’t know, but lets start working at it”.

And so we did for 6 weeks, with a series of demonstrations along the way to show progress and to keep improving. Examples of demonstrations:

Simulation results to show how the electrical signals would be attenuated through the cable (lots of loss!). “Hey, that’s not a very physical demo!”. You are right, but it’s actual results coming out of some real work trying to answer a key question. And to show simulated waveforms is much better than talking about 17dB loss at this and that frequency in a status report.

Are these demos legal?

Hopefully this served as a bit of inspiration on what to demonstrate at the end of each iteration. This is maybe one of the most difficult issues in adapting agile techniques like Scrum to the world of integrated hardware, software, FPGA, mechanical design.

As you can see we are “bending the rules” of what a demo is in the traditional software development scrum world. But we are holding a demo at the end of each sprint anyways. And we do this for the same good reasons:

Demos builds confidence in the team, the product and the path

The team becomes more focused on delivery

Early feedback and communication is dramatically increased

I believe we can easily redefine the “rules” for a scrum demo like this and still get most – if not all – of the benefits. And a good demo will beat the old status report by many lengths, anytime.

PPPS: Yes, the blog title is in honor of one of the worlds greatest analog gurus, Bob Pease, who died recently. Long live his archives: http://www.national.com/rap/

Disclaimer: A few deviations from the 100% pure truth is inserted in the project descriptions on purpose to protect the customers and other innocent.

Rolf V. Ostergaard is a M.Sc.EE from Denmark, who got his entrepreneurial inspiration by working in Silicon Valley back in the dot-com days. He co-founded the consulting business Axcon in 2004 and grew it to 20+ people focused on improving development of embedded systems – hardware, software, FPGA – the guts of smart devices. Rolf is a specialist in signal integrity and enjoys doing training and consulting to fix SI problems before they occur. Find him blogging on www.axcon.dk/blog and as @rolfostergaard on Twitter.