In Costs of an Agile Approach for Hardware Products, I suggested that an iteration-based approach for hardware was too expensive. I focused on the actual development costs. Let me talk a little about the team and alternatives here.
What Does a Hardware Team Look Like?
Agile software teams are cross-functional and interdependent. The team is able to create these nice features, through the architectural layers.
The team needs each person on the team to contribute, to get to those features.
Many agile software teams have somewhere between four and seven people. (Yes, I’ve encountered “teams” with more people. See Team Size Matters, Reprise.)
Does your hardware team look like that?
Most of the hardware teams I’ve worked with (inside an organization and as a consultant) have fewer people. The guy who prompted this series is part of a 3-person hardware team.
Those people work independently until they need to verify the product as a whole, works. (Just like software.) However, the difference between software and hardware is the hardware people need to do more independently than they do interdependently.
This hardware team swarms on a product. They need to reconnect periodically. Sometimes, multiple times a day. Sometimes, once a week.
They almost never need a daily standup because they work independently.
A Unique “Agile Approach”
This hardware team doesn’t use a waterfall. Instead, they (and many others in my experience) uses this approach to their work:
They realize the requirements will change, so they spend the least necessary time getting requirements.
They propose a design or architecture. If they have constraints (almost all hardware has footprint or heat or memory constraints), they list them here with the potential design. (They might even use some design-by-contract ideas because they are more independent than interdependent.)
The team moves into prototype-and-simulation.
Once the team has enough features-as-prototypes, they can create some number of prototype hardware. I often see three. You might have more.
Now, the greater product team(s) can marry the software with the hardware. In my experience, this takes significant time, unless someone has had the specific job of downloading the software to the hardware. I’ve seen this first “marriage” take weeks in the past. (This is why I have a deployment person in all my program team images. We need to think about deployment from the start.)
The software and hardware people will learn from the prototypes. Both software and hardware teams might have to iterate on “already completed” work. (It’s not complete. It was a prototype.)
Once everyone gets the prototypes to work, the hardware team can add more features. And, possibly produce more prototypes.
Now, they can iterate over the features. That’s when the team can produce their prototypes.
The “Add more features” part takes the place of iterations in a software team’s approach.
Feedback Loops Drive Collaboration
Software teams need to collaborate as a team to finish small features. And, because they can demo each feature, they might need to reconnect every day if the story/feature takes longer than one day.
What kind of feedback loops does a hardware team need?
When hardware teams use design-by-contract (or something that looks like that to me), the team doesn’t need a daily standup. A daily standup interferes with everyone’s concentration and focus.
The question I have is which feedback loops does this team need? How often? And, with whom?
Here are some possible feedback loops during development:
- As the hardware people iterate over features and they finish a feature with simulations, they can ask for feedback.
- I have not worked with hardware teams who wanted customer feedback during the architecture-decision phase, but I have not worked on custom hardware. (One customer.) One-customer teams might be able to take feedback. (I am skeptical.)
- During the add more features part (which includes simulations as tests), the hardware team could ask for more feedback. This is where the team can ask, “Are we done yet?”
- Once the team gets to pilot hardware, they need feedback from customer representatives, not just internal product people.
If a hardware team uses the feedback loops, they can manage their various costs before they go to physical form.
Hardware Costs Limit Agile Approaches
You can use an agile approach for parts of a hardware product. It depends on the kind of product, and how many times you want to see the hardware grow.
The more you want to see the hardware in physical form, the more expensive the product development will be.
Instead of thinking of an agile approach for hardware, consider how you will create feedback loops. We know shorter feedback loops work for any product development.
Instead of thinking in standups for collaboration, consider how to simulate features, and then demo those features.
This series has two posts:
- Costs of an Agile Approach for Hardware Products
- Create Feedback Loops (Agile Approaches) for Hardware Products
Unless you have questions. Then, it might be longer.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Create Feedback Loops (Agile Approaches) for Hardware Products Opinions expressed by Java Code Geeks contributors are their own. |
