We’ve had our first brave sole step up and offer his opinion based on data from our project planning survey! Our guest contributor is Gaurav Jalan, a design verification engineer with services firm SmartPlay in Bangalore. Gaurav, who runs his own blog focused on hardware verification, offers his opinion on variance in project plans.
Take it away Gaurav! Continue reading
We’re happy to have another guest contributer to the AgileSoC blog. This one is special because it’s a case study on an exercise I’ve written about before and presented as part of my talk at Agile2011. I’ve called it The Steel Thread Challenge to reach the software crowd and Operation Basic Sanity to reach the hardware crowd. These are 2 different names for achieving on goal: finding ways to help hardware developers think in terms of early functionality and tangible milestones.
Catherine Louis, a long time agile coach and trainer, has tried the exercise on more than one occasion with SoC development teams. I’m happy to report she’s had some success with it and has agreed to take us though what she’s done (Note: I like the way she uses the term “tangible outcome”).
With that, I’ll turn it over to Catherine. Thanks again!
I’ve had some great success taking Neil’s Basic Sanity presentation (Agile2011, available here) as a retrospective exercise for hardware teams interested in learning about adaptive hardware development. (a.k.a “Agile”.)
If others have not tried it, it is time you give it a whirl.
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.