Despite what some people may say about Agile being just for software development, Agile does work for other types of product development and support systems. Let's explore this topic a bit deeper by looking at a few different aspects over the next several blog posts. For today, let's talk about embedded systems.
As an engineer, I have always loved working on embedded industrial systems. My first job happened to be working on control systems that pumped fluids, pressurized activation chambers with radioactive isotopes, and centrifuges that tested the structural integrity of a semiconductor package that is used in rockets and Mars landers. You flip a control bit, and a high powered motor screams to life or some colossal valve opens. Nothing short of cool!
Most of the systems were built with a combination of microcontrollers and electromechanical failsafe systems to keep people safe in the event of a system fault, or heaven forbid, a software defect. This area alone sends most people down the traditional waterfall lifecycle just to ensure not to inject more risk into what could be something that could inflict a great deal of human harm if things go wrong.
In reality, the traditional waterfall cycle did not stop defects from happening--they happened. I know this because I was in the cinderblock reinforced testing labs as we had to reach for a monstrous kill switch that cut power and shut down such systems. What kept all of us safe was a quality mindset that was mixed with some excellent engineering and Q/A methods. This is where we can pick up how Agile fits.
Let's start with the fundamental methods that improve embedded systems. James Grenning's book about Test-Driven Development for Embedded C highlights one of the best reasons for working in an Agile way on Embedded systems. That is the usage of Test Driven Development (TDD) lowers defects, reduces dependencies on needing an entirely built system, and reduces the overall risk of literally a big bang first-time power up of a system. Combining TDD with paired or mob programming also furthers our ability to keep both hardware, firmware, and software quality high by putting more rigger into checking code and design at the time of inception versus discovering the defects in some slow, downstream process later. That, in turn, reduces interruptions to new feature development.
Now that is not without a massive mental shift for how a system feature is developed in an Agile way. Like most engineers, we tend to think about things in units versus a vertical slice of functionality that effects many units and groups of people. We can use methods like story mapping to slice up our backlog into chunks of functionality we want to demo across the complete system. So how we organize those slices of functionality and in what phase in the development impacts our ability to demonstrate high customer value. Let's face it, a demo of a sub unit's input and outputs is not only hard for the customer to see how it fits into the overall system, but it's also incredibly dull. Our goal is to discover early what the customer needs and what excites them.
So at the project level, we can start to use more of an outcome-based lifecycle like the one developed by Erik Simmons and several others of us when we were back at Intel Corporation. nstead of doing a bunch of disjointed work, the team is focused on looking to prove value at each stage in the lifecycle starting with the Opportunity Phase.
With more Agile mindset used in the Opportunity Phase, we ask ourselves questions like, "What does it take to frame an opportunity for our company?", "What needs to be developed at this point to prove my Minimal Viable Product?", "What excites the customer?", and "Is it worth investing?". All of this can be proven with conceptual and early prototyping and some reviews with potential customers.
The cool thing today is that with a few relatively inexpensive 3D printers, laser cutters, CNC mills, etc., we can produce a fabulous looking low-cost functional prototype in days. This means in the Concept Phase we can have several versions of fully functional prototypes that can be scaled to production at a lower cost. We can also reduce waste by not building the wrong thing that either undermines the value of our product or drives up engineering or manufacturing cost as we scale the product to production--all by using the Agile mindset and adapting some of the software methods.
I am going to leave this topic here for now. I plan to expand on how we can use Agile in the rest of our business in the coming weeks.
