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?
Ries claims that small batches are more efficient because they allow for early reaction to problems. In the envelope example if something were to go wrong such as cards not fitting, you wouldn't know till the end and it would take a long time to fix it. Small batches are also useful because they are easier to adjust when a new need arises.
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?
Our teams engine of growth is a sticky one. We are dependent on getting and retaining members to make our team function. The retained members, both adults and kids, teach the new members and help keep our team going. We display a few aspects of a paid engine through our demos, but as a whole we are trying to make the team work best for those in it to keep them in it.
Chapter 10: We also lose people (students, mentors, parents, and sponsors). What things cause this to happen? Which of these can we control?
In my opinion there are three major things cause us to lose people. A lack of time, feeling of non-involvement, or change in location (graduation, moving, etc) all cause us to lose people. We can't really control how much time someone has available, but we can make their time as useful as possible and keep them as involved as possible. We can control how involved someone is in our team through keeping them up to date in absence, including them in key decisions, and quite a few other things. The only aspect we can't influence is people moving to a different area.
Chapter 11: Explain the purpose of the "Five Whys" technique for root cause analysis.
The five whys are designed to uncover all the levels of error including the original cause. They are meant to find everything that went wrong in a chain and then discover what started the reaction to try to prevent it from happening again. This allows teams to try to fix the root problem and deal with other systems which are dependent on said problem.
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?
We could give the drive team individual parts of the robot to see how they work before assembling the whole robot. A drive base with some weights could have taught us a lot about how our robot would handle long before we ordered our final piece, but would have been relatively easy to mock up and adjust. The same thing applies to other mechanisms; if the drive team has a chance to test the prototypes in a semi realistic situation rather than just hearing "we'll make them work before the regional" they could provide feedback on what about them they like and what about them they don't like.
In these chapters I learned what the different engines of growth were and the ways of measuring each one, how the simple question "why" can be used to find the root cause of a problem if looked at correctly, and the difference between small and large batches. What can be taken from all of these things is to always look at how you are attempting to grow and try to achieve it in quick small increments. If this is done, problems that are found can be id'd and fixed efficiently reducing waste in the process.