Chad LS3

Chapter 9: The chapter starts with an example of stuffing envelopes in large vs. small batches.  For what reasons does Ries say the small batches are more efficient?

The main reason that small batches are more efficient is that errors are identified before the quantity of affected product is significant.  For our team, the small batches are really design changes.  It is much easier to trouble shoot a non functioning product if a limited number of changes has been made since the last test.  Similarly if the product is related to outreach, the best way to measure the effectiveness of an approach change is if small batches are used.

Chapter 9: Both small batch examples (SGW and School of One) should feel somewhat familiar as roboticists and as students.  What do you see in these stories that we don't use at school / in robotics?

The interaction of the drivers, designers and programmers should be more focused on the robot so that a feedback loop can more quickly be made.  The use of MVPs and virtual design reviews would allow the team to iterate both in quick "iron" and also virtually.    The virtual reviews could make programming more efficient because a small cross functional batch of work is being produced at once.

Chapter 10: Shift your focus from building robots to growing our team of students, mentors, parents, and sponsors.  What is our team's engine of growth?

Word of mount is our team's engine of growth.  Students hear that it is a fun learning (and a lot of work) program.  Parents hear about how the students are learning to work in multi-functional teams.  The key to a balanced word of mouth engine of growth is to continue to improve the teams skills in areas other than design and programming.

Chapter 11: Explain the purpose of the "Five Whys" technique for root cause analysis.

The purpose of the "five whys" is to continue to drill the analysis of the problem to a deeper level.  The early questions reveal symptoms of the root cause.

Overall: Let's say our build team's customer is the drive team.  Our design process usually involves creating and perfecting the robot as much as possible before giving the customer a couple days to use our product (and virtually no time to suggest changes after use).  What could we do to get our customer some kind of product sooner?  How could we learn from our customer and use their feedback in the design?

Getting an MVP built from a variety of materials as quickly as possible is the key. Wood, metal, cardboard, plastic. designed parts built in a day, what ever it takes to get something started quick.  While the MVP build is going one another portion of the team can develop an obstacle course test.  Even if it is only a representative task of the competition, much could be learned.  The test would need an objective measure so time to complete or points scored after so many practice runs could be used to measure improvements.

End with a summary of what you learned.

The "Five Whys" was a great take away for me.  In industry we get caught up in much more complicated root cause analysis.  Where as the "Five Whys" may be more difficult that it seems it is basic and can be quickly complied.