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?
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.
- Having a functional bot by competition
- Having a working understanding of the year's game, and how to coordinate strategy with alliance mates
- Securing sponsorships and funds through various channels
- Submitting a finished chairman's appliction for 10 points in the state rankings
- 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.
No comments:
Post a Comment