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

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

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

Agile2011 Round-up: Day 2

Day 2 General Observations

One thing I missed pointing out yesterday was the cross section of people at this conference. Yesterday I talked to people from Nike, Schlumberger, Siemens, Esri, Department of Defense, John Deere, CGI and a few others that I don’t remember. There’s a really interesting mishmash of people here.

Tuesday Keynote (9:30)

Fair to say that today’s keynote was different than anything I’ve ever heard at hardware conferences. Talking this morning was Dr. Barbara Fredrickson who is… wait for it… a psychologist!

A psychologist?

Continue reading

Agile2011 Round-up: Day 1


We’re off and running at Agile2011! I haven’t run into any other pure hardware guys so I’ll take it upon myself to do a daily round-up for the hardware folks that want to follow along. No promises… but I’ll try and do the same each night that I’m here.

Day 1 General Observations

The first thing to note was the seating arrangement in the rooms. I’m used to rows of chairs aimed at a presenter and screen; you might talk to the person beside you a bit but for the most part, you’re their to be talked at (until a Q&A). The seating arrangement here… very different. It was more like lunch time seating where people sat in groups around tables. About 4-8 people to a group seemed the norm. More inviting for sure compared to just staring at a screen and being blasted by an information fire hose. Continue reading

Help Us Embedded Software Developers… You’re Our Only Hope

Agile2011 will be my first time talking to crowd of embedded software developers. I already know tossing my hat in the ring has been a good idea because the whole experience has me thinking from a different direction. I’m starting to see the necessity of better collaboration between hardware and embedded software experts on SoC development teams, but it didn’t really gel until I started thinking in terms of system functionality and usability.

I’ve used this slide with a generalized design flow once before with a mishmash group of software developers to illustrate how our respective disciplines tie together. It’s a 5000ft view of an SoC development meant to show how we work on two different ends of the development spectrum.

We hardware developers live down in the weeds. We see things like gates, counters, filters, packet transformation, the details of an interrupt mechanism and pin-level communications protocols. Our deliverables are normally captured in a hardware specification and our job is to build the hardware such that it’s functionally correct before it’s taped out. We are not users nor do we have much direct contact with users so the concept of functional correctness is probably the best we can do.

Software developers are at the far end of the spectrum. Gates and pin-level protocol mean nothing to them. Their job is to take the hardware we’ve given them and make it usable for our customer.

A potential problem with this situation, in case you haven’t seen it yet, is that hardware that’s functionally correct doesn’t necessarily translate to hardware that’s usable. We hardware developers can stew over clock-by-clock details that have zero impact on the system, while at the same time brush off details that can cause head-aches for software developers or even cripple the system entirely. Corner cases for us can be primary functionality for them.

So how can we close the gap between functionality and usability? I think there’s work to do on both sides of the fence.

Embedded Software Developers

  1. Get involved early with the design of the hardware and stay involved
  2. Help your hardware teammates think in terms of system-level usability
  3. Include hardware developers in customer correspondence and see that issues of usability are broadcast to the entire team
  4. Develop software as the hardware is being developed so that your feedback can be used to tune the hardware

Hardware developers

  1. We aren’t users so it’s difficult for us to think like users. Realize that in terms of usability, we generally don’t even know what we don’t know
  2. Help your software teammates understand the possibilities and limitations of what you can do in hardware
  3. Work together with software developers during design and implementation of APIs instead of guessing what software developers might need or waiting for them to tell you
  4. Supply software developers with early prototypes or models to enable early software development
  5. Don’t optimize hardware without considering the impact on the software


  1. Treat hardware and software developers working on the same SoC as part of the same team
  2. Ensure hardware and software teams are co-located (or at least partially co-located) so communication is productive
  3. Use a common reporting structure for hardware and software developers to avoid personnel conflicts
  4. Enable and strongly encourage co-development of hardware and software

All these are things I thought of while putting together my Agile2011 talk. I like the functionality and usability labels to emphasize that the focus of hardware and software experts is fundamentally different. I’m hoping bringing functionality and usability together underscores the critical importance of early collaboration with software developers. They understand the system and interact with users in ways that we don’t.

Considering everything they do know with everything we don’t, if we plan on having happy customers, they’re our only hope!


A Better Way To Manage Conference Proposals

UPDATE: With acceptance emails going out for Agile2012 this morning, I thought it’d be a good time to re-spin this entry from last year’s run-up to Agile2011. If you substitute 2012 for 2011 and Dallas for Salt Lake City, I reckon everything else I had to say last year applies again this year. I like the process.

Special note for this year’s conference, Agile2012 will have 2 talks on ASIC and FPGA development. My proposal for “TDD And A New Paradigm For Hardware Verification” was accepted. As well, Tobias Leisgang from Texas Instruments had a talk accepted, How to play basketball with a soccer team? Making IC development more agile. You’ll find both on the Emerging Applications of Agile stage.

One hardware talk at Agile2011, two hardware talks for Agile2012… hopefully there’s a pattern developing here!

As I mentioned in a post a couple of weeks ago, submitting a proposal to Agile2011 was a last minute idea for me. I figured that since I had a collection of material ready to go, it wouldn’t take me long to put something together. I was almost right.

I’ll start by saying that the submit/review process for Agile2011 was about as transparent as I could have imagined. I’m used to writing an abstract, pulling together an outline, sending both away and then waiting for a yay or a nay a couple months down the road. That’s how SNUG generally works (I’ve presented 5 papers there… last in 2010) and DVCon as well (in 2010, Bryan Morris and I submitted a paper called Agile Techniques For ASIC and FPGA Development… it was rejected).

I’ve never had a problem with that, but the submission process for Agile2011 was different… dare I say better different… but I’ll let people decide for themselves.

The submission process was all handled online. Would be presenters login to write a summary of their talk in 600 characters or less, describe a set of “learning outcomes” (which I believe tells the audience what they should be taking away from the talk and who we think should attend) and finally the “Process/Mechanics” section which I think most people use to capture their outline. You also select a stage (of which there are several) where your proposal best fits. Here’s a description of the stages if you’re interested. I’ll talk more about them another time.

Pretty normal so far, except that all proposals are treated as proposals-in-progress so you can edit them at any time. They are also viewable by other presenters and anyone else who is interested, not just the official reviewers. I liked that. Seeing and discussing proposals before they’re accepted was something I wasn’t used to. I could contact other would be presenters to ask questions. We could also work together to avoid overlap. I’m guessing that makes for a better conference better by helping avoid repetitive material. We’ll see in August if that’s actually the case.

Also interesting was that there were options for session length/type. I believe there are 30min/60min/90min talks. There are also 3hour workshops and tutorials. Last are 10min lightning talks. Having different types of sessions is new to me, especially the workshops. Agile is supposed to be interactive so I’m thinking that the workshops end up being a conference highlight.

The best part though was that anyone could append comments to a proposal. That’s more feedback that I wasn’t used to and really appreciated. On average, each proposal got maybe a half dozen comments. From what I’ve seen and heard, comments were pretty constructive and helped would be presenters tune proposals over a number of weeks (mid-January to late march). All the comments I received motivated me to tweak my proposal. I’m guessing that most people ended up with proposals that were stronger than what they started with… I know mine was… so I’m pretty grateful to the people that commented.

From there, the official reviewers for each stage made their comments on each proposal after which I’m assuming they consulted with each other and the conferences organizers to decide which proposals were accepted.

Not an exact explanation of what happens but close enough.

Between the initial write-up, answering reviewer questions and revising my outline and summary, I spent maybe 4-5 hours on my proposal. Looking through what other people had, there are some that definitely spent more than that. There were also people that had 2 or 3 proposals… not sure where they found the time for it! I’m taking all the effort that people obviously put into their proposals as a sign that the prep time ends up being worth it 🙂

If you’re interested, you can take a look at my proposal for Applying Agile In IC Development… We’re Not That Different After All and the feedback it received (I’m excited that it was accepted to the Agile for Embedded Systems stage). Feel free to let me know what you think of it. You can find more details regarding how proposal are reviewed/accepted/etc in a write-up by Mark Levison on his blog. If you interested in seeing how Agile Alliance has things setup, you can go to

Neil Johnson

Lessons From A Software Conference – Part 1 of Several

Agile2xxx is a conference put on the Agile Alliance that has happened every year since 2003 (I think??). This year, roughly 1500 software developers from hither and yon will meet on August 8th at Agile2011 in Salt Lake City to hear colleagues speak, participate in workshops and discuss the next big things in software development. It’s not the only agile conference of the year but it’s a big one from what I understand.

I’ve enjoyed the opportunities I’ve had to present at conferences. But more so than at other conferences, Agile2011 is a chance for an experience that’s quite different. Why you ask? Well at hardware conferences, I talk to my peers–people that do the same things I do (which is mainly hardware verification). Acceptance and feedback can be mixed, but people normally get the gist of what I’m talking about. Compare that to me speaking at Agile2011.

  • Agile2011 is a software conference… I’m a hardware guy.
  • Attendees (I’m assuming ) are experienced with agile… me, experienced’ish.
  • Presenters (again I’m assuming here) are experts with agile… me, not exactly.

Hardly an exact fit. So why then would I submit a proposal? Admittedly, that was a last minute twitter-initiated decision.

Compared to agile software experts, I’d consider myself a rookie. A very enthusiastic rookie with decent experience but a rookie nonetheless. I have a long list of ideas for what should work in hardware development. I’ve done small scale rollouts of some of those ideas that have turned out successful. I’ve put a lot of time into it and because I’ve already given presentations and written about what I’ve been doing on, I figured I could cobble together a proposal relatively quickly. The submission process was an interesting experience. I’ll get to that in the next entry (spoiler alert: I did submit a proposal and it was accepted).

Back to the why… the first reason for me submitting a proposal to Agile2011 is to get expert opinions from others on what I think should work. I’m convinced that agile can work in hardware development, even though it is relatively unknown. I’ve seen it work on a small scale. The software guys use it so successfully that it’s ridiculous to think that we can’t use some of what they’ve already shown to work. The obvious differences mean it can’t be exactly the same, but the obvious similarities mean it won’t be entirely different either. Presenting my thoughts to a conference crowd gets ideas heard, critiqued and (hopefully) validated.

The second reason (which is where the title of the blog comes from) is that I actually intend to learn something from these strangers from the land of software! From the submission process to the preparation and the presentations, workshops, side discussions and everything else. It’s a different crowd and a different experience so I expect to be bombarded with great new ideas from a few different angles.

Finally, I would hope software developers listening to me talk about agile in hardware development will get something out of it also. If I didn’t think I could pull that off there wouldn’t be much point in me presenting anything!

Agile is big in the software community but relatively unheard of in the hardware community. I think has started to change that. I hope a presentation at Agile2011 is a good next step.

Stay tuned for the trials and tribulations 🙂

Neil Johnson