This blog post highlights a software company and technology that I view as potentially useful to organizations investing in agile development, agile new product development, and business agility over the next few years. Note that, in my opinion, this company and solution are not typically “top of the mind” when we talk about agile development today.
The Importance of Continuous Delivery to Agile Development
I have taken a hiatus from this series over the last two weeks, but I knew one thing that I wanted to tackle: product development that included hardware, or New Product Development (NPD) solutions. And I have to say that, in general, the situation is distressing.
It’s been more than ten years since the Agile Manifesto, and in that time there have certainly been vocal proponents of agile NPD. The lean movement, for one, keeps claiming that “lean” has incorporated the tenets of agile software development, that “lean” and “agile” are complementary, and that this is a methodology that is being applied to NPD in general.
Looking at their and other evidence, I am not at all convinced. There is little or no evidence that their proponents are intensively applying agile software development techniques and methodologies to actual hardware development, whether you’re talking about engineering a plane or designing and fabricating a chip. There is a persistent tendency in what I have seen in the agile/lean movement to treat just-in-time leanness and fast-design-change-from-user-feedback agility as equally important (or, treat lean as more important than agile), rather than carefully considering what it would mean to have super-lean NPD give way when agility demands (as, in agile software development, it often does) temporary use of extra resources plus Gantt charts that are not time-optimized. Finally, I cannot find clear evidence of forward thinking on how, if we are going to maintain that agile hardware development is not appropriate in many hardware-design cases, agile and non-agile will integrate effectively. It is clear from some of the comments I have seen that many hardware engineers are bewildered by the seeming Wild West of agile software development, and in no mood to face an overall schedule in which they depend on the changing specs and indefinite deadlines of the software side.
And yet, I was able to find one small but amazingly perceptive example of another kind of thinking about NPD. XtremeEDA Corporation, and in particular Neil Johnson there, is just what I’m talking about.
If you want to see an example, try submit2011.agilealliance.org/files/session_pdfs/applying%20agile%20to%20ic%20development.pdf. There it all is: How to turn ASIC development into agile; how to coordinate with agile software developers; how to use more customer feedback; and the message “to heck with minimal just-in-time resources and up with ‘one person owns a task.’” He even – be still, my heart – quotes Ken Schwaber, whom I knew, before his days as Mr. Scrum and as one of the original Manifesto signers, as the vendor of a superb rapid application development tool that basically “got” agile (alas, it was only for the AS/400).
Even I don’t want to overstate the relevance of agile development approaches to hardware NPD. There are still constraints, not the least of which is the fact that producing a hardware prototype or even a functioning sub-product prototype is in many cases a costly and time-consuming process that we cannot yet completely accomplish as swiftly as compile-load-go.
And yet, what Mr. Johnson makes clear is that, in the real world, agile hardware development and integrated, totally agile joint hardware/software NPD still do better than the traditional counterparts, in time, in money, and in customer satisfaction. And that’s just one product iteration. You tell me what rapid, incremental, customer-pleasing hardware improvements would mean for your bottom line.
Isn’t it time that not only IT but also the CAD and manufacturing side gave it some thought?
The Relevance of XtremeEDA to Agile NPD
I don’t want to misrepresent the imminence of agile NPD, so these next two sections will be short. Neil Johnson is one person in XtremeEDA, and clearly the firm doesn’t make a big point of his efforts, I am guessing in order not to spook its traditional customers for consulting and ASICs. I am sure that XtremeEDA does a fine job with these tasks, and that if you want to use them you need never run the risk (?????) of agile hardware development, or even hear about it, if you don’t want.
That said, I am also sure that if anybody does want to see how it’s really done, XtremeEDA would be very pleased to have someone like Neil show them, and any fees involved have got to be minimal considering the advantage to be gained. So what, bottom line, could XtremeEDA potentially offer if you go that route?
First, hands-on experience – as in the url to which I just sent you. Second, creative thinking about how to apply this experience and the resulting insights to a wide variety of (at least in the chip area) hardware development projects, fab and otherwise. Third, both experience and creative thinking in how to mesh embedded-software and hardware agile development. Fourth, consulting and support for your efforts. Above all, fifth, suggestions on scaling agile hardware and hardware/software NPD.
The point of this exercise in imagining how xTremeEDA could help you is to lead you to the next question: How will this information make my NPD – specifically, NPD that includes hardware, like a cell phone or a child’s toy – agile? And the answer, in case I haven’t said it sufficiently, is that agile is, more than anything else, a process and a culture. You process NPD that way, you think NPD that way. If you are really doing agile NPD right, NPD agility comes with the package. If you use information from someone like XtremeEDA to implement agile hardware development and integration between your agile software development and agile hardware development, your NPD will be agile.
Potential Uses of XtremeEDA-Type Agile NPD for IT and NPD
In this case, IT and NPD are two separate things, and often, in the case of hardware development, two separate organizations. On the IT side, if there is a separate NPD organization, this means evangelism. It may not work – but with someone who has walked the hardware walk at your side, like XtremeEDA, you may actually get listened to. Of course, if the NPD organization is folded under a joint hardware-plus-software IT organizatio, it’s more a matter of top-down commitment from the CIO (and, hopefully, the CEO), and then using someone like XtremeEDA to hand-hold and calm the rightful fears of experienced hardware engineers.
If we’re talking about an overall NPD organization to whom software development is both important and an annoying pest, on the other hand, you may want to consider initially leaving IT and/or agile software development organizations out of the conversation completely. That will avoid the usual antagonisms that surface between hardware and software teams, and it will also make the organization squarely face the fact that pure agile hardware development works – and there’s a hardware geek like someone at XtremeEDA to tell them so. Once the hardware-only implementation has shown the doubters, and worriers begin to turn into enthusiasts, you can let loose the software and hardware sides on each other, and they will automagically start practicing their getting-user-feedback skills on each other. An integrating process tool is great, but don’t forget that these folks may well do some of the integration on their own.
The Bottom Line for IT Buyers
I freely admit that an XtremeEDA approach to NPD may turn out to be of little value to most companies in the next 2-3 years. That, however, is not because it intrinsically has no value. Rather, it is because I am fully confident that most companies with significant hardware in their products will not figure out how to walk the walk before 2015. They will probably not be in a hurry, because they will rightly figure that most of their competitors will take the same attitude. Into the pool? You first. I live in hope; but I’ve seen too much.
However, when – not if – agile NPD really begins to take over, I urge you to consider carefully the further implications of truly agile NPD. My survey results, as well as experiences when software is the only product of the company, suggest that NPD is the absolute biggest bang for the buck for the business in implementing business agility, leading to permanent, 10-35% improvements in revenues, ROI, and customer satisfaction (not to mention quality), and similar reductions in costs, compared to what they would have been had you not implemented agile. Today, in many companies, agile software development is really about competitive advantage. In NPD, it is about the top and bottom lines.
Moreover, because NPD is always at the core of company success, agile NPD leaks into other areas of the company, far more than agile software development. Marketers cannot help being more agile. CEO strategies, given new power to change product directions fast, become more nimble, and the CEO begins to think more in terms of strategy change than enforcing execution. Even finance – well, maybe someday.
If, however, you really are a visionary, and would like to do it now, then I beg you not to talk about it publicly. What? XtremeEDA? Oh, they’re just here to help us out with some ASICs. Nothing to see here. These aren’t the droids you’re looking for. And your company’s success? Oh, just lucky, I guess. Fun, isn’t it?
Yes, it is. And XtremeEDA-type agile product development just happens to be quite profitable, too. Just a coincidence, I’m sure. Yeah, right.