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.