We are at the beginning of the re-rise of tangible products, when the problem of unifying development lifecycles is fast becoming the biggest impediment of innovation. On one hand, speed can kill, and one should remember the importance of process for hardware- At the top of the list of challenges often faced by hardware Scrum teams is a demand for time. For one thing, delivering a functional piece of hardware to the customer after each iteration and then adapting the design to the customer’s changing specifications increases the cost of a project dramatically. When traditional methodologies often involve much less financial risk. A lack of modularity also makes it difficult to use Scrum: hardware often doesn’t have the modularity that makes dividing projects into small increments possible. But on the other hand - faster iteration flows to accelerate hardware development. Agile methodology makes it possible to improve upon an original hardware design without significantly increasing spending and time required. Agile’s positive, team-focused values create freedom to make mistakes, fostering more healthy risk-taking, less blame-shifting, and more reward in the long run. Are you up for this hard(ware) challenge? This talk will be all about rapid iteration with hardware: the Dos and the Don’ts, on how to do a series of hardware build-test-feedback-revise iterations and then continuing the cycle once again.

1. Don’t be too hard for agile;
How to go lean with hardware

2. I am Moriya Kassis
Hello!
Product Management Consultant for hardware
& IoT companies,
and the Founder of the biggest PM communities
in Israel &

3. Why is this ME standing on this stage
and talking about this subject?

4. “
We are at the beginning of the re-rise of
Consumer Electronics, when the problem of
unifying development lifecycles is fast becoming
the biggest impediment of innovation.

5. Agile = Decision Model

6. Are you doing the right product?

7. Are you doing the right product?
Are you doing the product right?

8. Agile methodology makes it possible to improve
upon an original HW design without significantly
increasing spending and time required.

9. The Don’ts:

10. Don’t talk SW with
your mouth full of HW:
1
Get ready to learn some new techniques and try
to enjoy leaving your agile SW experience aside

11. Don’t have MacGyvers
in your team:2
Developers should work in pairs to reduce the
time needed for training and documentation.
Mix the firmware and the hardware geniuses to
work together

12. Don’t forget the
certifications:3
Make sure to get started on necessary
certifications early, and skip the nice-to-haves

13. But it’s easier to tell you what not to do, than...

14. The Dos:

15. Finite Iteration:1
Break down the elements of your separate
prototypes further, and iterate on the most
discrete units of functionality that you can.

16. Do a majority of the people you ask to play with
your prototype tell you that the button is awkward?
Getting buttons with the right click-feel is one
discrete element to iterate on.

17. A digital

18. A digital
or a physical component?

19. What shape of a button?

20. What shape of a button?

21. Do a majority of the people you ask to play with
your prototype tell you that the button is awkward?
Getting buttons with the right click-feel is one
discrete element to iterate on.
Button placement is another one.

22. Button placement is another one.

23. Button placement is another one.

24. Button placement is another one.

25. Separate Prototypes:2
Make 2 different objects -

26. Separate Prototypes:2
Make 2 different objects –
an ugly black box ‘works like’ prototype,

28. Separate Prototypes:2
Make 2 different objects –
an ugly black box ‘works like’ prototype,
and an entirely non-functiona‘l looks like’.

30. Re-define the term
demo-able component.
Every single time:3
An iteration is a product version somewhere
between a “virtual product” through to a “ready-
to-trial prototype”

31. Similarity to
the final
component
actual
subsystem
Ease of
development
Spectrum of options for a subsystem

32. Similarity to
the final
component
actual
subsystem
Ease of
development
Spectrum of options for a subsystem

33. Spectrum of options for a subsystem
Similarity to
the final
component
actual
subsystem
Ease of
development

34. Similarity to
the final
component
actual
subsystem
Ease of
development
Spectrum of options for a subsystem

35. Fast Over Fancy:3
There will always be newer-faster-better
tinkering toys, and you can spend forever
researching them. Instead, find things that work
and use them to build a functioning prototype.

36. “
People care about whether you’ve
made something that they want

37. Make tradeoff:4
To be able to plan after you demo’d the previous
one, make tradeoffs in terms of:
 Frequency of Integration
 Depth of integration
 Fidelity of feedback

38. Any questions ? Moriya Kassis

39. Now go and break things.