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.
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.
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.]]>
I got asked that a couple of times last week . So this is an answer that I can point to in future.
Let’s get some ground rules out of the way. Some definitions.
Design is solving problems in the defined solution domain. Here’s a list of domains:
Architecture opens up the domain to areas that your design doesn’t go. For example regulatory, environmental and ethical considerations. You don’t design in those domains, you consider them. They are part of the overall architectural vision.
So, bearing in mind that I’m referencing other writers here, they may use the terms design and architecture in different ways from me.
The Scrum world talks about ‘horizon’ when it looks at features. If something is over the horizon then you don’t need to spend too much time on it. The requirement goes on the backlog and will be discussed by the team when it gets closer.
That worries people. Does that mean the design is short sighted?
Perhaps it does, but who is to say that a design that is ‘grown’ as features are implemented rather than ‘planned’ by months of theoretical work is less coherent, or less appropriate?
The important point about scrum is that it doesn’t concern itself with how something is implemented; that’s up to the team.
Scrum is about keeping track of any project so carefully, with such an eagle eye, that any delay, any backlog, gets the immediate attention it deserves. In a smoothly running project, the first delay is the most important.
Let’s get back to design. This is more an agile development issue, however it is related to controlling a project.
It’s important to allay people’s fears that they are getting a ‘less good’ product if they don’t take great care in the initial design of their product; if they leave the team to ‘Just F***ing Do It’ (JFDI).
The article I always cite is by Martin Fowler, chief scientist at Thoughtworks . It’s called ‘Is Design Dead?’ and the basic premise is that design can be incremental, if sufficient tests cover all the parts that may change when a new feature is added.
That means test driven development goes hand in hand with incremental design. You cannot use incremental design as an excuse for less work. You take the hit on having tests for every function in your design. And more.
Today I found another reference; it’s a video at the server side . It is an hour long and haven’t watched it yet, when I have, I may update this posting.]]>