Hardware Scrum Sprint Demo Examples

tirs aug 30, 2011 (Axcon)

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.

This post previously appeared on the AgileSOC blog by @nosnhojn – so please go there to join the discussions.

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.
  • Live demo of actual FPGA code on an eval board doing loop-back transmit/receive testing.
  • The eval board hooked up with a very long, but much thicker cable. Easier to buy and work with, and the longer cable had about the same loss.
  • Next iteration showed the system implemented on two different FPGA devices on two eval boards. This demonstrated how both low-end and high-end FPGA’s could be used to implement the two ends.

This became known as the “640 mbit/s though a 2m hair” project. Hair referring to the thickness of the individual conductors in the very thin coax. We blogged about that way back in 2007: http://www.axcon.dk/blog/teknologi/640-mbits-gennem-et-2-meter-langt-har.htm (danish).

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.

Q: What are you doing to demonstrate progress in your projects?

PS: A good post specifically on software development Scrum Demos is: http://martinaharris.com/2010/01/dancing-to-the-tune-of-the-scrum-demo/

As can be seen from the above, I do not agree on all of this in the context of hardware development, but many points are well made.

PPS: If you need a long, but great, motivation for Scrum. This Youtube video from Google TechTalks is recommended: http://www.youtube.com/watch?v=IyNPeTn8fpo

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

Kommentarer (2)

  1. Catherine Louis added on 30. august 2011

    Great post Rolf. It’s exactly your “what questions are we trying to answer” which the motivating force behind each iteration.

  2. Henrik Østergaard Madsen added on 30. august 2011

    Hi Rolf,

    You are absolutely right about the bending of the rules to be able to run agile hardware development. Actually, I think (and have successfully tried) to bend them further and include two more reasons why the demo should be held:
    * To precisely inform the customers and other stakeholders of the current progress (which in our case is not necessarily very ‘releasable’), and
    * To get a common understanding of the quality and possibly difficulty the project is experiencing – adjustment of expectations.

    This also makes it possible to demonstrate somewhat subtle achievements where the difficulty of the scrummaster sometimes is to persuade the team that this demo is actually worth holding.

Hvad mener du?