View Single Post
  #8   Spotlight this post!  
Unread 29-12-2015, 10:27
philso philso is offline
Mentor
FRC #2587
 
Join Date: Jan 2011
Rookie Year: 2011
Location: Houston, Tx
Posts: 938
philso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond repute
Re: Advice For Agile/Scrum Robot Development

Quote:
Originally Posted by Sid323 View Post
As a returning member of a team which is made up of many students new to FRC this year, I had a few questions about how my team could approach the build season.

This year, we are planning on using portions of the Agile/Scrum development process, which I have limited experience with, but most of the members have never heard of it before. Has anyone used this method before, and what advice would you have for a team new to it? I searched for this on CD before, but the answers weren't very clear (most of them suggested that Agile doesn't work that well for FRC on the whole).

Also, considering that our approximately 35 member team is over 50% rookie, do you have any advice for how to approach a situation in which most of the team has never built a robot before? We do have more than a few experienced members and mentors returning, but our team is currently going through a transformation period.
From what I have read of SCRUM and similar development processes, an underlying assumption is that all participants are committed to "doing what it takes" to achieve the same goal. The whole team must also be trained in that management technique ahead of time and accept being managed in that way. A typical FRC team may have a small core of committed team members but the remainder usually come and go in an unpredictable way. The team members who are assigned a task and don't show up cannot be managed, making everybody frustrated.

I am not against such development processes. Two jobs ago, we used a "concurrent design" process to put out a very complex product involving electrical hardware, mechanical and software design in a relatively short time with everything coming together very smoothly even though the development work was done in three different countries.
Reply With Quote