How does scrum help hardware design

Once again we visited a group to explain what we are trying to do with Scrum IT. This time in Holland .

I talked with one company and explained that, even though they are analogue hardware designers, their hardware will be driven by software. To supply hardware without regard to how it will be used is missing a trick. In this specific case we agreed that the hardware had some software control.

The designers had created a board with their chip on it, and considered it research. However they didn’t want to supply it to customers, just show it to them. The aim was to engage the customer in consulting to create a specific hardware design for them.

I’ll come back to this, after I explain the other discussion.

I was asked specifically how Scrum can be used with hardware. This is simple, Scrum is a project control methodology. It’s become popular in Software. In it’s earlier guise as Sashimi, it was used for general product development. Here is a PDF of the original paper .

Wikipedia also explains the history of Scrum as a general project control methodology .

If you put a team together that includes the hardware designers and the software developers each customer feature benefits from at least two viewpoints. Put a web designer, graphic artist, technical author in the team and the user documentation comes out right, too.

Most product features cross the boundary between hardware and software, even when the software is purely for diagnostic or maintenance purposes. That boundary can be discussed by the hardware and software engineers who have a common aim. That common aim is to deliver the best return on investment to the customer. The customer has been in the sprint planning meeting and has agreed what the team will deliver at the end of the sprint.

If for example some hardware can be made cheaper by removing a FIFO and doing the buffering in software it is the engineers who can decide this as they are implementing the feature. If the reverse is true and performance can be improved by using the FIFO, again it’s the engineers who can decide. They have listened to the customer and they know what the customer is prepared to pay for; cost or performance.

So, let’s get back to the first company. The one that didn’t want to get involved in software. What they could do is supply an early evaluation system to as many customers as possible, at cost price. They want to get as many customers as possible, or rather want as many happy customers as possible. So they should give prospective customers the means to think about the research project without having to engage fully with the designers. To do that three short scrum sprints could be done, with the hardware and software engineers. Like this.

three scrum sprints

What are these Ss? If you have looked at the scrum methodology you’ll see there are two interlocking cycles. There is a diagram at the main scrum website and at the wikipedia site referenced above. ScrumIT even has it’s own PDF version you can download and print out – SCRUMPoster.pdf . So the Ss represent a single sprint to develop working functionality.

The aim is to supply an early evaluator to customers. The chip designers supply a board and some software that would run on a PC. The evaluation kit has cost very little to produce; the board layout and possibly six weeks of software development. The boards are supplied to customers at cost. Invariably these customers want it to do other things; perhaps they want it to be integrated with their own software or hardware. They could do another sprint to add the functionality.

If three customers each carry out an increment on the basic demonstration, there are now three variants of the evaluator. All of them work. Scrum delivers working features, not demo or dummy features.

three sprints and three customer sprints

Now the designer has access to extra functionality they could wrap up into the product and make it more attractive. They could do one final increment of the software. It would probably satisfy most of the customers who wished to evaluate the hardware.

From demonstration to dev kit, refining the hardware and software at the same time and engaging with three customers. All done in possibly as little as two months.

Scrum is hyperproductive. It also works with multidisciplinary teams.


Commenting is closed for this article.