Jacob SC3

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

In our team, it is easy to walk down and ask about or just look at what is being done on the robot.  We also made our general strategy pretty available as well.  That's where the transparency starts to deteriorate: changes in design (front/back load, wheel arrangement, drive train, etc) are not always communicated to all members, there is a very apparent divide between the programming, mechanical, and media people with each doing their own thing, and I personally have had to deal with the challenges of what people want while designing CAD models.  This lack of transparency caused many delays last season and it needs to be fixed.

• Chapter 7: Sutherland talks about the importance of measuring velocity every sprint (even though it can be tedious at times).  How does knowing velocity affect a sense of growth?  Why is it needed to identify the "happy bubble"?

Any business cannot know it's success if it does not have an idea of it's velocity.  Velocity means speed in a given direction so to know ones velocity is to know how quickly a business is approaching or passing it's goal.  If it is moving rapidly in the right direction growth is good and is perceived as such.  If it is not moving, but the company is happy a happiness bubble may be forming.

• 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 a FRC team a product owner would have to have a great understanding of the rules of the game and what role the teams robot is supposed to play.  They would also need to have an idea of what can actually be made and an idea of a time frame for these things.  This would require somebody who has at least a baseline understanding of every section and knows a great deal about the majority of pieces or is willing to work with others to arrange tasks for their weak areas.  For our team we might need more than one product owner;  this is largely due to the transparency issue I mentioned earlier since most people are rather restricted to their faction and don't know much about the others (mechanical/media).  If we fix this problem it could become feasible to have only one, but they would have to be around all the time and be well informed on just about everything.

• 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. Prepare kids for future involving STEM principles

2. Build an amazing, functional, and legal robot

3. Recruit new people who are willing to learn

4. Raise money and awareness

5. Have fun (make it to nationals/worlds)

6 or 1. World domination (don't tell Paul we're doing it without him)

• 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 chapter that struck me as most significant was the application of scrum in schools.  The teacher literally had the students divide themselves up into cross functional teams and organize their own learning.  This has alleviated some of my worries since this worked so well in a high school I really think it can work on our team

• Summary

In these chapters I learned about transparency and how essential it is, how happiness affects results, and about a few real world situations where scrum was used.  The situations especially helped me to understand how our team can implement and use scrum to improve our productivity.

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.