So pretend you’ve dedicated about 5 years to something you believe in… I mean really believe in. At the beginning it seems like you’re the only person in on it (or 1 of 2 in my case considering Bryan was the guy that gave me the first little push). It seems to make so much sense but you can’t figure out why others haven’t seen it already. Then slowly… very slowly… you see people pop out of the woodwork from around the world. At times you get the feeling there’s a community being built, and that you’re a part of it, but it’s still so early that it’s not entirely clear who’s in your little community or where it even exists. Sometimes you question whether it actually exists at all… but you keep plugging away because you believe in it.

Then you spend a week in Hillsboro and find out that there are hundreds of people working toward the exact same thing you are.

Surprise! The agile hardware community does in fact exist. It’s a relief to actually see it :).

This week, I’m at the Intel Agile and Lean Development Conference in Hillsboro. Back in March, the agile coaching group at Intel were nice enough to offer me a few slots on the program and I gladly accepted (who would pass up the opportunity to talk to actual hardware developers about agile hardware??). It’s been a great 3 days so far and as I’ve done for previous agile conferences I wanted to give people a run down of what happened. This’ll be part one (provided I get finished before I fall asleep on my laptop). I’ll probably post part 2 tomorrow.

---

Monday Coding Dojo

My week started on monday when had the chance to take part in a coding dojo. Having never been to a coding dojo before, I had no idea what to expect. From what I gather, you can have a coding dojo to learn just about anything. People here were focused on TDD. To do it, they took a problem – Conway’s game of life – with the language of their choice and solved it a number of different ways, with a number of different parters and a number of different twists.

When I walked in, the twist was people working together weren’t allowed to talk to each other. The only way to communicate was through code and tests. The next twist was that people couldn’t use primitive data types to interact with their design, only complex data types were allowed. I played passive observer for those 2 rounds and then jumped in for the last. That was a free-for-all where the only limitation was to use TDD. We used C# in visual studio (I think??) which obviously meant my partner was at the keyboard, not me.

Overall, it seemed people were quite happy with the exercise. There was a great mix of people from different sites and teams with different backgrounds and language and unit test framework preferences. It looked like a very good way to learn how to pair and learn TDD so it gives you the chance to kill two birds with one stone.

Attending the coding dojo wasn’t initially part of the plan but I’m glad I did. Here’s a link for more info on coding dojos if you’re interested: http://coderdojo.com/.

TDD in C Tutorial (Tuesday AM)

My big break with TDD came after I saw James Grenning’s TDD in C tutorial at Agile2011 in Salt Lake City. I’ve seen it once since at ESC in San Jose and Tuesday I got to see it again but this time as observer/helper (James is a pro so he didn’t need much help).

The difference this time around that I loved was that James runs his tutorial using Cyberdojo. If you’ve never heard of Cyberdojo, you should check it out. Instead of running on local tools or machines, exercises are done using a simple browser-based editor. You log into your session and everything is set up without any futzing around.

The magical part was that the Cyberdojo keeps a history of your activity where every run was captured as a red, yellow or green dot at the top of the screen; red is a failing test, yellow a compile/link error and green was passing tests. Stringed together, the dots show you how you’re doing. This is TDD so ideally, you’re looking for a repeating pattern of red then green (i.e. your test fails then it passes). You can also, at a glance, catch the pairs that weren’t TDD’ing! No red dots… no failing tests… no TDD.

“What you do tomorrow is your own business, but today we’re doing TDD”.

The best advice James had during the session was for people new to TDD: it’s a discipline to begin with but it ends up being an addiction. I’d agree with that.

An Introduction to Hardware TDD (Tuesday PM)

My turn. A 4 hour session dedicated entirely to hardware TDD using SVUnit. Seriously, what could be more fun!

As I said to everyone attending, the goal of the session wasn’t to learn TDD, it was to practice it. I gave a brief description of the TDD cycle and a few guidelines to start, then we got right into it.

After clearing a few technical hurdles (I’m quite sure no two hardware developers on the planet actually share the same environment setup) we did a kickstart exercise to introduce SVUnit. What’s a passing test look like, what’s a failing test look like, simple stuff like that. On test 3, most of the people in the class went through the TDD cycle for the first time ever. A couple more tests, people were familiar and we got to the real example.

In December I had the idea of putting together a modelling example based on the old HP48G calculator I had at university. It uses reverse polish notation and has about a billion different functions so it’s the perfect way to start simple, get increasingly more complicated and go as far as you want. Everyone used TDD to implement the numbers, stack and almost a few arithmetic operators. We did everything in pairs and one point I had people switch pairs and work on someone else code, exactly the type of thing that happens in the real world.

We had great questions and discussion all the way through. People were engaged and open to the idea. I know at least one person that’s committed to the idea which is great (as I’m typing he just sent an email saying he’s starting Friday morning). It’s pretty rewarding to see the interest.

The thing I didn’t do was hand out the Intel sponsored prizes at the end of the tutorial! I know who my winners are, I just need to find you before end-of-day tomorrow!

All-in-all, very happy with the session. Couldn’t have gone much better.

Wednesday Keynotes

The morning keynotes on wednesday were given by David Hussman from DevJam and James Grenning. I’m lumping these together because both guys had similar messages from different angles.

Both, over the years, have seen agile practiced so many different ways by so many different people and both had examples of how teams have tried to follow agile by the book while forgetting some of the motivations behind why they were using it in the first place.

David emphasized how agile had become a process that teams follow while forgetting about the product they’re delivering. Teams need to forget about the right and wrong ways to be agile and instead find the way that works for them. Today was also the first I’ve seen of dude’s law where Value is directly proportional to Why (why the product does what it does) and inversely proportional to How (how you do what you do); value increases as you focus more on the product and decreases as you focus on the process you use to build it (I think that’s right??).

James pointed out that many teams are so focused on the team and structure that they forget that technical competency is an obvious requirement of every development team; it’s a strategy without the tactics to follow through. He suggested that with Scrum being so popular, teams need to reconnect with the technical practices of XP; it’s the combination of the two that’s powerful.

Keynote highlight: David referring to his fashion sense as business camping. Nice.

Open Space

Wednesday afternoon was dedicated to open space guided by Diana Larson. Open space is a loosely structured way of letting people organize themselves into groups and conversations that matter to them.

Large sticky notes were spaced around the auditorium. People interested in hosting an open space discussion wrote their topic on the sticky note and announced it on the mic so everyone knew what they planned. Boards at the front of the auditorium started as an empty agenda. As people announced their topics, they put their sticky notes on the board to settle on place and time. When the topics stopped rolling in, everyone picked a session and the discussions began.

I teamed up with a few local guys and a couple fellows from Chandler to talk about agile hardware (surprise). We talked about some of the challenges of defining DONE for a hardware team, how to limit work in progress, the interactions between design and validation teams and TDD in RTL design.

Open space was an excellent way to enable the conversations that people were obviously interested in having. There was no looking around when Diana asked for topics, people dived right in. The boards were full and everyone was participating. Quite a good idea.

---

That’s it for today. I did skip a park bench session of industry experts that I’ll try and cover tomorrow. The two big sessions for me tomorrow are at 11am – Agile Applied to Hardware Development… We’re Not That Different After All – and 2pm – An Incremental Approach to Functional Verification. Hoping to have good crowds at both!

-neil