Download as PDF, PPTX
Uploaded byCprime
Understanding Agile Hardware
This document discusses best practices for using agile product development for hardware projects. It provides differences between hardware and software development such as hardware being more difficult to change after manufacturing. It recommends using scrum with a focus on technical stories for hardware. An example project at Thermo Fisher Scientific developing analytical chemistry equipment is described that successfully used scrum. Key lessons learned include the product owner also being a team member, most deliverables being behind the scenes technical work rather than user-facing, and estimation and velocity being more challenging for hardware projects.
More Related Content
Similar to Understanding Agile Hardware
Understanding Agile Hardware
- 1.
- 2. Because our worldis Hybrid… Shift our language from “Agile Software Development” to “Agile Product Development” to cover both Software and Hardware! !
- 3. Some Differences betweenHardware & Software • Software is easier to change than hardware. ! • Hardware cannot be “refactored” after manufacturing ! • Hardware designs are constrained by the need to incorporate standard parts! • Hardware components have much longer lead times for acquisition ! • Hardware design is driven by architectural decisions. ! …!
- 4. Let’s Compare theDevelopment Cycle
- 5. Recommended Scrum Processfor HardwareStory Types: Hard vs. Soft (expect more technical stories)! ! Sprint Length: Recommended 2-8 weeks, but keep standard length through development! ! Release Planning: non-negotiable ! ! Variation of Sprints during Release Cycle Beginning: requirements, architecture, silicon selection! Middle: Repeating sprints of design/build/test! End: emphasis on scale – build/test!
- 6. Agile Benefits Applyto Hardware Too! Improved visibility, predictability, ability to respond to changing business needs, Improved ability to collaborate with software teams using Scrum to develop associated software! !
- 7. But, does itwork?
- 8. YES! We have implementedAgile hardware development successfully
- 9. The Mission: ! Thermo FisherScientific, Inc., is a major biotechnology company that makes a wide variety of analytical and laboratory products, such as mass spectrometers, chromatography equipment, and so forth. They were also our very first Agile Hardware client!! ! We narrowed their initial goal to building a product for analytical chemistry, intended for laboratory and medical use.! !
- 10. The Plan: ! Week 1: ScrumTraining, Write high-level requirements (Epics)! ! Week 2: Draft Release Plan, including estimates for all Epics, Write User and Technical Stories to prepare for Sprint 1! ! Week 3 (first week of Sprint 1): Sprint Planning, Develop and test deliverables! ! Week 4 (second week of Sprint 1): Develop and test deliverables! !
- 11. The Result: This iswhat their FIRST week’s Burndown Chart looked like!
- 12. The second andthird sprints built on the lessons learned over time, and the Team continued to improve.
- 13. Quote from ProductOwner, Dr. Bedford “First and foremost, running this project with Scrum is an ongoing success. The team has formed nicely and we have proper buy-in from each team member. I make technical decisions with more input from the team than any other project that I have worked on. Grooming is a hassle because it takes so much time and requires us to stop doing and think, but the drawbacks I mention are also the clear benefits. We take time to plan. And we plan together. The daily standup is a life saver. As is the board. I can quickly understand where we are and what needs to be done. Release planning has been beneficial because it really focused the team onto what our big goals are as opposed to smaller engineering goals. I feel that management here in San Jose is excited about Scrum. I have had many of the bosses and decision makers stop by and ask about the process. I am curious to see if another team pops up in the near future.”!
- 14. LESSONS LEARNED From AgileHardware Development
- 15. Lesson #1: ProductOwner as Team Member ! The people who would most commonly lead the definition of a product, as Product Owner, are likely to participate as Team members as well. This was indeed the case at Thermo Fisher.! !
- 16. Lesson #3: User-ExperienceInformation may not Lead to many User Stories Each user experience can be considered atomically, and adding many of them adds code to all layers of the product.! !
- 17. The problem isnot that writing requirements for hardware is inherently more difficult than writing requirements for software. ! Lesson #3: Writing Hardware Requirements is Difficult to Learn
- 18. Lesson #4: Muchis Behind the Scenes, Not much is in Front Few of the deliverables for Trailblazer reflected any meaningful user experience, while most were behind the scenes. In Scrum language, there were lots of Technical Stories, and relatively few User Stories.
- 19. Lesson #5: TheProduct Owner Writes Few Stories For Software products, the Product Owner writes User Stories, while the Team writes Technical Stories. These statements are true for hardware development as well, but the shift in Story types means that the Product Owner wrote a much smaller number of Stories.
- 20. Lesson #6: Storiesare Tested by Implementers The deliverable of a Story generally is tested by the person or people who developed it because deliverables vary so widely that they are the only ones who will understand the deliverable.
- 21. Lesson #7: ScopeDecomposition is Component- Oriented, not Functionality-Oriented Greater volume of Technical Stories over User Stories reflects the reality that the natural scope decomposition is into components, not areas of functionality.
- 22. Lesson #8: Time-BasedEstimation is Essential Time-based units, such as Person-Days work well. If the Team cannot develop a consensus norm of sizing that is not based on time, then the concept of relative sizing, and the use of Story Points as units, is not applicable.! !
- 23. Lesson #9: Swarmingis Always Good, but Ability to Swarm is Decreased Swarming is difficult because it depends on certain factors. The scope of the Story must be large enough for the work to be decomposed into pieces for multiple people to work on it. Also, the skill sets of Team members and types of work required for the Story must be such that two or more people can work on the pieces at the same time! !
- 24. Lesson #10: Rankingis Important, but not Literally Achievable In Hardware development, Stories are can be implemented by only one person on the Team. Thus more Stories are likely to be in process at any one, and unforeseen issues or disruptions are more likely to cause some Stories that have been started to not complete in the Sprint. !
- 25. Lesson #11: VelocityMatters, but is not Definitive Velocity is less definitive as a planning tool in Hardware development. Stories are often one-person exercises, so we must pay much closer attention to how loaded each person on the Team is. It is easy to select a Sprint Backlog that satisfies the Velocity limit, but which overloads some people and leaves others idle. ! !