How do I get started with agile hardware development? That’s a question I get a lot. Do you ask for management approval or try something under the radar? Is a pilot appropriate or is it best to just go for it with the whole team? Is it better to start with this team or that team? And the biggest hurdle…
How do you get people to buy into the idea?
In terms of what to do, I like to steer people toward XP where they can match specific practices to their particular customer, product, strengths and weaknesses. But figuring out what to do can be the easy part. Figuring out how to roll it out is another challenge completely.
In the past, I had a habit of trying to explain my way into a consensus that agile practices X, Y and Z were the way to go. For me, that was the natural way to start. Find a good idea and explain it to the team. They of course think it an excellent idea and we decide to implement it.
Surprise! That didn’t work!
Instead, through trial-and-error I’ve found a more effective way to grow an agile team is to apply agile practices in a way that makes someone else’s life easier. Now admittedly, my experience is limited. I’ve never grown an agile organization from the grassroots. But I do have experience in overcoming skepticism and I’ve found that regardless of people’s initial impression of agile, it invariably improves if you use agile practices to make their life easier.
A few examples that have happened to me personally.
Making a Design Engineer’s Life Easier
I’m a verification engineer. From the beginning, I’ve assumed major productivity benefits as coming from incremental development and tighter coupling with designers. I’ve also found that explaining the benefits with words alone can be a tough sell at best. So I stopped evangelizing. Instead, I tell designers that I’m prioritizing my work to be able to incrementally roll out new testbench features. Then I explain how I can make their life easier…
“The testbench will support <feature A> within in the next couple of days. I’ll also have an RTL test ready to go.
I’ll leave it up to you, but if you’re interested you can focus on <feature A> and we can integrate it right away and run the test I have. That’ll tell you if what you have is working. It’ll also save you having to write any smoke tests.
If you want to give it a shot, just let me know.”
Effectively, what I’m describing is incremental development, a technique worthy of long philosophical debate. I’m framing it as a way to make a design engineer’s life easier, though. This has been a good way to avoid the skepticism and debate almost entirely.
Making a Manager’s Life Easier
Our big bang development makes manager’s job very difficult. We go to painstaking lengths to build a schedule that shows us finishing on time. For the first several months, we report week after week that everything is on track. Then quite suddenly, for whatever reason, fires break out everywhere and the schedule is fully and completely obliterated. Weekly progress turns into a weekly schedule slip. We fall into survival mode and managers are stuck explaining delays up the chain and eventually to customers. An easier way than big bang is to talk about how…
“…I don’t have much luck with detailed big bang schedules. I find they’re always too optimistic and they mask potential disasters making it difficult to react. So instead, I’d like to keep it to a ballpark guess for now with a list of features and tests I plan on running. We’ll make the test results visible. Starting day 1, I’ll publish updated test results as they roll in. You can check in for up-to-date numbers whenever you like. We’ll also use trendlines to revise our ballpark guess every week.
As well as the day-to-day reporting, we can use the test results as real evidence of whether or not we’re on the right track. And we can do that early, ideally within the first 4-8 weeks. If we’re struggling it should be obvious at that point and that’ll give you the time to react accordingly. Hopefully it’ll be easier for you to either bring on new people or reassess scope so we can keep to the scheduled delivery date.”
Again, this is incremental development but from a manager’s perspective so they can see better how their team is progressing and better predict and absorb major scheduling issues.
Anyone Can Do It
I’m going to step out of my comfort zone for a second and suggest other areas where depending on your position and specialization, you can offer to make someone else’s life easier.
Design/verification using incremental development to help with the software…
We’ve got the RTL for the software interface coded and verified. It doesn’t do too much yet, but the registers are there and they work. If you like, I can walk you through how we load it on the emulator so you can do some early driver development.
Using pair programming to help bring on new team members…
I could capture everything you need in an email, but I’d probably forget something. How about instead we move into the conference room for a couple of days and work together on this. We can take turns writing code and you can ask me questions as we go along. We’ll carry on until you’re comfortable with it.
Physical design engineers using incremental development to help with the RTL…
I’ve got a preliminary synthesis script in place. I can show you how to run it so we can make sure right from the start that our actual resource usage is close to what we have in the estimates. If we’re way off, that’ll make it easier for to to update your architecture before it’s too late.
Using test-first programming and pair programming to help a design engineer fix a bug…
I think I found a bug here so I wrote a test specifically focused on that line in the code. I committed the failing test so you should be able to make your fix then run the test to verify it before you deliver. I’m also concerned that we’re not hitting the corner cases here and here. If we can work together for a couple hours to come up with similar tests, that should give you what you need to verify we’ve got everything covered. We could even make the design changes as we go to save you some time.
Managers using shared workspace to help their team communicate…
I see you guys having a lot of whiteboard discussions and I’ve been trying to follow the email trails and bug reports. I guess you’re working pretty closely on this. Would it be easier if I found you a couple of desks that were closer together? You could have all these discussions right from your desk without having to email each other. We could probably find you another whiteboard, too, to keep track of the details.
The great thing about making someone’s life easier is that it automatically gives you a customer, a purpose, a feedback loop and opportunities to self correct -not to mention focus – all of which are pretty fundamental parts of agile development. If you were a real go-getter, you could even turn helping people into a series of short-term, bullet form contracts…
- I’m working for <someone>.
- I’m going to make it easier for them to <something>.
- In <time>, they can use it and tell me if it works for them.
- Based on their response, we can either quit, carry on or improve.
So if you know what agile development practices you want to experiment with, try thinking about how you can fill in the <someone>, <something> and <time>.
With that, the agile hardware experiment begins 🙂 .