Nate SC2

Chapter 4: Sutherland required his first scrum team to throw out all titles.  Why?  Where (inside and outside FRC) have you seen titles get in the way of getting things done?  Where can titles be a positive thing on a team?
Titles can cause people to abuse power and can slow work down.  A manager guides a group, but they take a bit of the employees voice away.  In our team waiting to check with a mentor or team lead has caused us to delay getting things done.  That being said, a title ca mediate between different ideas if there is a split in how something could be done.

Chapter 4: The daily scrum should be "closer to a football huddle [than individuals reporting out]".  Explain why.
A football huddle is a way to let everyone know what is going on, and the goal you have as a team.  In a football huddle most people will have different jobs but all be working towards the same goal.  In this technique everyone is up to date on the plan for the day, and everyone has a job they can do.

Chapter 5: Why is multitasking wasteful?  When in your own life do you refuse to multitask and just focus on a single task?
Multitasking is wasteful because you can't focus well on multiple things at once.  Multitasking does not get things done faster, it usually takes longer and produces a lower quality product.  In my life I always refuse to multitask.  I find focusing my energy on one thing to be much more efficient and effective.  The closest I get to multitasking is switching periodically from one assignment to another when I get stuck so I can come back with a fresh perspective.

Chapter 5: One section is titled "half done isn't done at all".  What are some half-done tasks we have with our FRC team?
Well, this course is halfway completed.  I can't think of any we currently have half done.  But we do have a tendency to start something and not finish.  This is a problem because we forget how far we were and many times have to restart.

Chapter 6: Explain how planning poker is supposed to work.  Mention the halo effect, Fibonacci numbers, who should play it, and the discussion that should occur when estimates vary too much.
Planning poker is a way for people to more accurately decide what tasks are most important.  It allows for an accurate estimation and uses the Fibonacci sequence because menial tasks do not vary in difficulty much, but strenuous tasks can vary more greatly in difficulty.  It eliminates the halo effect of people automatically siding with a person.  The people who play it should be those who are familiar with the tasks and can justify their reasoning accurately.  If there is too great of a difference the highest and lowest numbers should explain their reasoning and everyone repeat the poker hand.

End with a summary of what you learned.
I learned the importance of organization during work.  It is needed to efficiently complete a task.  Prioritizing tasks allows for work to be done in a sensible order, and it organizes work in order to eliminate inefficient multitasking and less important jobs.  We do not necessarily need to work at robotics for 10 hours a day and go to school.  If we use our time wisely and recognize when we are being inefficient we can get our work done much faster.  Skills from this book can help our team a lot.

Braxton SC3

Chapter 7: How does our team do a good job of supporting autonomy, mastery, and purpose for each person?  Where does it fall short?

Our team supports autonomy for its members by allowing everyone, more or less, to participate in discussion about how to build or design a part, what design our logo should have, etc. Anyone can be on an independent team or group that decides how to go about a task, and they can provide vital input on that team. Mastery is supported by the same system, as people can do any job they want, as long as they want, at least in theory. They can work at crimping wires until they have carpal tunnel, or they could CAD until they collapse from exhaustion. Purpose even falls into the same system. However, these are only in theory. At times, like the corporations of old, we can be highly divisionalised. Sub-teams and sub-sub-teams can oftentimes have their one culture and codes, putting up hypothetical barriers between each other. However, this problems is not as bad as it could be, but there is still room for improvement. 

Chapter 7: How does our team do a good job of being transparent?  Where is it opaque and unclear in its workings?  Be honest.

One of the best things our team does in terms of transparency is the team's shared folder of info. Anyone on the team can look at our financials, our survey results, our award documents, team lists, and more. Anyone can attend our meetings (most of them, at least), and offer input on how we should proceed. We all know what tasks need to be completed, and we fill in those who don't and they can look at our scrum board to see who is working on what, what's done, what needs to be done, etc. However, our team isn't ideal. Only a few of our documents in the shared folder are up-to-date, and a few are hidden in endless trains of files. I suppose if one wants to know out of date mid-season financials from 2014, or team member lists last updated 3 years ago, then these docs are for you, but otherwise, sometime in the next few months, there should be a widespread effort to update or purge the documents in there, and then organize them better for easy access. We also sometimes have problems with keeping on scrum board up-to-date at times, since its all the way down in Pethan's room, but that's only a small issue. All in all, our team is pretty transparent, but there is, as always, room for improvement.

Chapter 8: A product owner needs to be knowledgeable about the domain, empowered to make decisions, available to the team, and accountable for value.  What specifically are we looking for in a product owner for a FRC team?  Do we need more than one?

In an FRC team, we're looking for many of the same traits. For example, the product owner needs to be knowledgeable bout the tasks necessary for the robot and the team, not only knowing what they are, but also why we need to accomplish them. They need to use this knowledge to create a sizable backlog for us each sprint, and to, long with the scrum master, set up the meetings and clearly explain to everyone the situation with the sprint, what we need to do next, etc. They also, obviously, need to be available to the team. As for needing more than one, it's possible, but I'm going to say no. However, we don't know until we try during a sprint.

Chapter 8: "Prioritizing everything is prioritizing nothing."  What do you think are the five highest priority items for our FRC team?  Put them in order 1-5.

1. Having a functional bot by competition
2. Having a working understanding of the year's game, and how to coordinate strategy with alliance mates
3. Securing sponsorships and funds through various channels
4. Submitting a finished chairman's appliction for 10 points in the state rankings
5. Submitting other award applications, finished of course

Chapter 9: Summarize one story from Chapter 9 and explain why it gets you excited about using a proper implementation of scrum with our FRC team.

The Valve story: Gabe Newell and his compatriots in Microsoft left after there were problems relating to Gabe's team structure. They left to form their own company, Valve. The new company had a flat structure and often used scrum to create their products. Nowadays, Valve is known for products such as Steam, Counter Strike, and Half-Life, wildly successful in the gaming market. This gets me excited about scrum because I use Valve products such as Steam and Counter Strike, not knowing they were the product of scrum, or that the company that made them had an extremely flat corporate structure. Now, Valve isn't perfect, but it's products are oftentimes high quality, and so a process that has worked for them, as with so many other, could work for us, and that's why this story got me excited to use scrum on our team.

End with a summary of what you learned.

In this book's final section, I learned bout some of the key aspects of scrum, such as prioritization, transparency, and autonomy. These are extremely important aspects of any scrum team, and implementing them is crucial to any successful team.

Kaitlyn SC2

Chapter 4: What is the purpose of the sprint?  What are the rules that govern a sprint?

Answer:To find things that cool and that can be built fast. Rules are that if the demo wasn't both working and cool, the lab directors killed the project.

Chapter 4: Sutherland required his first scrum team to throw out all titles.  Why?  Where (inside and outside FRC) have you seen titles get in the way of getting things done?  Where can titles be a positive thing on a team?

Answer:Because if people have a special title, they tend to do only things that seem a match for that title. And to protect the power of that role, they tend to hold to specific knowledge. Jobs because if you have a higher status then a new person you can do more and can maybe get away with something. Different sub teams on robotics teams. They can be positive because it can show which person you can ask if you need help on something. Or to show what person is able to do.

Chapter 5: One section is titled "half done isn't done at all".  What are some half-done tasks we have with our FRC team?

Answer: When we were working on the chairman's award, we had some done but when we got close to the competition we worked on it till we pretty much had it done.

Chapter 5: We're used to the idea of a hero working extra hard to save the day.  Why does Sutherland hate on the hero?

Answer: That a team that depend on regular heroic actions to make its deadlines is not working the way it's suppose to work.

Chapter 6: What does the "Definition of Done" mean?  Why is it critical that the entire team understands the DoD for each task?

Answer:When the conditions needed are met and that it passes the tests needed to pass and to say that is is done. They all have the same task that they got to complete and they all have the same requirements.

Summary:
I learned that are easier ways to get stuff done without wasting to much time or money. Also when doing multi projects at a time, it takes longer to complete and and loss to context switching increases per project. I also like how they have sprints, which is an interesting challenge but it can also create cool things too.

Bryan SC2

• Chapter 4: What is the purpose of the sprint?  What are the rules that govern a sprint?

The purpose of a sprint is to have a brief amount of time in which the team or group is extremely productive. A rule is that the amount of time has to be limited and it has to have tasks assigned to specific people or groups of people.

• Chapter 4: Sutherland required his first scrum team to throw out all titles.  Why?  Where (inside and outside FRC) have you seen titles get in the way of getting things done?  Where can titles be a positive thing on a team?

It was just getting in the way of working because they just marked the person. This way they would be more productive rather than pulling the "I'm the boss" card. I have seen people on our team and other teams saying that since they are the whatever captain they get to control the work being done in that specific group of people and just end of not doing any of the work. Titles can be use for getting scholarships as well as being able to compete. Well, we need a safety captain due to ya know, safety as well as being able to participate in competition.

• Chapter 5: Why is multitasking wasteful?  When in your own life do you refuse to multitask and just focus on a single task?

Multitasking is wasteful because you don't do as good of a job when you are doing multiple things at once. If you just do one thing at a time, then you can get it done faster and better. Usually, I try to multitask as much as possible and it usually turns out well, but I know that if I focus on one thing it will turn out better than both things at once.

• Chapter 5: One section is titled "half done isn't done at all".  What are some half-done tasks we have with our FRC team?

Well, we had the Best Buy grant which I am pretty sure never even got done in time, but I could be wrong (this is just from what I heard). Also, we had the chairman's presentation maybe half done for a long time, until the night before the presentation, which should've been done way earlier. 

• Chapter 6: What does the "Definition of Done" mean?  Why is it critical that the entire team understands the DoD for each task?

The "Definition of Done" means something has been thoroughly examined and tested and is able to be handed over to the customer or consumer for use. It is critical that the team understands the DoD for each task so we can get it done to the same standards as we need, so someone doesn't finish it when it really isn't finished at all.

Summary:

This part was to explain parts of scrum and how we should use them. They are very important parts of scrum and should be looked at as such.

Jacob SC2

• Chapter 4: What is the purpose of the sprint?  What are the rules that govern a sprint?

A sprint is a period of time in which a team set's aside a number of tasks to be completed.  At the end of the sprint the team evaluates what happened adjusts and repeats.  A sprint is meant to get a lot of work done in a short period of time and is governed by the tasks/stories that have been laid out for it and the amount of time it takes.

• Chapter 5: Why is multitasking wasteful?  When in your own life do you refuse to multitask and just focus on a single task?

Multitasking is wasteful because you lose time switching back and forth between tasks.  Actually multitasking is really just juggling between two things and the brain just isn't equipped to do this.  I refuse to multitask whenever I do homework since if I get distracted I tend to stay distracted for a long time.

• Chapter 5: We're used to the idea of a hero working extra hard to save the day.  Why does Sutherland hate on the hero?

I'm not sure that Sutherland hates people who act as a hero, but rather the fact that they have to.  If a hero is needed to finish the project on time then obviously the team isn't doing it's job right.  There is also the fact that a hero is a single person and Scrum is all about improving on the team.

• Chapter 6: Explain how planning poker is supposed to work.  Mention the halo effect, Fibonacci numbers, who should play it, and the discussion that should occur when estimates vary too much.

Planning poker is when people use cards with numbers from the Fibonacci sequence on them  to try to rate the difficulty of a task.  It is designed to be quick and to avoid the halo effect of someone seeming like they know what they are talking about and everyone thinking themselves wrong.  Each person lays down a card with one of the numbers and as long as they are all within one of each other they are averaged.  If they are not, the high and the low each explain why they think theirs is correct and the cards are played again and averaged.

• Chapter 6: What does the "Definition of Done" mean?  Why is it critical that the entire team understands the DoD for each task?

The definition of done refers to what needs to be accomplished for a task or story to be considered complete and moved out of in progress.  This is critical, because if definitions of done vary, one team member can think a task is done, mark it as such, and move on to the next one.  This is a problem because a task that isn't done to the set specs may not work when it is needed.

• Summary

This section of the book covered quite a few aspects of scrum including planning poker, sprints, DOD, and others.  It also covered how to enact these and why they are used.  

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

You know almost immediately if any problems occur in the process as well as in large batches you waste much more time sorting and organizing the different segments of the process. 

• 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.

Hardware becoming software - This has already begun on our team but using CAD to prototype concepts, something we haven't done within CAD however that could rapidly speed things up is designing using parametric constraints which I could explain in person or using a computer but I don't know how to explain here... basically setting CAD dimensions equal to other dimensions so that if you change 2-3 base dimensions the entire object will update to the proportional size (would only be useful sometimes but would save a lot of time when it is).

Fast production changes - If we designed a robot to be flexible to multiple ideas beforehand it would be much easier to adapt quickly.

Rapid prototyping tool - If we build a protobot extremely early in the season and are able to rapidly develop (go through bml loop) it our final robot will be much better as a result.

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

They use a feedback loop much more often in their businesses than we do in school or even robotics.  And they are able to work more effectively because of it.  They use their feedback as soon as possible to reiterate sooner.

• 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 team has a sticky growth engine, we rely on getting members and retaining them.  In our specific case next year acquiring people will be more of the problem than retaining others, but in following years retention will become more important as many of the people who were in FLL will join us at least for 1 season and its up to us to make their experience good.

• 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 for a variety of reasons which only some of we can control, we lose people to things we cant control such as them moving (can't control) , others we can such as them having a bad experience or commandeering too much of their time (can control).  Sponsors might stop funding us because we don't show appreciation enough (easy to control), or because it just doesn't work for them (can't control).

Kaitlyn SC1

Chapter 1: Sutherland explains the 80/20 rule: 80% of the value often comes from 20% of the work.  In the last year of FRC, what were some of the 20% jobs that added tremendous value to the team?

Answer:What added tremendous value to us was the lifters and the cams. With them we were able to lift and stack totes and bins and drop then off to score points.

Chapter 1: At the end of every sprint (2 weeks in this case), the Sentinal team presented a working demo to stakeholders across the FBI.  Why is this necessary and important to do?

Answer:It can help how long something could take or How many work items they can get done during the sprint. Helps give info that could take longer with the how FBI, but when they let a  few do it then it could take less time and get the results quicker. They can also test things that might not happen now but could eventually, like someone hacking into the FBI and starts to transfer money to a different country, they were able to stop it.

Chapter 2: "OODA (Observe, Orient, Decide, Act)", "inspect and adapt", and "PDCA (Plan, Do, Check, Act)" are all getting at the same core idea.  Explain this idea and how it relates to the way a team functions.

Answer: We observe what area we would work best then we would figure out a way to make us gather stack things faster. And if something goes wrong just do what you think could be best at that time.
 We make plans then when we are ready we do or build it when we have built it we check if it is good enough then we act and do our best.

Chapter 2: Explain how we would implement the paper airplane example to practice a OODA cycle at a team meeting.  What would be the point?

Answer:Before doing things we observe what we are going to do. We will then orient it and decide what will be done. After that they we will act and work on it. See if the things will work or 

Chapter 3: What evidence does Sutherland bring up when justifying a focus on team improvement over individual improvement?  Do you think that should apply to our FRC team?  In what cases does it not?

Answer:Managers. I think it could help because people how haven't been in robotics or are still a little new they could learn from the people who are managers. But it also wouldn't work because sometime teams or places don't need a manager but everyone has a part and they can all help and teach each other.


Summary:
It think book will give us and myself good advice that we could use at robotics but not only that but other places too. This can be very helpful, when doing something because it might take less time to do then you might of  thought before. In the book it also says studies that they have done and have worked. This could help everyone and help reduce the time that is needed for somethings and get them done faster.

Jacob SC1

• Chapter 1: Sutherland explains the 80/20 rule: 80% of the value often comes from 20% of the work.  In the last year of FRC, what were some of the 20% jobs that added tremendous value to the team?

We had a few small items that had huge impacts on our bot including the cams, the slants on the guide rails, and a few other things. The cams were extremely small and relatively simple, but without them or even with the first version of them our bot would have been nonfunctional.  The slants on the guide rails allowed us to get the first tote flat and relatively center and fixed our yellow tote problem, but they were a late addition that would have helped immensely earlier on.

• Chapter 2: "OODA (Observe, Orient, Decide, Act)", "inspect and adapt", and "PDCA (Plan, Do, Check, Act)" are all getting at the same core idea.  Explain this idea and how it relates to the way a team functions.

The core idea is that you need to check that what you are doing is making progress towards a true end and pivot if it is not.  All three end with action of some sort; whether this is to change what you are doing or to encourage your team to keep at it, you must make a decision based on what you have observed.  In teams this is used to keep moving in a good direction.  When a team understands what went wrong/right in a scenario and takes action to improve, they become faster and more efficient.

• Chapter 2: Explain how we would implement the paper airplane example to practice a OODA cycle at a team meeting.  What would be the point?

We would break down into small groups with less than 7 people per and then assign a task.  Time would be set aside for planning, doing, and thinking over how things went and then the process would be repeated again.  The point of this would be to teach students the basic principles of Scrum while building team  bonds and morale.

• Chapter 3: What evidence does Sutherland bring up when justifying a focus on team improvement over individual improvement?  Do you think that should apply to our FRC team?  In what cases does it not?

The largest evidence that Sutherland brings forward is in how the best teams compare to the worst teams which has a ratio much greater than 10:1 (the comparison of best vs. worst students in a college class).  Sutherland also points to how much teams can accelerate their pace while a single person has their limits.  I think that focusing on team improvement to our team should be incredibly important since we can't rely on one person to get everything done.  The only case I can think of where this principle would not be true would be in single person sports since a single great person can win on their own.

• Chapter 3: The best teams are transcendent, autonomous, and cross-functional.  In your OWN words, what does this actually look like on an FRC team?  It may help to reference examples from the West Point, NPR, and Special Forces case studies.

The best kind of FRC team realizes that the purpose of their team is to introduce to and teach people about STEM and works towards that goal with a good robot being a side effect (a nice side effect) of the learning.  This kind of team lets the students test and make decisions based on their results that affect the robot directly.  Lastly, in a great team, everyone has a basic understanding of what everyone else is doing and knows what they are all working towards.  This would be a great FRC team and would exhibit transcendent, autonomous, and cross-functional characteristics.

• Summary

I learned a few things about scrum and how it works such as what a sprint is and how scrum came to be.  I also learned about small teams being efficient, the waterfall method and why not to use it, and how inefficiently teams have been working because "that's the way it's always been done".

Braxton SC2

Chapter 4: What is the purpose of the sprint?  What are the rules that govern a sprint?

The purpose of a sprint is to have a short burst of high-productivity in which a large mount of work is completed, and then the team evaluates what they've accomplished and seeks to improve the process for the next sprint. Some of the rules that govern a sprint are: holding a daily meeting with the entire team, no longer than fifteen minutes, in which team members go over their work and what will prevent them from doing it efficiently; a sprint must not be too long a period of time; and a board featuring the sprint's work divided into backlog, doing, and done columns on which post-it notes with jobs are moved to their respective station.

Chapter 4: Sutherland required his first scrum team to throw out all titles.  Why?  Where (inside and outside FRC) have you seen titles get in the way of getting things done?  Where can titles be a positive thing on a team?

Sutherland required his team to throw out their titles because practically all of them were simply status markers that only hinder collaboration and cross-functionality, as title-holders simply stuck to their title's job, or what they perceived as their titles job, and they often hoarded valuable info. In FRC, I've seen titles get in the way of jobs and even cause conflict, as arguments and discussions over who should have what title and what their jobs should be have occurred far more often than they needed to. Titles on the team have often caused jobs to be left unfinished, as the respective title holder would 'handle it'. However, this isn't to say that all titles are negative on an FRC team. Most titles, admittedly, are useless and just get in the way (most team leads). However, there are two titles worth keeping due to their benefits, even if they are simply honorary. The first is safety captain, a title required by FRC and an obvious title to keep. The other, overall Team Captain, is very valuable scholarship-wise, and is a title of respect granted to an individual on the team by majority vote. This title, even if simply unused and honorary, is worth keeping for its positive scholarship impact and recognition of a highly-involved student recognized by the team as a whole.


Chapter 5: Why is multitasking wasteful?  When in your own life do you refuse to multitask and just focus on a single task?

Multitasking is a wasteful activity because the human brain can only focus on so many tasks at once, and focusing on too many can cause effort to be wasted due to mistakes, backtracking, and switching projects. One of the times where I outright refuse to multitask is when I'm reading a book. I absolutely cannot read more than one book at a time outside of required reading, as it throws me off plot-wise, and I have to re-read several pages to remember where I was, rather than just a paragraph or already knowing.

Chapter 5: According to the Maxwell curve, an employee reaches peak work completion in a scrum environment at how many hours / week?  Given that we all work on robotics AFTER a full week of work or school, how many hours do you think we should be working each week during the build season to maximize how much we can get done?  How does this compare to how often we met last season?

An employee reaches their peak work completion in just under 40 hours. In robotics, I'd recommend we work around 10-15 a week, maybe more or less depending on the time of the season. This is FAR less than we worked last season, as some of the longest weekends could rack up 12 hours a day. My reasoning for wanting much fewer meeting hours is this: in long weekends, people show up early and start work, although a key person is almost always missing, resulting in blockage. For the rest of the day, people come and go, and someone is almost always out of the loop in some way, and no one knows what we did earlier except for those that were there. By the end of the day, a few hours after lunch, productivity is practically non-existent, and any work that is done is either wrong or esoteric, which is to say known only to the person who did it, who will then have to spend time informing everyone, usually individually. And now, with scrum, we are very quickly running out of work to do, resulting in a very unmotivated group of students in later hours, when the meet should already be over. The latecomers also tend to lack jobs, as they've all been done already by everyone else in 3 man teams, leaving unproductive students. These issues encourage me to petition for shorter meets each day.


Chapter 6: What does the "Definition of Done" mean?  Why is it critical that the entire team understands the DoD for each task?

The "Definition of Done" means that a story is finished with development, tested successfully, and is able to be confidently handed over to the customer, manager, or whoever the story was for. It is vital that the entire team knows what the DoD is for every task so that they may test the story themselves, and catch issues early, to prevent a huge loss due to redone work and backtracking.

Summary:

In this section of the book, I read about the different processes of scrum, and how to perform them properly. These ranged from planning poker to sprints. There was detail about the purpose of these procedures and how to implement them, as well as their rules and regulations.

Nate SC1

• Chapter 1: Explain the planning process for the new FBI system "Sentinal".  How was a Gantt chart used in the process?  What is Sutherland's beef with this kind of planning?
• The FBI had people plan every step of the Sentinal project which sounds like a good idea.  They used a Gantt chart to show how these steps will work.  This ends up failing every time though.  That is the problem that Sutherland has with this kind of planning.
• 
  
• Chapter 1: Sutherland explains the 80/20 rule: 80% of the value often comes from 20% of the work.  In the last year of FRC, what were some of the 20% jobs that added tremendous value to the team?
• Last year, we had a few things that were very helpful that didn't take much work.  The front triangles to get in the box got made in about ten minutes at competition.  Also, the wooden triangles were a very quick fix to the problem of crooked totes.  These small jobs greatly increased the value of our robot to make it able to compete at a higher level.
• 
  
• Chapter 2: "OODA (Observe, Orient, Decide, Act)", "inspect and adapt", and "PDCA (Plan, Do, Check, Act)" are all getting at the same core idea.  Explain this idea and how it relates to the way a team functions.
• These systems are both getting at the need to focus on a small part of the problem.  This calls for a plan with preparation for issues.  This would be great to be implemented on out team because we would have a plan, and we could allocate some of the time for the task for possilble issues that may be unseen in the plan.
• 
  
• Chapter 2: Explain how we would implement the paper airplane example to practice a OODA cycle at a team meeting.  What would be the point?
• We could implement this to do two things: work on team functionality and learn to design and build pars of a robot.  With this we could be givin small tasks of things to build and we would be able to learn each time and learn better processes to build a robot.  Also, if we constantly switched up teams we would be able to learn to work with everyone on the team.
• 
  
• Chapter 3: What evidence does Sutherland bring up when justifying a focus on team improvement over individual improvement?  Do you think that should apply to our FRC team?  In what cases does it not?
• Sutherland brings up the point that improving a team has a giant advantage in productivity improvement over individual improvement.  This would be great in helping our team get things done.  This would allow us to build our robot in a shorter amount of time.  That may also boost morale as we would actually see our families in the winter.  The only problem may be that someone may not feel they get enough credit for the work they did and get frustrated for going unnoticed.
• 
  
• End with a summary of what you learned.
• I learned many things in this reading.  I learned it is best to do short term planning and improve as a team over improving as individuals.  This would allow for our team to become more efficient and create a better robot in a shorter amount of time.  It also explained why attempting to plan out every last detail may be a poor decision as unforeseen problems can occur.

SC1 Ben

Chapter 1: Sutherland explains the 80/20 rule: 80% of the value often comes from 20% of the work.  In the last year of FRC, what were some of the 20% jobs that added tremendous value to the team?

I think that our triangles are an example of a quick job that was extremely helpful. We did spend some time thinking of manners in which to modify it, but they still took minimal time and effort to construct.The stop switches were also beneficial in not totally wrecking our chain and gears, and it didn't take much work to decide where to place them and how to wire/program them.

Chapter 1: At the end of every sprint (2 weeks in this case), the Sentinal team presented a working demo to stakeholders across the FBI.  Why is this necessary and important to do?

It is important to get constant feedback on any advancements that are made. There is always the distinct chance that modifications must be made, or maybe there are too many modifications as is.

Chapter 2: "OODA (Observe, Orient, Decide, Act)", "inspect and adapt", and "PDCA (Plan, Do, Check, Act)" are all getting at the same core idea.  Explain this idea and how it relates to the way a team functions.

All of these systems want you to look around and see what needs to be done, what constraints there are, what materials you have at hand. Then they want you to plan out your course of action and act on it. As you carry out your plan, make sure to watch for changes, so you can make adaptations as the situation necessitates. 

Chapter 2: Explain how we would implement the paper airplane example to practice a OODA cycle at a team meeting.  What would be the point?

We could divide the team into small groups, each tasked with building a paper airplane with 10 minutes. We test the airplanes, and let each team observe the others' planes. From there, people take notes on what they liked and disliked, and make modifications accordingly to their own design.

Chapter 3: The best teams are transcendent, autonomous, and cross-functional.  In your OWN words, what does this actually look like on an FRC team?  It may help to reference examples from the West Point, NPR, and Special Forces case studies.

An FRC team that is autonomous would agree on tasks needed to be done that day and know how to do these tasks on their own. They don't need constant interruption to be told how to do something or to be told to get on task; they stay on task and know what they're doing. Cross-functional teams can do multiple things. They build a robot that isn't restricted to only one function through the duration of demanding games, they know how to raise money and can get by without loans or outside help(not including donations), and they know how to involve their community. They get people interested in STEM and host summer shops and demos. Transcendence would be characterized by results. A transcendent team would win regionals and awards. They would go out of their way to help other teams, schools, and communities, resulting in awe-struck neighboring teams. 

Summary

I have learned about the creation of scrum, how it works, and its efficiency compared to the waterfall method. I learned what characteristics a team should have, how teams ought to go about planning tasks, and adapting to any changes along the way. Finally, I learned to appreciate the easy tasks that constitute grand results. 

Bryan SC1

• Chapter 1: Sutherland explains the 80/20 rule: 80% of the value often comes from 20% of the work.  In the last year of FRC, what were some of the 20% jobs that added tremendous value to the team?

I think that the cams and the triangles in the front of the robot added a lot of value due to the small amount of effort needed to complete such tasks and how it helped a lot.

• Chapter 1: At the end of every sprint (2 weeks in this case), the Sentinal team presented a working demo to stakeholders across the FBI.  Why is this necessary and important to do?

This is necessary and important because without feedback improvements can't be made. That said, as a team we need to get input from the drive team as well as the other sub teams and work on solutions based off of the feedback.

• Chapter 2: "OODA (Observe, Orient, Decide, Act)", "inspect and adapt", and "PDCA (Plan, Do, Check, Act)" are all getting at the same core idea.  Explain this idea and how it relates to the way a team functions.

These relate to how a team functions by explaining how a team should go about their business. The team should act on what things are changing around them and plan accordingly.

• Chapter 2: Explain how we would implement the paper airplane example to practice a OODA cycle at a team meeting.  What would be the point?

We could actually make paper airplanes in groups to see who's would go the furthest using specific resources and they can observe other teams doing things. The point would be to learn how to observe and make changes based off of your observations and to decide how to do things based off of those observations.

• Chapter 3: The best teams are transcendent, autonomous, and cross-functional.  In your OWN words, what does this actually look like on an FRC team?  It may help to reference examples from the West Point, NPR, and Special Forces case studies.

On an FRC team it would look like a bunch of people working together to make the best possible robot including mentors and students. Everyone would know what to do and would be able to complete that task without much help, but if they did need help they could check in with other teams and also check in with mentors.

Summary:

I learned that even the smallest things can be the most valuable and that there are many ways to go about solving a problem. Also, that we don't always have to use our own ideas, we can use other peoples ideas to solve a problem. We can also become autonomous as a team by simply helping each other and taking responsibility.

SC1 - Chad

Chapter 1: Explain the planning process for the new FBI system "Sentinal".  How was a Gantt chart used in the process?  What is Sutherland's beef with this kind of planning?

The "Sentinal" planning process seemed to be like many other large companies.  Each functional group created their requirements needed by other groups, estimated the amount of time required to complete their taks.  The Gantt chart linked each functional areas activities together to generate a complex interdependent plan.  Sutherland's issue with this planning method is that it is incorrect before the team even starts implementing the plan.  So all the work that was spent creating the interdependence could have been productively spent solving problems.  From my personal experience, the person providing inputs or creating the Gantt chart is also the best person to eliminate road blocks and provide leadership for the team.

Chapter 1: At the end of every sprint (2 weeks in this case), the Sentinal team presented a working demo to stakeholders across the FBI.  Why is this necessary and important to do?

Stackholders need to be updated or the scum will begin to be more like the waterfall method with no feedback until the end. With frequent updates, changes can be identified early enough to make adjustments. In many cases, the stack holders also need to have confidence that the scrum method is yielding benefits. The stackholder meeting is the venue for this update.  By the way, a great stakeholders meeting could be lunch/dinner time presentations to the entire team.  Food and a show!

Chapter 2: "OODA (Observe, Orient, Decide, Act)", "inspect and adapt", and "PDCA (Plan, Do, Check, Act)" are all getting at the same core idea.  Explain this idea and how it relates to the way a team functions.

These ideas all feed into continuous improvement strategy.  OODA is about figuring out what needs to be done and doing it, which is for sure a lean methodology.  Inspect and adapt and PDCA have continuous improvement embedded in the definition.

Chapter 2: Explain how we would implement the paper airplane example to practice a OODA cycle at a team meeting.  What would be the point?

To start with the point.  I think that learning the skills to observe and orient are very important.  The airplane is a good example because it also incorporates a loop and small tests.  Learning the technique could be as simple as duplicate the exact activity.  For an applicable robot activity, we need something that can easily be iterated so optimizing the program is the most obvious.  The activity could center around maneuvering the robot through and obstacle course, time or hitting the fewest obstacles could be the criteria.  Between iterations changes to gains and other quickly modified parameters can be changed. 

Chapter 3: The best teams are transcendent, autonomous, and cross-functional.  In your OWN words, what does this actually look like on an FRC team?  It may help to reference examples from the West Point, NPR, and Special Forces case studies.

Autonomous and cross-functional are the most probably team types for an FRC team.  The mentors enabling students to make their own decisions (experience is a great teacher), the students knowing when to engage the mentors for assistance and once the input has been taken in, the team should act.  This is basically the NPR example where the executives (mentors) couldn't be reached.  The team has a choice rise and get the job done or not get focused on problem solving.  For the FRC team this is operating in the small groups developing small tests and moving the robot design / build / programming forward.  Cross functionality with the cross training would improve efficiency as it would help level the surges in work.  As the special forces communications specialist can patch up a wounded comrade with the medics can't, a marketing or programmer could spin the cad model during the build season to free up the designers to solve a problem.  Or that marketing person could be well enough versed in the design to help create concepts for solving design problems.

End with a summary of what you learned.

Coming from a place that really values Gantt charts and has several people hired just to manage the Gantt chart, I am finding this book fascinating.  

Thinking back to my work for the last 12 months, it took this book to realize why my productivity improvements have stalled.  Basically it is the small cross functional team model.  During this time my marketing and business team mates have took other jobs or retired, leaving an imbalance of skills.  In addition, other projects have ballooned such that the teams I am on are very large.  I have the perfect project that is starting August 1 to try some of these new concepts on.  There are many items that lend themselves to small batches and there is customer interface software to be developed that could, give the correct support and early adopters lend itself to the lean start up and scrum principles.  Now to get some buy in!

• Intro: Last build season, we discussed an ideal strategy.  This strategy had a number of leap-of-faith assumptions about how long things would take and what we could do.  Try to describe our ideal strategy, including those assumed numbers that helped us calculate how many points we could earn in a round.

Our ideal strategy was to build large stacks at the feeder and score them, we figured we could score at least 40 points a game, if we were able to get the bottom tote to land flat.  We assumed these numbers based on roughly how long it would take to lift a tote using our protobot to test.

• Intro: At what point in the build season did we find out how accurate our assumptions really were?  Was it possible to accelerate this?  Could the assumptions be broken down into small experiments?  If so, how?

I would say we found out about half way through the build season, this definitely could have been faster.  If we had built a full protobot on the first/second week we would have been able to realize many of the important design decisions that it took us a long time to find.  We could have broken some of the assumptions down which we did do, however I think in retrospect that we should have done these small experiments sooner, if we had built a protobot quickly we could have tested the extensions idea/center of gravity problem.

• Intro: Explain the build-measure-learn feedback loop.  What is the purpose of this loop?  Why is it a loop?

In the bml (build measure learn) feedback loop, you start by building a minimum viable product, testing it, and seeing where you can improve it.  Then you are able to improve it and make a better build, test it, and find where you can improve, making a perpetual loop of improving your product.  The purpose is to be able to build better and  better product by learning what customers want/what does and doesn't work.  It's a loop because you can improve pretty much everything, and you can keep using this process to get a better and better product.

• Going back to some of the leap-of-faith assumptions, what would some minimum viable products (MVPs) look like that could validate these assumptions?  What would we measure with the MVPs?  Think specific to last season's game.

A MVP in First most likely will look like a protobot, being able to test anything that isn't fact, whether its being able to straddle the scoring platform or if we will tip over if we try to drive straight onto it.  If we had built our protobot sooner we could have found many design changes that would improve our real bot and have fixed them.  We did that too an extent but I think we should have done this sooner as it takes a lot of the unknown out of design.

• Explain the words "pivot" and "persevere" in the context of a team's way of doing things.

For us to pivot is to realize that a different design choice would be better than what we are currently doing and use that idea.  Persevering for us would be deciding although something is hard and there are other options we continue to push forward because it is for the best.

Braxton SC1

Chapter 1: Sutherland explains the 80/20 rule: 80% of the value often comes from 20% of the work.  In the last year of FRC, what were some of the 20% jobs that added tremendous value to the team?

In our team's last year, some of the 20% jobs that brought an immense amount of value to the team include our cam iterations. These small pieces of metal allowed our bot to lift, hold, and release totes and bins, so there were instrumental to our entire strategy. Our work on the cams my not have been the most exhaustive of anything on the robot, but certainly brought a lot of value by making our entire strategy possible.

Chapter 1: At the end of every sprint (2 weeks in this case), the Sentinel team presented a working demo to stakeholders across the FBI.  Why is this necessary and important to do?

This is an important and necessary function to the Sentinel team because these stakeholders re going to be the product's primary users, and their input is extremely important for the project. In addition to this, the two weeks of development is long enough for tangible progress to be realistically made, as well as short enough to prevent a large amount of waste to possibly be produced. The development team can then collaborate with the users and improve the product based on their suggestions.


Chapter 2: "OODA (Observe, Orient, Decide, Act)", "inspect and adapt", and "PDCA (Plan, Do, Check, Act)" are all getting at the same core idea.  Explain this idea and how it relates to the way a team functions.

The idea that both OODA and PDCA are trying to get at is that of the fabled agile development, where teams should take in their surroundings and situation, plan accordingly, and then act upon that plan and information. After you act, you should reflect upon your actions, to see how you can improve. This is very relatable to teams, as they should follow this process when developing a product.

Chapter 2: Explain how we would implement the paper airplane example to practice a OODA cycle at a team meeting.  What would be the point?

The paper airplane idea could be implemented at a team meeting in several ways, one of which would be having everyone divide into small groups, and work on a task such as CADing a model of a part, assembling a piece, or, as we've done in the past, build marshmallow-and-toothpick towers. The point of these exercises, aside from the ambiguous concept of 'team-building', would allow the entire team to become knowledgeable on a part or process, and for everyone to give input, which could lead to new ideas being brought to the table. 

Chapter 3: The best teams are transcendent, autonomous, and cross-functional.  In your OWN words, what does this actually look like on an FRC team?  It may help to reference examples from the West Point, NPR, and Special Forces case studies.

On an FRC team, being able to be transcendent, autonomous, and cross-functional is extremely valuable. An FRC team that meets all three of these criteria would be similar to that of the special forces team, where each member knows how to perform another's job, in the event they are unable to do so. This kind of cross-functionality on an FRC team would be  valuable asset, as team members could still program autonomous, design in CAD, or wire the electronics board even if the people who normally do these things are gone. An autonomous team would be able to know what needs to be accomplished on that day and how to accomplish it without a long meeting. Finally,  transcendent team would be able to fluidly move through all of the motions of design, construction, and testing without hitting any roadblocks that could have been prevented.

Summary:

In this first part of the book, I read about the origins of scrum, and just what scrum is, as well. I read about the ideal size of a team, and bout how much more efficient scrum is as compared to the waterfall method. I learned about the traits that are present in the ideal team, and bout the value of just 20% of work put into a product.