You’re in a training course. It’s noon on Friday and more than four days have just flown by. You’ve covered several different topics; some you like and some you don’t. A few you want to start using; others not so much. You’ve learned a lot of new things and it’s been a great week. On Monday though you’re going to get thrown into the deep end, all by yourself, where you’ll need to apply your new knowledge. What do you do?

This is what we did.

In early December I delivered a week of hardware TDD training. It was a good week with lots of questions and discussion (not to mention a lot of TDD’ing). At the conclusion of the week, we needed a way to help the team take what we practiced and carry it over to the following Monday and beyond. We had a few choices:

1. we do nothing and assume everything will just work out;
2. I tell people exactly what to do even though I knew little about what they actually did; or
3. let people figure out for themselves what to do.

Knowing very few things just work out, option 1 was never considered. Telling people what to do never seems like a long term solution so that was out. That left option 3 where participants plan for themselves how they’ll apply their new skills. To do that, we did an exercise called “My Commitment to Agile Hardware Development”. This is how it works.

A Commitment to Agile Hardware Development has 6 parts.

My commitment to Agile Hardware Development is to…

You’re advocating for agile hardware development and your commitment represents something you can do to help advance the movement. If you’ve come to the end of a training course, as we were, you’ll commit to applying knowledge or techniques learned. It doesn’t have to come from a training course though. Maybe you’ve come to the end of a book, read an article or blog, heard an idea from a friend or co-worker. Doesn’t matter. You pick something you’ve learned or heard about – something specific – that you’re interested in and you commit to improving yourself and the people around you by applying it.

Here’s a few examples:

• Start using TDD to write higher quality code.
• Create a more informative workspace to help teammates talk and share information more easily.
• Use incremental development for a new product so we’re focused and prioritizing effort.

This is why I’m making this commitment…

It’s not a new year’s resolution… though admittedly, the early January timing is a bit coincidental… so it’s not some big idea that fades until it’s forgotten. This is a serious commitment to yourself and there has to be some serious reason for making the commitment; some value that you hope to gain.

• Our defect rates are high. Our team will save a lot of time and money with lower defect rates.
• We’re often confused because we don’t share information well. Better communication will spread product knowledge and limit confusion around product features and purpose.
• Trying to focus on a complete product has been overwhelming in the past. Focusing on smaller portions will make the solution space easier to digest.

This is how I plan to meet my commitment…

You’ve got the what and the why, this is the how. Using broad strokes, describe how you’re going to meet your commitment. Ideally, you should probably note who is going to be involved and what their roles are (if it’s more than just you). You’ll need to know about tools and supplies you might need, techniques you’ll need to learn, the areas of your product where your commitment applies (and areas where it doesn’t). Basically, capture everything you need to be confident you can meet your commitment.

This is how I know I’ve achieved my commitment…

You’ll need some way of measuring whether or not you’ve succeeded in meeting your commitment so think of criteria that are as objective as possible.

• if our defect rates for new testbench code written using TDD decrease by 80%
• if by show of hands the team agrees that communication has improved and we’ve created less confusion around product features than in past projects
• if we’re able to release a small but complete slice of the functional design (with passing tests) to the physical design team

I plan to meet my commitment by <date>

Simple enough… pick a day and measure your progress by that day. Shorter timeframe is better so limit yourself to around 4 weeks. Measure your progress on that day regardless of how well you’re doing. Pick a day and stick to it!

Signed/dated

It is a commitment after all so to emphasize the commitment: sign it in blood (red pen or marker will also do), date it and get on with it!

Requirements for your Commitment to Agile Hardware are that it’s public and it’s visible. That way, people understand you’ve committed to something new. They can follow along if interested and of course motivate you if you’re in need of motivation :)!

Now while you may or may not succeed at achieving your commitment, success isn’t the only objective. Learning about agile hardware is the real objective, for you and the people around you, so as you work toward achieving your commitment be public about your progress. Use your commitment as a conversation piece for people that walk by. Tell people what you’ve committed to and why, talk about why things are going well (or not so well) and ask people for their opinions. By doing so, you’re raising agile hardware awareness and spreading your new found experience to others.

At the conclusion of my TDD course in December, we had 6 different Commitments to Agile Hardware that took about an hour to draw up. Commitments were written on poster-sized flip chart paper with coloured marker. All were different. They were tuned to likes and dislikes from the course material. They also took into account that participants were returning to different projects, each with different people and with different needs. The one similarity is that people walked away with something they were confident in and committed to. That’s the important part.  Everyone took a turn presenting their commitment in the class. Then they were unveiled to the rest of their teammates.

That’s a Commitment to Agile Hardware. No one’s forcing you into anything or committing to something on your behalf. This is your commitment to yourself… and to the future of agile hardware.

-neil

Challenge: why don’t you make a Commitment to Agile Hardware? Get a poster sized piece of paper, write up your commitment, sign it and post it on your wall. Bonus points to anyone that sends in a photo to post in a subsequent blog! (I’ll be posting my commitment shortly)