Kaitlyn 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?

Answer: If the letters didn't fit in the envelopes they might not know till the end of a large batch but if it is a small batch then you can detect it earlier. The small-batch approach produces a finished product every few second, while the large-batch must deliver all the product at once.


Chapter 9: "Hardware becoming software", "Fast production changes", and "Rapid prototyping tools" are all things that could help us build a robot more quickly.  Give an example of each of these 3 that we could do.

Answer:
Hardware becoming software-cad the materials we would like to use then when we might have an idea we can put the parts together on the inventor.
Fast production changes-use different materials, cad stuff near the beginning and change when need too.
Rapid prototyping tools-Doing what every we are prototyping we have it as a different material so it will be here faster. And then if there are flaws beside the type of material then it would be faster to know and figure out the problems.


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?

 Answer:Students that join are most likely interested in something with STEM or want to do something that really isn't a sport. But everyone is different so for each person it can be different. Our growth is when new people come and also the people that we on the team last year or previous years.


Chapter 10: We also lose people (students, mentors, parents, and sponsors).  What things cause this to happen?  Which of these can we control?

Answer:People graduating, some might want to wait till one of their children are in robotics to help, don't have the time to be able to help. For sponsors we might lose them because they can't give anymore or they don't think they don't want to anymore. We can control some but there are also a lot that you can't. But that is why each year we get new people because they have come to help us when the students that graduated can not anymore.

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

Answer: To the prevention of the most problematic symptoms. It is also when you are confronted with a problem, have you ever stopped then asked why five times. By asking why if can help uncover the root problem and correct it.


Summary:
When stuffing envelopes you have to decide which way is faster. Like in the book doing small batches can help you find problems faster that you would in large batches. I also think the "Five Whys" could be helpful for us because it could help solve some problems that we have and make things go a little more smooth.

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.

Summary

               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.

         

Jacob 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?

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.

• Summary

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.

LS3: John

·                     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?

• Problems with the entire process are discovered and corrected early (mis-fit envelopes, sealing problems.)   There is less overhead by avoiding the need to manage large piles of in-process inventory.

·                     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?

• I would say we have a combination of sticky and viral growth.   Most students ‘stick’ at least until graduation, but we’ve also seen some that stick beyond that as they stay involved in FIRST and come back to mentor.  We also have some viral growth, (but probably not > 1.0) whereby as we have more and more students involved, they help recruit other students
• In regard to sponsors, it is critical that we have ‘sticky’ growth there, and retain sponsors from year to year without losing them. 

·                     Chapter 10: We also lose people (students, mentors, parents, and sponsors).  What things cause this to happen?  Which of these can we control?

• As mentioned in the previous answer, we lose students through graduation.  We lose mentors in some cases for similar reasons, if their commitment is primarily based upon helping out where their kids are invested, rather than being fully invested ‘on their own.’   Some mentors start out because their kid is in the program but then stay with the program even after the kid(s) are no longer participating (usually due to graduation.)

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

• The goal is to get to root cause of why something undesirable happened, and to avoid just ‘patching’ the system.   A pre-match and post-match checklist is often a great way that problems once encountered are avoided in the future—by enhancing the ‘process’ of competing, we avoid the same mistakes, whether they be as simple as assuring a fresh battery is in the bot or something more complex, like making sure the lifter is at the correct starting position and that code is deployed and operational. 

·                     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?

• Here’s a wild idea—sort of longer term—drivers get very little experience with our own robot(s) due to the constraints of our limited build time. What if we sought out, during off season events or even a special purpose ‘meetup’ where we brought together multiple teams with their robots and had teams swap bots and drivers (with some how-to driver training) so that our team was exposed to a much larger set of drive experience possibilities.   We might hear things like “Team 1234’s bot was so easy to drive compared to ours, we need to understand how to program our drive system in a similar way as they do.  Or we may here things like— “4859’s bot is so simple to operate, instead of having all sorts of manipulator controls, they just have up and down – and it does everything.”

·                     Summary: 

• A key take-away for our team that I learned is that we have lots of opportunity to enhance our relationship with our sponsors and get even more value from them.  For example, we could build a small survey asking our sponsors what motivated them to contribute to our team vs. sending their donations elsewhere vs. not donating at all.  Was it because we build cool robots and they are intrigued, because we had students presenting and soliciting?  Was it the goals of the program?  Was it so that their name would ‘get out there’ by being on the bot/t-shirt/web-site?
• I’ve also considered pitching to sponsors that they can help out via 1) Money, 2) Materials, 3) Services, 4) Providing mentors/advice.   I now realize that they can also provide another very important service– they can help recruit other organization as mentors, if we provide the tools for them.  It was clear at McNeilus that they were setup to give tours to customers and prospective customers.   While many of these customers are likely distant geographically from Byron, providing McNeilus with a low effort way to tell them about their involvement in FIRST and a direct way for those customers to find teams local to their locations would be a great way to expand FIRST to other sponsors.  If McNeilus could tell us “Company XYX from Topeka saw the picture of your team and robot and seemed pretty interested” we could contact the FRC teams in Topeka and tell them they might want to ‘strike’ while the iron is hot and try to sign up a new sponsor.  If we were to devise a world wide mechanism and game plan to get a large number of FRC teams to do this with their primary sponsors, then there would be a viral effect that any person/company visiting a strong FRC Team sponsor would turn into a ‘sales lead’ for that or another team.

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.

Nate 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?
• Small batches are more efficient because you can recognize problems quicker and do not have to organize the letters after every step.  This allows less time between each step and mistakes are known immidiatly so you will not have to backtrack.
• 
  
• Chapter 10: We also lose people (students, mentors, parents, and sponsors).  What things cause this to happen?  Which of these can we control?
• This happens by a few things like graduation, moving, and disinterest.  The only one we can control is disinterest.  We can keep people interested by finding ways for everyone to be a part of the team.  If we can get everyone to enjoy being on the team, people will not want to quit the team.
• 
  
• Chapter 11: Explain the purpose of the "Five Whys" technique for root cause analysis.
• The "Five Whys" technique is used to find the root cause of a problem.  This is dome by getting to the problem that the person so it can be fixed, not just scolding the person and hoping it doesn't happen again.
• 
  
• 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 someone incorrectly uses the five whys.  This happens when, instead of thinking past the person's mistake, they tell the person it is their fault five times.  The master is used to ensure this does not happen.
• 
  
• 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 have them test each feature as it comes out.  This would allow them to see a problem immediately, and then it could be fixed quickly.  With this we could get a great robot quickly.
• 
  
• End with a summary of what you learned.
• I learned that it is better to produce one product at a time and to test one hypothesis at a time.  I also learned we need to work to grow our team so that when we lose people we have more strong teammates to fill their places.  Also, it is best to not blame people, and figure out a more simple reason to why it really happened.  With these steps we can build our bot more efficiently and make it better.

LS3 Bryan

• 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 says it is more efficient because if you were to do 100 at a time, you would first have to sort everything and then start the process, but if you were to do that the 1 batch at a time group would already be done.

• Chapter 9: "Hardware becoming software", "Fast production changes", and "Rapid prototyping tools" are all things that could help us build a robot more quickly.  Give an example of each of these 3 that we could do.

For Hardware becoming software we could simply use some of the many unused buttons on our joystick to do simple tasks for the robot. For example, we could use it to do a quick 180 turn or if we are in a position that we are in a lot of the time we could just press a button so then we could just finish the task without having to keep doing the same thing. For fast production changes we could have some people quickly do cad models and prototyping to find flaws in the designs by using the materials that are sitting in the robotics room and also have people ready for fall back ideas in case the specific design is too flawed. For rapid prototyping tools we could make use of the scrap metal and wood we already have instead of having to make a cad model and send it to Mcneilus steel. I don't know if we did that all of the time, but we could simply just use the scrap metal and wood that is just sitting there.

• Chapter 10: We also lose people (students, mentors, parents, and sponsors).  What things cause this to happen?  Which of these can we control?

Some things that cause people to leave are moving, graduating, and simply just not wanting to be on the team. Well some things that cause these things to happen are fairly simple reasons like getting a new job, or doing well in school, or just not liking the people on the team or not liking the sport. We can control the graduating not wanting to be on the team by not letting people graduate. No just kidding, but we could have the graduates able to mentor our team the next year after they graduate. We could also be very welcoming to new people and show them things on our team.

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

The purpose of the "Five Whys" is to find the initial cause for something. To perform it you must ask yourself "Why" five times..

• 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 simply let them use a robot that is nothing close to the final design and have them suggest things about how we should fix it. We could ask them what they think of it and what they want on the robot and do what they want.

Summary:

I have learned that we must question ourselves to learn. We must also get other opinions from other people. We also don't have to do the same ideas as other teams. For example, many teams don't make hardware software, we could do that. We also don't have to rack our brains for complex solutions when we can just fix something with the easiest. "The best solution from a problem is usually the easiest one" -Glados.