Guest Blog: I Tried It (Operation Basic Sanity) And I Liked It!

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.

Continue reading

Posted in guest blog | Tagged | Leave a comment

November is TDD Month On AgileSoC.com

It’s the biggest thing we’ve done on AgileSoc.com to date. We’ve been planning it for a while. Finally it’s going to happen (in about a month from now)!

November is TDD month on AgileSoC.com

Starting November 1st, we’ll be taking a closer look at how test-driven development fits into hardware development. We’ll have an overview of TDD, give our opinions with respect to how it fits in to the development/verification paradigm most of us follow now and hopefully have a few examples and expert opinions. It’s 1 full month dedicated to TDD!

All this and more rolls out through the month of November so be sure to join the discussion!

-neil

Posted in TDD | Tagged | 1 Comment

Hey Buddy, Can You Spare a Keyboard

Whenever I describe the agile practice of pair programming I usually get the same general reaction,which is something like “I don’t think I’d like to do that”. My usual attempt to convince someone that it could be an interesting tool to try is to suggest that verification team could do it for the complicated sections of code, or to have the designer and verification pair program to develop the drivers. While good reasons, these were never enough. This posting will be another attempt on my part to show the value of pair programming, and to provide some suggestions on where programming could be effective for you, and some reasons on why pair programming may not be effective.

Continue reading

Posted in Agile Development, AgileSoC, Pair Programming | Tagged | 3 Comments

Sir! Hands On Your Head And Step Away From The RTL!

A handy bit of guidance that I’ve gleaned from books on lean product development comes via the recognition that unfinished work sitting in someone’s in queue, which in lean manufacturing lingo is called inventory, is waste in your development process. Lean software practitioners take things a step further to describe untested and/or unreleased code sitting on a file server as inventory. I reckon doing the same can benefit us in hardware development.

It makes sense to me that built up inventory can be responsible for poor productivity or quality. Why? Think about it… do you do a better job when the amount of work in your queue is manageable or overwhelming? Do you work better when someone shows up at your cube with 10 feature requests or 1? Do you work better under the weight of 25 outstanding bug reports or no bug reports?

I’ll take manageable over overwhelming any day so I can see minimizing the amount of untested and/or unreleased code… I mean inventory… in your development process over time is a good thing. Minimize inventory and you’re minimizing waste. Minimize waste and you’re maximizing productivity and quality.

How about an example that applies to hardware development.

Continue reading

Posted in Agile Development | Tagged , , , | 6 Comments

Dear Agile Hardware Skeptic

This post is a little different than what I’ve been doing here so far because it’s directed at only 1 person. This person is new to agile. We have talked about it a few different times and last time we talked she mentioned:

“most of what you have on AgileSoC.com seems to assume you already know about agile… I wish you had some stuff for beginners.”

Point taken. Here’s a post just for you… and any other beginners that want to stick around.

Continue reading

Posted in Agile Development | Tagged | Leave a comment

8 Ways To Avoid Ignorance Based Exploratory Testing

Exploratory testing is a term I heard several times at Agile2011 in Salt Lake City a couple weeks ago. As I heard people talking about it, exploratory testing seemed to be something that verification engineers should be familiar with. Admittedly, it was new to me so for anyone else new to exploratory testing, here’s a description from good old wikipedia:

Exploratory testing seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases. The quality of the testing is dependent on the tester’s skill of inventing test cases and finding defects. The more the tester knows about the product and different test methods, the better the testing will be.

From that definition and other things I’ve read since Agile2011, it seems that exploratory testing is more easily pondered relative to it’s antithesis: scripted testing. In scripting testing all the thought is put in upfront; a tester would do all their research first, build the test plan and then they or someone else would execute the test plan. With exploratory testing, the tester assumes its impossible to deduce everything up front and that the goals of the testing will change over time. He/she starts with a more basic plan and then thinks their way through the test process, learning and shaping the test plan as they go along.

Continue reading

Posted in Functional Verification | 2 Comments

Guest Blog: What’s All This Hardware Scrum Sprint Demo Stuff, Anyhow?

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.

Continue reading

Posted in guest blog | Tagged | Leave a comment

Agile2011 Final Report

Agile2011 was a great conference. No question. Broad coverage of a bunch of great topics, high quality speakers and great organization made it probably the most enjoyable conference I’ve ever been too. Regardless of what you’re working on – hardware, software, marketing, sales, etc – and irrespective of what role you play in your organization -developer, tester, manager, executive, HR, whatever – and regardless of the type of processes and practices you follow, Agile2011 was a place where anyone could take away ideas that they can take back to work monday morning and begin applying immediately.

If you haven’t read through my daily reports yet, I wrote a daily round-up for each of monday to thursday. I sat in on a bit of the first keynote friday morning but had to leave early to get the airport (so no friday report unfortunately). You can go back to the Agile2011 page for pointers to each days report. I’ll finish off here with my general thoughts of the week. Continue reading

Posted in Agile2011 | 1 Comment

Agile2011 Round-up: Day 4

The Neil Johnson Agile2011 Conference Gold Star Award For Outstanding Accidental Contribution To The Field Of Hardware Verification

The Neil Johnson Agile2011 Conference Gold Star Award for Outstanding Accidental Contribution To The Field Of Hardware Verification is a mildly prestigious, little known fringe award given out to any person that spends more than an hour explaining software test practices to a poorly informed hardware verification engineer. The non-cash award this year goes to Elisabeth Hendrickson (@testobsessed). It’s an hour she’ll never get back but it was a big help for me. With a better idea of how software testing has evolved the last few years, it’s clear some similar evolution is in the cards for us, too.

Silo Busing (9:00)

A good start to the day came from Tom Perry and his talk about silo busting. I understand silos to be the confining spaces that restrict teamwork and collaboration between functional experts and across product teams and business units. Tom had some good ideas for… well… busting these silos to help bring developers together to form a more cohesive development environment. Continue reading

Posted in Agile2011 | Leave a comment

Agile2011 Round-up: Day 3

Exploratory Testing In An Agile Context (9:00)

This talk was given by Elisabeth Hendrickson. Elisabeth’s twitter handle is @testobsessed and I’d say that suites her entirely. She is obsessed with testing. That was pretty obvious.

This was more a workshop than a talk so it was very interactive again. The idea here was to practice thinking about how to uncover tests suited to a given design by playing a game called scrabble flash. It worked well. As small groups, we were able to identify a few interesting test conditions just by trying different things with the game. This was another exercise where I’ve seen that a big part of software testing is about creating opportunities that fuel curiosity and creativity in the mind of the tester. I’m starting to think that we’re not quite curious enough in hardware testing.

fwiw… if you’re looking for a scrabble flash partner, I’d go with Jon Kern. He’s a pro.

Applying Agile In Hardware Development… We’re Not That Different After All (11:00)

My turn… finally! We had about 20-25 people in the room today for my talk. Just a good number of people for the size of the room. As you can tell by the third slide in my presentation, I feel I’m definitely playing the role of outsider here at Agile2011. But that passed as soon as people starting asking questions. I got some very good questions regarding where agile is most applicable and how we can get software developers more involved. The discussions afterward were very encouraging. Thanks to everyone that attended. I felt uncertain walking in and encouraged walking out. It was a great experience and I sincerely hope there’s more embedded agile in the cards for future agile conferences. James Grenning and Nancy Van Schooenderwoert have done a great job putting the stage together. It’s come at a good time too with embedded systems becoming increasingly relevant. Continue reading

Posted in Agile2011 | 1 Comment