This post is a little different than what I’ve been doing here so far because it’s directed at only 1 person. This person is new to agile. We have talked about it a few different times and last time we talked she mentioned:
“most of what you have on AgileSoC.com seems to assume you already know about agile… I wish you had some stuff for beginners.”
Point taken. Here’s a post just for you… and any other beginners that want to stick around.
First a little more information on this mystery person. Let’s call her Jaime. Jaime is a real person though Jaime is not her real name. She is a verification engineer that I’d rate as being quite good at her job. She’s worked with a few different organizations and teams, is technically very capable and does a good job at staying current with respect to new technology. Seasoned, smart and current… just like a lot of other verification engineers, though fortunately for her she’s a little different. The thing that sets Jaime apart from other technically capable verification engineers are the intangibles that make her a good co-worker and teammate. She’s very easy to work with. She’s opinionated (in a good way), understanding and open-minded.
An agile hardware skeptic is a person that sees there might be value in using agile but they aren’t yet convinced. Like I noted in my Agile2011 talk, Applying Agile To Hardware Development, I see most people involved in hardware development as being agile hardware skeptics. If it seems like I use the term skeptic negatively, I’m not; quite the opposite in fact. I think anyone new to agile – from hardware, software or where ever – should start as a skeptic. Agile hardware skeptics are ready for new ideas but they take the time to think about things. They aren’t into bandwagon jumping and they don’t take people’s word for it. They want to decide for themselves whether or not agile is right for them and their team. You may not believe this if you’ve been following AgileSoC.com, but I fight to remain an agile hardware skeptic. As soon as I find myself becoming a believer, I forget about the tough questions I should be asking. Agile in hardware cannot be the same as agile in software so the tough questions keep things real and on track.
I see all of the potential for agile in hardware development being fulfilled by skeptics hence the importance of this post to reach out to people like Jaime and others like her.
Jaime: “OK… OK… blah, blah, blah. Convince me agile belongs in hardware development!”
Right, let’s get to that now. From the top, regardless of what you’ve heard from me or anyone else, Agile is 4 values and 12 principles. That’s it. If you want to start anywhere, start by understanding that. (You’ll find everything in the Manifesto For Agile Software Development. You should read that now, then come back!)
Next, it’s time for some note taking. Write down all the times you’ve been in the groove; the times you’ve been really productive. What is happening in those situations and why are they special? Think about the people around you when you’re most productive. Why are you working so well together? What have your objectives been and why have you been able to achieve them? Why are things going so well?
Now jot down all the times you’ve been through a really tough slog or been brought to a grinding halt. What’s bringing you down? Why is it happening? How do you know the difference between something that’s going well and something that ends up falling apart?
Write down all the things that you’ve done repeatedly that have never made sense. Why do you do every little thing that you do? Think about the goals you’ve set that you have never been able to reach; the ideals you continuously reach for, desperately, but have never achieved. Think about the concessions you repeatedly make. Think about why people are always disappointed but never surprised when things don’t work out as planned.
Finally, and most importantly, think of yourself as the person paying the bills. What are the things you’d pay for? What would be important to you and what are the things you’d consider a useless waste of time? How would you want to be informed? Be realistic… but don’t limit yourself to what’s been done. Open yourself up to what could be done. Question everything.
Finally, compare everything you end up with to the right and left columns of the 4 values of the agile manifesto. Where does everything you’ve written down fit in? On the right or on the left?
Jaime: “Wow… that’s ridiculously vague and I’m more confused that before. Thanks for that!”
I know, I know… all of the above amounts to a pretty abstract exercise. But lock yourself up for an hour and do it anyway because it’ll help you understand why you’d even contemplate using agile. Those kinds of thoughts have to simmer for a while to become real motivation but be patient, the “Ah-ha” moments you jar loose could be worth it.
I’ll wrap up by saying that seeing agile simply as an alternative to what you’re doing now won’t get you very far. Basing your opinion on what you’ve heard from others – good or bad and me included – probably won’t be much better. You could end up underachieving at best or walking away from it altogether.
So Jaime, other agile hardware skeptics and agile beginners, I’d encourage you to unlearn whatever you have learned and start again with the agile manifesto. In my opinion, it’s pretty hard to argue the values and principles can’t be applied. From there, analyze everything you associate with how you work and form your own opinions on whether or not agile can help you.
Keep the skepticism… but use it constructively :).