Here’s a guest post from Soheil Salehian, the fellow at University of Calgary who is helping me out with the Agile2014 co-development demo. It’s been fun working with Soheil thus far so I asked him to jot down a few thoughts on why he’s interested in agile hardware and what he’s hoping to get out of our demo development. Here’s what he had to say…
I have always been a firm believer that once you start learning a concept at some level, it is often incredibly rewarding (or at least humorous!) to step back and ask yourself: ”why am I learning this? Does learning this concept get me any further in anything?” The interesting thing is not the actual answer but the rewarding process of asking those type of questions. For anyone familiar with Agile concepts, such questions may resemble asking for feedback which is the most valuable part of using the Agile methodologies and processes in the first place.
Now a little introduction about me, I got the ”Agile sting” while working at Intel as a hardware verification engineer about a year ago. In our team I pushed for some implementation of Scrum that wasn’t a bad first crack at it. Since then, I have moved on to become a poor grad student here in Calgary in embedded hardware/software co-development using test driven development.
Luckily it turned out that Neil, who I met during my time at Intel, is co-located here in Calgary. When he approached me about the idea of designing a demo on a hardware platform for the Agile conference down in Florida this year, I knew I had be part of this in some way. First because it is a great opportunity to practice TDD concepts and second because it is a real hardware/software co-development application to show off to the software guys that Agile hardware is a real growing movement. We also picked a real dev board to do this and I knew we would have a real chance to show other fellow hardware and software Agile developers that this stuff really works. Now don’t get me wrong, we know we have our hands full with this project but I think both Neil and I are feeling pretty stoked about working on this demo. I know for my side that the experience of software/hardware development using pure TDD techniques on a real platform will not only help me grow as a hardware engineer but also get me to understand why I have 1 been trying to learn about Agile in the first place! It would be interesting to get to know stories of other hardware developers who are making the switch and their reasoning behind it. I am certain of one thing: the answer to the ”why Agile?” question will get you even more hooked!
Soheil and I will post a lot more as the demo comes together so stay tuned!
-neil
Neil,
A handful of engineers and I are trying to promote Agile methods for firmware (FPGA) development within my firm. Most of the company depends on the waterfall approach. How do I sell Agile FPGA development a) to my management and b) to skeptical engineers? Do you recommend any tools to assist development? What development metrics should be collected (lines of code / man-hour, requirements verified / man-hour)?
Thank you,
there’s a lot of people in your shoes, that are going against the grain, so your question is a common one. my thought on this hasn’t changed much in the last few years… it’s been to demonstrate benefits (as opposed to selling benefits) by committing to new technical practices that can help you and your group improve and being public about your commitment and success (or failure).
I’d recommend choosing from the primary/corollary XP practices. reason I prefer starting with technical practices is that there’s often no reason to even involve managers or sell your position. you can do many of them under the radar and report the results (results are harder to argue with than ideas/proposals). and I don’t think it matters what waterfall process surrounds you. if you go the other way and try implementing a development framework (i.e. scrum, kanban, whatever), that’s where things probably get tricky wrt management/colleague buy-in. not that it can’t be done, but it’s tough as a first hurdle and you’ll need the technical practices anyway to be successful.
in terms of metrics, I like quantifying improvement relative to quality (i.e. defects found/filed) and measuring progress relative to requirements verified/
-neil