Thoughts on Verification: Agile From a Verification Perspective (Part 3 of 3)
In Part 3, Alex and Bryan discuss some of the growing pains of adopting or solidifying Agile methods in your verification process. Bryan also discusses about his website, which brings to light Agile related issues in SOC development. Part 1 and 2 can be viewed here and here respectively.
Special Note: If you missed Bryan’s presentation “Yes We Kanban” at the MTV Conference, never fear! Bryan will soon release a whitepaper on Kanban and its merits in the verification world. Look for it to be published soon on the Verilab website.
Alex Melikian: I’m beginning to get the picture that Agile is not a “one size fits all” solution, but a collection of methods that can be cherry picked to match the culture and working environment of the team. As mentioned previously, where cross auditing is used instead of pair programming, or vice versa.
Sadly I feel there are companies out there that don’t engage in any of these Agile techniques. There’s always a reason like lack of time and/or resources. Others however, I believe is simply due to omission, and that’s something that has to change. So how can we at Verilab help some of our clients adopt and benefit from Agile techniques?
Bryan Morris: If the client is not aware about agile, I think we can provide some education on the various frameworks and techniques, and then help them decide which best fits their unique culture. As well, we can provide some guidance on how to introduce the agile techniques. Almost nothing will guarantee an unsuccessful agile adoption if you try swap out what they are doing and and introduce a completely new “agile” way of doing things. I truly believe that it’s best to use an incremental approach. Pick and choose a few techniques that best fit your team’s culture and experience, and the closer to what you’re already doing the better. Make that successful, and then pick the next “low hanging fruit” to tackle. I think we can help to educate and encourage our clients.
Lastly, I think we at Verilab are all very pragmatic. Many teams can benefit from adopting agile techniques, but they still have to deliver the chip. We understand that, and will do our best to help adopt and adapt the best techniques for your team.
However, I think it’s still early days for using agile in hardware development. I’m encouraged that a blog that I started several years ago (http://www.agilesoc.com) is starting to gain a nice following with folks sharing their positive and negative experiences with adopting agile. Software development is ahead of us, but they are also allowing us to review what’s worked well and not so well for them, and then pick the areas that best suit hardware development. I’m encouraged and optimistic that the momentum is building towards adopting and adapting agile frameworks for hardware development.
AM: It’s true, again, those in the software world are definitely ahead in their understanding of Agile than those in hardware. However, the silver lining in this is that the software world does play the role of a guinea pig on some of the new Agile techniques, or even the existing ones, for the hardware folks. If someone in hardware is thinking of adopting an Agile technique, they can google it and see what the folks in the software world think of it. How practical is it to deploy agile on an existing project? Are there ways where agile can be employed in a more incremental and gradual way?
BM: By existing project, I’ll assume you mean one that is in progress. From that perspective, I think that the Kanban methodology is probably a better fit. Recall that Kanban is a methodology where you visualize your workflow through the use of a Kanban board. Meaning, at its simplest a whiteboard and columns indicating phases in the process with tasks/features identified on sticky notes. Tasks, or to use the agile terminology “stories”, are pulled across the flow from start to completion. Kanban’s key advantage is that it highlights bottlenecks in the process and when a particular story is not progressing. When introducing Kanban it is recommended that you always start by capturing your existing process on a Kanban board. Then as you become familiar with Kanban you can tweak your process, or incrementally add additional Kanban elements e.g., cumulative flow diagrams. Kanban encourages empirical analysis by providing quite a few easy to capture metrics to help identify any issues you have in your workflow, and then help with tracking where you are in the project.
There are obviously more details associated with changing a project management methodology mid-stream, and should only be considered if the project is in a bit of crisis. Then I think adding these agile techniques actually help, and Kanban especially by focusing on controlling and then optimizing your process.
AM: Of course when we talk about optimizing a process, we’re insinuating change. We all know change is part of our business, and, not surprisingly, some people are afraid of it, especially changes that are big. Hence, as you allude to, it is really important to carefully pick the right time to adopting changes like Kanban, Scrum or any other agile technique into the team’s management habits and culture.
You mentioned earlier about your website, agilesoc.com. Tell us, what motivated you to create and update this website?
BM: Agile techniques had been largely ignored in ASIC development. I wanted to create a place where we could start the discussion about how we in SoC development could adapt agile techniques. Creating a blog was an opportunity to have that one spot where I hope people can get background information, find the current thoughts on using agile methodology, share success stories, and perhaps more importantly, where some technique is really not applicable in the context of hardware development.
AM: … And more relevantly for our readers, tell us what material they may find useful on it?
BM: I like to think there are some interesting articles providing background information on the frameworks currently being used; thoughts that myself and my collaborator Neil Johnson think on how we can or have adapted specific techniques, and there are some opinion pieces, aka rants, on various topics that relate to how we currently develop ASICs and where agile could potentially help. Most importantly, Neil has been working extremely hard over the last year building on a tool I created called SVUnit which brings the Test Driven Development technique I described earlier. The TDD framework that SVUnit provides an easy way to create, add and run these tests. As I said, Neil has spent a lot of time over the past year adding concrete examples and tutorials on how to use SVUnit.
Lastly, as I said agilesoc.com is intended to be a place where we can have an on-going discussion about using agile techniques. Neil and I are the main contributors, but we welcome others to submit articles that we’d happily post on the site. In addition, we created an “AgileSoC” LinkedIn group where some discussions also happen.
AM: Sounds like a good resource for our readers interested in Agile in the ASIC/FGPA development business can look into. I encourage newcomers to use it to expand the discussion and share their experiences. As we’ve concluded, Agile has a lot of benefits for the hardware design community, however it has a bit of catching up to do with the software world in regards to it. Hopefully we can close this gap in the near future.
That’s all we have for this edition of ‘thoughts on verification’. Thanks for your time Bryan!
BM: Hey, thank you Alex!
