Fair to say that what we’ve posted on AgileSoC.com to date is decidedly pro-agile. Bryan, myself and the guest bloggers we’ve had thus far believe in agile hardware development so we haven’t spend much time talking about why agile hardware wouldn’t work. No surprise there. But when you’re getting a steady diet of opinions from one side of an argument, it can be easy to forget that there can be some very practical arguments on the flip side to the coin. Today – after a little cajoling from Bryan over the past year – Mike Thompson from Huawei in Ottawa brings a little balance to AgileSoC.com by examining the flip side of the coin. Continue reading
By: Rolf V. Ostergaard
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.
By: Rolf V. Ostergaard
Far too often technology projects leads to a lot of fun work with very low productivity – and less useful results. A demo-driven scrum-like approach is a good way to fix that.
A technology project is…
Let me start by describing what I term a “technology project”. Most development is directly focused on building a product. Often with a lot of focus on cost price, schedule, manufacturability etc. Risk is avoided and solutions that fit the cost and schedule with low risk are preferred.
A technology project is intended to take more risk, do something new, and do this in a setting where the development of new technology is the goal. This is done outside of product development projects, to make the risk acceptable. Done right this actually reduces the risk of one or more following projects, where the technology can be used in new products.
Most engineers love technology projects. For the same reasons, managers often use them to create variation in the work for the engineers. It’s like a treat for engineers. Sounds a bit nerdy, I know. But it works.
Show, don’t tell
The problem with many technology projects is that they can feel less important than “real” product development. But the contrary is true, they are more important. Without technology projects, the innovation suffers and new revolutionary products become to risky to do.
Our solution to this is a scum-like approach with demos. Each 2-3-4 week iteration, should demonstrate something. Preferably physical and preferably progress. The mantra here is “show, don’t tell”.
Sometimes it requires a lot of creativity to “show” something that can’t be build as a physical object yet. But eventually it gets there and the demos become more and more interesting.
At other times the progress is negative – we are in a dead end and need to dig ourselves out again. That’s good too, because the cost of doing this in a technology project is much lower than in a tight product development project. That is risk reduction at work.
We would prefer to always hold the demo, regardless of the results. “Negative progress” requires more understanding from all stakeholders – and a demo is really a good way of getting everybody to understand.
If you read about Scrum and demos, you will hear a lot about how important it is to demo the real working product in a realistic user setting. I think this is besides the point here. For projects involving hardware, software, FPGA/ASIC, mechanical and other aspects, this may be completely unrealistic. Making a demo – any demo – is however always possible. And this is much better than not trying. More about making a demo, any demo will be discussed in a subsequent entry.
Part of the purpose of a demo is collecting feedback. Both from other engineers on ideas for improvement, potential risks, things to try, test conditions to consider and from the other stakeholders on where the value is, what would improve the solution etc.
Most technology projects tend to have one or two applications in future products as their primary targets. Holding regular demos is a also a really good way to get other application ideas identified as well. When a broader group get to see what can be done with this technology, feedback in the form of “Could this be used for…?” is inevitable. This is a good catalyst for further innovation.
Is this Agile?
This method of making progress very visible and forcing easy to understand demos throughout a project helps in many ways. Does it make the project more agile? I believe so in many ways, but that may not be the primary reason for doing it. The more important reasons is to keep focus on the projects actual results and to make the project more visible.
A very nice side benefit comes from the way motivation works. If you are doing something that matters to others (and hell yes, we want to see a demo – anytime!), you are immediately much more motivated. Motivation improves productivity dramatically.
All in all this demo-driven approach to technology projects achieves three good things:
- Productivity is boosted through the motivation to do good demos
- Project visibility is increased, which also helps spread the knowledge
- Innovation is regularly inspired by the technology demos
Hopefully this served as a bit of inspiration on how to improve outcome, productivity and motivation in these traditionally difficult technology projects.
Q: How do you make technology projects visible and productive in your organisation?
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 specialised 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.