[runneals]

Originally Posted by Pault

The team I was on last year tried using SCRUM, and it did not end well. It essentially just ended up using a ton of precious meeting time with little benefit. Essentially, what it comes down to is that SCRUM has a lot of quirks that work really well in a normal, professional environment, but not so well in FRC. For example, you really only get one shot at making a robot (kind of 2 if you build a practice bot, but lets ignore that scenario). That means you cant have a "potentially shippable product increment" after every "sprint." Also, for coding, you generally cant reliably test a lot of code until late in the build season. Essentially, the whole idea of a "sprint" only works for projects where there are going to be many exact, functional prototypes of whatever is being built (meaning they match the CAD rather than are made of wood, and are properly wired to a control system so that code for them can be tested). FRC teams just dont have the time and resources to do that.

Now, there are a lot of good principles that can be taken from SCRUM. Both the daily scrum and the scrum of scrums are useful for keeping the team on the same page and making sure everybody knows what needs to be done. The whole notion of iterative design is great for FRC; prototypes are your friend. And TO-DO lists are awesome for keeping track of what needs to get done and making sure everybody has work to do, although I personally prefer online TO-DO lists such as Trello.com which my team is using this year.

Finally, if you have the privilege of having some devoted engineers mentoring your team, use them to lead projects. They are much more efficient at distributing tasks than students are, partly because of experience and partly because mentors generally aren't occupied doing their own thing during meetings. The student leader of the wiring team is going to want to be involved in wiring the robot themselves, not spending all their time telling other students what to wire and teaching them if they dont know how. An electrical engineer, on the other hand, would be more inclined to oversee the work students are doing and put someone on a new task when they are done.

Don't forget to hire that Certified SCRUM Master In all seriousness, I could see where a modified version of SCRUM or an agile type process could potentially work. We tried to use bits and pieces of it (primarily the project scope document) on projects where I have been the only developer and it seemed pointless to use it (besides the project scope document) where I was the one doing all the development work.