Monday, July 13, 2015

Ben L3

1. 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?
                 Small batches make mistakes easier to identify and quicker to fix.
2. Chapter 10: We also lose people (students, mentors, parents, and sponsors).  What things cause this to happen?  Which of these can we control?
                We lose people through loss of interest,negative experiences, or the feeling of not having enough time to commit to the program. Ways to fix these issues would be reassuring the abandoners that they don't have to give up every weekend for robotics, that schedules are extremely flexible. We can try to show them the fun in robot design, though if they just don't have the heart for it, there's always media or finances, or public rapport that could be worked on.
3. Chapter 11: Explain the purpose of the "Five Whys" technique for root cause analysis.
                The purpose is to look for the main source of any issue. This is accomplished by asking yourself why something happened, then asking why that in turn occurred, so on, so forth.
4. 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?
                The clear answer is to give them the unfinished robot; let them play with it. They will tell the build team what they love and what they hate, from there, build team will know what needs work and what is fine just as is.
5. Chapter 11: Explain what Ries means by the "Five Blames".  What things help prevent root cause analysis from turning into a blame game?  What is the role of the "Five Whys Master"?
               Five Blames is when people focus on the faults of each error, instead of learning from them. They simply want to blame others for errors made. Don't focus on who each error spawned from, but why they happened and what can be done about it. The master's role is to prevent the Five Blames from occurring.
               Producing and testing small batches at a time is efficient, as is the 5 why's. Building a stronger and larger team helps us combine brainpower toward solving an issue, resulting in better efficiency. Don't get hung up on fault, when it's easier to find a solution.


  1. You said "We can try to show them the fun in robot design, though if they just don't have the heart for it, there's always media or finances, or public rapport that could be worked on" This is a good point. We have to be careful to make sure that non-robot activities are not considered secondary. The I and R in FIRST stand for Inspiration and Recognition, and the other activities are key in making that kind of thing happen.

  2. I for sure agree that the cross functional team needs to be seen (because it is) as a team of equals. What caught my eye on this post first was unfinished bot. As we work to release small batches, the entire team needs to see the unfinished bot as a completed set of tests to run. Then the sum of the small batches leads to a product ready for competition. Notice I refrained, with the backspace key, from saying finished. Products are never finished, just ready for production.