Not A Problem… The “Fluffy Stuff” Isn’t That Important Anyway

There are 17 different stages at the Agile2011 conference in Salt Lake City that cover a wide variety of topics. Though there are obviously technical stages (it is a software conference after all), what would probably look odd to hardware developers browsing the program is the number of stages dedicated to the non-technical (aka: the “fluffy stuff”).

Yes, you did read stages dedicated to the “fluffy stuff”, not just individual sessions. The 5 that stick out to me are:

I know that these topics are important to agile developers so I wasn’t too surprised to see them. What did surprise me though is that not only are these topics covered at Agile2011, they’re well covered with an average of 15 sessions for each stage! Now, I’ve never been to previous Agile2xxx conferences, or any software conferences for that matter, so I know nothing of content and quality (both of which I’m assuming are decent). But by the simple fact that these sessions take up almost a 3rd of the program, the folks that put this on seem to think they’re worth the time and effort.

In another universe… could you imagine going to DVCon and seeing a track called Collaboration, Culture & Teams with 22 sessions? Would SNUG, User2User or CDNLive have a track called Coaching & Mentoring with 15 sessions. How about just 1 session? One bright light I do see is at DAC where they have a “Management Day” on June 7th. Other than that, topics stay pretty technical at all of the above. I list these conferences because they are reasonably accessible for the average joe and generally well attended. If there are other conferences I’ve missed that do fit the bill, I’d appreciate you letting me know.

I’ll venture a guess that the sessions I point out don’t get run at hardware conferences because we hardware guys don’t have much of an appetite for the “fluffy stuff”. Even though leadership is important, even though we could probably learn something by listening to how out peers work with customers, even though there are times when we need to coach and/or mentor colleagues, we probably rely more on what we’re born with and experience first hand than what we learn. Or maybe as a group we figure that technical excellence will compensate for lacking the “fluffy stuff”? Maybe we already know what we need to know! Who knows for sure.

It is hard to argue against the fact that “fluffy stuff” plays a tremendous role in hardware development. There’s no denying it. And we could likely get better… much better… though it seems we’re a little behind when it comes to realizing it!


Q: Got an opinion for why the agile software crowd spends so much time on “fluffy stuff” like leadership, coaching and mentoring while we hardware folks appear indifferent? I’d like to hear what you think!

Regular Delivery… It’s Part Of Being Agile

In a post a few weeks ago I talked about how regular delivery wasn’t actually the point of being agile in hardware development. While the software guys can deliver on a weekly or monthly basis, taping out an ASIC every week doesn’t make much sense. Obviously. But even though regular delivery makes no sense for an ASIC doesn’t mean agile isn’t applicable. The value of agile in ASIC development is the ability to demonstrate progress. I believed that when I wrote it and I believe it now.

So why the contradiction in this post? Why am I now saying regularly delivery should be part of agile hardware development? While it might not make sense for ASICs, regular deliver is entirely possible with an FPGA or an IP block.

Before you shake your head, think about why agile software teams deliver product regularly. The goal for any software team is to satisfy customer need. Sounds simple enough except that sometimes customers don’t know what they need… so they ask for what they think they need or worse, what they want. If you (the development team) disappear for, say 9 months and then hit them with finished product, there’s a decent chance someone ends up being disappointed.

Development team: “All done! This is exactly what you asked for in this giant ambiguous requirements spec! I hope you love it!”

Customer: “I don’t love it because that’s not what I asked for.”… or… “Hmmm, I guess that’s what I asked for but what am I supposed to do with it.”… or… “Super, but I don’t need that anymore”.

Experience has shown agile software teams that keeping your customer involved in development helps avoid delivering a disappointment. Involved doesn’t mean telling, it means showing. Showing customers product as it’s being built helps them identify what they need and prioritize what they might not need. This works in software. There’s no reason to think it couldn’t work for an FPGA or an IP block.

“You mean we should be able to ship an FPGA load or an IP block every few weeks/months?”


“Even though it isn’t done?”


“But we’d have to change our whole delivery process or we’d end up wasting all our time on packaging the thing instead of building it.”


“…and we’d need automated regressions…”

Uh huh.

“…and we’d have to help them with integration so they know how to use it…”

Right again.

“…and we’d need user guides and documentation in place…”


“…we’d probably need a reference design, maybe even a board ready way before we’d usually have one…”



“…but what if there’s a problem with what we’ve built?”

That’s kind of the point.

With an ASIC, it’s not possible to incrementally deliver the real thing but there is still value in hardware simulation/co-simulation demos, emulation demos, intermediate size and power calculations, etc. It’s not perfect but it’s better than going the distance, sharing progress through status reports and hand waiving only to find disappointment when you’re done.

With FPGAs and IP it’s different. Regularly delivering product to your customer even though it isn’t done could end up being an invaluable learning experience. And unlike an ASIC, it’s entirely reasonable. Yes it could require major changes to how you develop and package your product but the customer feedback could be worth your while. Even if you only do it once, think of it as working out the kinks so there’s a better chance of bug free delivery when you are done.

Better to discover that what you’re building isn’t quite what your customers need in a month or 2 than funding a massive development effort and finding out months later.

Possible? Not possible? Ridiculous? Let me know what you think!


Agile Hardware Starts As A Steel Thread

For me, a key to agile is incremental development. Most software developers reading this will probably say “duh… no kidding” but it’s a new concept to hardware folks.

If you’re new to agile, incremental development is something I’ve talked about in several articles on In a nutshell, it’s where product features are designed, implemented, tested and ready to go in small batches. Products start small but functional then grow in scope until they are delivered (they can also be delivered *as* they grow but I’m not going there today).

Because most hardware teams are used to developing products as big bang feature sets, incremental development can be a big step. To help teams get started, I put together an article called Operation Basic Sanity: A Faster Way To Sane Hardware that spells out how a team can deliver a small batch of features equivalent to a functionally sane device. That article was actually inspired by an exercise I called the “Steel Thread Challenge”.

Steel Thread is a term I’ve seen to describe some minimal thread of functionality through a product. I think about it as being able to <do something simple> to <some input> so that <something basic> happens on <some output>. As a hardware guy, a steel thread seems synonymous with a sane design. It’s small relative to what remains but significant in that you know the design is doing something right.

The Steel Thread Challenge: How-to

What You Need: The Steel Thread Challenge is a retrospective exercise that works back from a finished product. Choose a design that you’ve just finished or is at least well into development. You’ll also need a conference room with some whiteboard space.

Who You Need: You’ll focus on front-end development so include designers, verification engineers and modeling experts as well as the system architects and managers.

Step 1: Describe the product: On a whiteboard, draw a block diagram that includes the design and test environment. You should end up with something like this (except the blocks should be labelled)…

Step 2: Find the steel thread: Decide as a group what constitutes a steel thread (HINT: it should be a simple function that provides some tangible outcome). Identify the main processing path of the Steel Thread by drawing a line through your block diagram. That should get you to this point…

Step 3: Remove everything you don’t need: The goal is to find the smallest code footprint that supports the Steel Thread. By analyzing how your Steel Thread travels through the design and test environment, erase everything that isn’t needed (best to take a picture of what you have so you can redraw it if necessary!). First erase entire blocks if you can. If logic can be moved or simplified to remove entire blocks, make a list of necessary simplifications and then erase those blocks. From the blocks that remain, make a list of the features that aren’t necessary and could be ripped out. That should leave you with a list of what’s been removed and a diagram like this…

Step 4: Planning for the steel thread: Now the “challenge” part of the Steel Thread Challenge. This is a mock planning exercise where as a group you discuss how you would build, test and deliver a Steel Thread starting from a clean slate. Pretend your Steel Thread is your product and you have to deliver it asap. How would you get there and how would it be different from what you normally do?

  • would the code you write be any different than usual?
  • would teamwork and/or organization be the same or different?
  • what would your schedule look like?
  • what would your documentation look like?
  • would your task assignments be any different than normal?
  • how long would it take to deliver the steel thread?
  • is there planning that could be delayed relative to what you normally do?

If you and your team try this exercise, I’d like to hear how it goes. If you have other ideas for helping people jump the “big bang to incremental development” hurdle, I’d like to hear that also! This will be a big step for many teams so the more options we have, the better!


The Newbie’s Guide To

For anyone that’s new to, here’s a guide to what we have. I have all the top ranked articles here. I also have my favorites… these articles aren’t necessarily the most popular but they’re the ones that I’m happiest with. Finally, a couple of sleeper articles.

…and don’t forget to follow the discussions on the linkedin group!

Top Ranked

  1. UVM Is Not A Methodology: This one is top ranked by a mile. Primarily for the verification engineers out there, this article discusses what teams need to keep in mind when adopting technology like UVM.
  2. Top-down ESL Design With Kanban: This article came together as I was reading 2 different books (ESL Models and their Applications (1st edition) and Kanban and Scrum: Making the Most of Both). It combines the modified V approach to system development that Brian Bailey and Grant Martin present and Kanban, which Bryan Morris and I have always thought as being hardware friendly.
  3. An Agile Approach To ESL Modeling: This is a general article for the ESL crowd. Why is modeling important, how modeling can fail and how agile can help modeling teams succeed.
  4. Agile IC Development With Scrum – Part I: the first of a two part video of the paper Bryan and I presented at SNUG San Jose in 2010. In the video, we talk about how hardware teams would have to evolve to adopt Scrum.
  5. IC Development And The Agile Manifesto: The Agile Manifesto spells out the fundamentals of agile development. This article shows how the manifesto is just as applicable to hardware development as it has been to software development.

My Favorites

  1. Operation Basic Sanity: A Faster Way To Sane Hardware: agile makes sense to a lot of people but getting started can be tricky to say the least. I like this article because it gives news teams a way to get started without changing much of what they already do.
  2. Top-down ESL Design With Kanban: top ranked on the site and also one of my favorites.
  3. Agile Transformation In Functional Verification – Part I: I think this is another good article that helps verification teams take the mental leap into agile development.

Sleeper Articles

  1. Realizing EDA360 With Agile Development: If you’re not into the EDA360 message from Cadence, then the title might scare you away. But this isn’t just more EDA360. The theme here is convergence in hardware development, how functional teams drift apart over time and how agile can bring them back together.
  2. Why Agile Is A Good Fit For ASIC and FPGA Development: I think this was the first article we posted. I go back to it periodically just to see if our early writing still makes sense. I think it does!


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

Regular Delivery Isn’t Really The Point

Living the role of agile hardware development advocate has been a learning process for me. Obviously, I’ve learned a lot in terms of agile development process but that’s not all. I’ve also had a chance to speak with people seeing new ideas for the first time. That’s been very interesting for me.

Through talking with people, I learned quickly that people sit in 1 of 2 camps when you present the basics of agile hardware development. The first camp responds with “what a great idea… this makes a lot of sense”. The second camp responds with “this doesn’t make any sense at all… how the heck am I supposed to tape-out an ASIC every week/month/quarter?”.

To the first: I enjoy the long discussions we have. I’d say great ideas, opinions and concerns flow both ways. There’s always some skepticism (which there absolutely should be) but there’s a level of acceptance and that’s been encouraging.

To the second: this may seem a little odd… but discussions with you guys have become more valuable to me. I’ve found that a great way to learn is to have my opinions methodically dismantled by an all out pessimist. I get to hear all the reasons why I’m wrong in one short burst. Awesome! The argument against usually starts with how product and delivery are too different between software and hardware so agile can’t work. They might be able to deploy product weekly, but us taping out an ASIC several times is entirely ridiculous.

That discussion can go further but it’s the “product and delivery are too different” argument that allows people to dismiss agile out-of-hand.

Conveniently, I recently found that I’m not the only one bumping into that argument. In this article just published on eetimes (which is a good intro level article and not just for embedded software developers), James Grenning makes a very good point related to development and delivery of embedded software. It seems some in the embedded software world are using the same argument to dismiss the potential of agile:

Because value cannot be delivered each iteration some say that agile cannot be used on embedded software development. My opinion is different. Instead of delivering value, we provide visible progress. I don’t mean doing show and tell on what might be build, but rather a demonstration of real working running software.

Substitute “hardware” for “software” in that quote and I think it’s a decent response to the “product and delivery are too different” argument. Of course it’s absurd to think an ASIC should be delivered every week or every month. In fact that argument is so valid that it’s silly to get caught up discussing it. Instead, and just as James notes for embedded software, the potential for agile in hardware comes from regularly demonstrating progress instead of just describing it in documentation and discussing it in meetings.

Regularly demonstrating progress is where the discussion of agile in hardware development should be starting, regardless of what camp you’re in.