I keep hearing the need for "Growth Mindset," "Collaboration," "Empathy," etc. while describing the characteristics…
This challenge was taken on by the Medical HW manufacturer Optinova in August. Over the course of two days, we pushed the limits of “what is possible” by applying Agile in a HW environment.
Our hypothesis was that Agile would be a good fit in product development and innovation scenarios. And the result so far from the work that we have been doing with Optinova is promising.
Cross-functional teams, focus, rapid prototyping, close customer feedback and visual overview work just as well in hardware as in software. The training setup we used was as follows:
- Day 1 – Learn basic Agile practices and principles
- Day 2 – Applying them – developing three product ideas from scratch in one day, in a rapid prototyping workshop.
The result: All three participating teams managed to take an idea to working prototype in a day. One team went so far as submitting a bid to a real customer the following day based on their prototype. That’s high speed, even in software terms. But the most important thing wasn’t the result, it was the lessons learned. When we asked the participants if they wanted to continue to build products this way, the votes were unanimously in favor. If we can get it to work, this would help build a competitive and innovative company.
This is what the teams said that made them fast:
- Cross-functional / cross-department collaboration
- Experience in the field
- Prototype often
- It’s ok to fail!
Ok, that seems pretty logical. The more interesting question is: how often does this actually happen on a regular work day?
Here are the more unexpected findings during the rapid prototyping workshop:
- Most teams dropped sprints in favor of regular stand-ups, Kanban and shared designs during the day. One obvious reason was because the sprint lengths chosen by the teams were too short to produce anything worth demo-ing.
- When the teams started to produce designs together, it was no longer necessary to have updated post-its. My take on this is that the team needs to get an overview of what needs to be done, and in what order. If they can accomplish this in a simpler way than using post-its, then so be it
Note: Being process compliant was an explicit non-goal during this exercise. We gave the teams quite a bit of slack to find a way that worked for them, but stayed close to pick them up if they hit a dead end.
Cross functional team experimenting in Lab
So, we can tell you that using Agile in Hardware, especially in product development scenarios actually works!