Considering there’s been lots of new visitors to AgileSoC.com the last few months, I figured now would be a good time to (re)welcome everyone with a reminder of why we’re all here!
Where Does Agile Come From?
Agile is a development philosophy we’re borrowing from the software crowd. We’re using it to transform the way we build hardware. We start with the 4 values of the agile manifesto:
- Individuals and interactions over processes and tools
- Working software (hardware) over comprehensive documentation
- Customer collaboration over contract negotiation and
- Responding to change over following a plan
Then we strive to embody these values through a combination of attitude, culture, technical practices and frameworks.
Agile is not prescriptive technology; there will be differences between agile teams.
What is Our Goal For Agile Hardware Development?
I’m an idealist. Considering agile hardware is in its infancy, it would be a major opportunity missed if we start with the goal of being anything less than ideal. Shooting for the stars is the only reasonable thing to do. Therefore…
The goal of an agile hardware team is to develop the customer relationships, culture, teamwork, technical skills and supporting structures and practices necessary to enable immediate deployment of an SoC, ASIC, FPGA or IP while working at a sustainable pace.
It’s taken me 5 years to put it into words, but that’s finally it; that’s the goal of an agile hardware team. It’s a lofty goal, but I don’t really see any viable alternative. This is the course we set, then we take baby steps (or giant leaps) toward achieving our goal.
(The exact definition of deployment varies by technology, but in the general sense deployment means development stops, you package what you have, send it to your customer… or to the fab, then to your customer… then carry on with development if necessary.)
Achieving Our Agile Hardware Goal
People will have their opinions about the best way to get started. Some will believe in a top-down approach driven by management. Others will see a bottom-up approach approach lead by developers. Then there’s the various technical practices, frameworks and process tools to consider. Finally, there’s the role of EDA and how it supports a new development philosophy.
I strongly believe that agile hardware will start as a bottom-up movement where developers take the lead and managers assume the role of enabler to support experimentation and growth. This is based on a) comments and discussion I’ve heard in software circles regarding successful and failed agile transitions; and b) the fact that agile was proposed by developers for other developers.
I also believe that technical practices from XP are the right place for developers to get started as opposed to looking first to Scrum, Kanban or other frameworks (though if you have a different opinion, we can still find agreement that starting anywhere is better than not starting at all!). Many of the technical practices required to support Scrum and Kanban are so much different than what we’re used to that it’ll take us some time to catch on. As we get comfortable and gain an understanding of what we’re in for, we can carry on toward Scrum and/or Kanban and/or somewhere else, if necessary.
As for EDA, it will have to assume a support role, responding to the newly discovered needs of developers. Notable for EDA will be the challenge of responding with tools that enable incremental development through the physical design tool chain in a way that shortens feedback loops as much as possible. There will also be opportunities for open-source development in areas where EDA is slow to respond.
One Person Can Make A Difference
Even if you find yourself deep in the bowels of the most rigid development structure ever created, anyone with a little gumption can get started with agile. Refer to XP for technical practices that can be successfully adopted by individuals with little or no impact to existing practices while drawing little or no attention to yourself.
Remember that before there was agile software, there wasn’t agile software… and that some within software still don’t believe it’s possible even now that it’s becoming mainstream. We’ll have the same within agile hardware for a long, long time to come.