We used a scrum method for design. It resulted in 3 robots of various abilities. We are wondering if all three were bagged, can they be brought to the same competition, with only one competing at a time for the same team? The rules don’t seem to specify a rule on this.


Oh, you mean the one-robot rule, C5?


C5. Compete with only one (1) ROBOT. Each registered FIRST Robotics Competition team may enter only one (1) ROBOT (or ‘ROBOT’, which to a reasonably astute observer, is a ROBOT built to play DESTINATION: DEEP SPACE) into the 2019 FIRST Robotics Competition Season.

The rules do specify this


Maybe off-topic slightly, but I’m interested to hear your experience with Scrum. I always thought it would be hard to apply to FRC (I tried to use elements from it once). I’m also curious how it caused you to end up with three robots.


And in particular,

C5. Compete with only one (1) ROBOT. Each registered FIRST Robotics Competition team may enter only one (1) ROBOT (or ‘ROBOT’, which to a reasonably astute observer, is a ROBOT built to play DESTINATION: DEEP SPACE) into the 2019 FIRST Robotics Competition Season.

This means you can’t even bag the three robots separately by next Tuesday and bring Huey to a week 1 event, Dewey to a week 3 event, and Louie to a week 5 event.

One of the implicit (or perhaps it’s explicit, because I’ve never formally studied it past a few hours of indoctrination, though I’ve been a part of it in several different roles) assumptions of Scrum is that it is possible to deliver a working version of the product, and continue to work on the developmental version(s) of the product with no effect on the working version. This, in particular, is often a false assumption in FRC development, where the incremental deliverable may be the only physical working model. Perhaps trying to preserve this assumption is how they wound up with three distinct versions of the robot.


While you can’t bring 3 robots, you can bring the “abilities” of the 2 other robots, if you have a useful way of grafting them to your primary robot. (there is no weight limit to what you put in the bag(s))

Then at the competition you’d have the option of switching out the “abilities” for your competition robot.

Of course, making changes after passing inspection would require re-inspection.


If this isn’t a joke. I think this team is going to need more help than 7502. Although I would like to know how many labor hours it takes to build 3 robots in conjunction.


I used it a couple of times with my team this season. In the first one, we got through 30 students in about 15 minutes, identifying 12 specific blockers the students needed assistance with. We realized that a key person (the head teacher) already had a todo list for the day whether she knew it or not. It also got the students thinking more about what a blocker means, and escalating for help when they hit one.

For those who don’t know what SCRUM is or why it’s more than a buzzword, SCRUM is a methodology for running projects. It can be applied in many places. It is, effectively, a daily update on who is ‘blocked’ on what without spending hours on status. Anything that prevents someone from doing his or her immediate job, big or small, is a blocker. For example, needing to purchase something, or not knowing what task to do next, are considered blockers. It is like traditional program management (understand cost/budget/risk) but in a way that puts less of the leadership responsibility/fallibility on a single person.

I too am curious about the 3-robot thing, and why SCRUM is being blamed for it.


I suppose so. Still not sure what manual that is in after looking, but thanks.


The 2019 Game and Season Manual.

If you haven’t read this manual, then you will probably have some issues at the competitions…


Seems clear enough, thank you. the rule is still a bit ambiguous after being at competitions and seeing where robots were connected by a cable to make them one robot or have significant interchangeable parts.


The rules do change over the years. 2015 did not have a frame perimeter size limit, so having other parts attached with cables was OK. Having significant interchangeable parts is allowed, as long as you follow the inspection rules–for example, all configurations must be weighed together and meet the maximum weight rule, or the robot must be reinspected after each change, before playing the next match.


I am not sure blamed is an appropriate word for a program that is meant to inspire students. I wouldn’t call what we attempted as puristic. We made an attempt to involve all our students in a developmental process. We had a scrum master, etc. We daily identified opportunities, met to understand opportunity, evaluated possible solutions by building multiple prototypes, built the prototypes and deployed them for evaluation. How we have 3 robots right now is that each possible solution required a build that would allow testing. i.e. for the disc - one has a mechanical apparatus, one has velcro, and one has suction cups. The main issue in attempting scrum was that the time needed to build effective possible solutions for evaluation was not enough - so we took 3 concepts all the way to a testing state and thus 3 robots. I am not saying they all are perfect and working without flaw, but the students have really gained a lot from the process, where highly engaged and where in critical thinking mode most of the time.


Thanks for the response, but not the sarcasm. Remind me again why I bothered posting anything on chief delphi.


thank you for that answer


The kids in our “scrum” process where highly engaged for the past 5 weeks. We had 3 groups that rotated members and assignments. Each group had programmers, mechanical, electrical, pneumatic trained kids that had a good idea of what to do. Our 2 mentors where able to fully stay in an advisory role because of it.


Sorry, sarcasm was not intended. It sounded like you could not find the rule that folks were referring to, so I provided a link the rules, and let you know that it’s kind of important to know the rules.

There are lots of people who post here, who do not know the rules, do not know where to find the rules, do not understand the importance of the rules. It’s really hard to tell from this end, how much of this you know already.


Kudos to you for making the student experience a priority.

You now have the delicate task of selecting which design(s) to compete with. It can be tough as students become attached to their idea and can have a hard time rationally deciding their design needs to be left outside of the bag. But this is also a valuable experience for them.

Good luck with this last week, and at competition!!


I think this is a very interesting case study. The more and more info I am reading about the more intrigued I am.

More than just “Scrum” must have been used here. I mean right off the bat you are implementing Cross Functional teams. Going deeper it looked like your team really embraced a certain production/management culture to achieve their goals with everyone on the same page. What are your resources like? Funding, # of Students, Shop Layout, etc?

I think your team did a great job at building Robots, but there is a bit of oversight I see in some of your responses in terms of building FRC robots. I can’t wait to see the outcome of all of it though. with a week left and either deciding on one of the 3 robots or merging the robots or what. It seems like you will do well either way.


I don’t think anyone in this thread was trying to attack or denigrate you for using scrum or any of the other choices you shared with us. Generally people on CD believe that each team should decide how to run their program so as to achieve the best outcomes for its members.

With regards to Scrum, my interest on your team’s adoption of it was genuine. It would be great if you after the season could share what went right for you and what went wrong, what you’re changing and not changing for next season, and if you’d suggest using Scrum or similar methodologies.

Good luck with the rest of build season!