Agile was made for software development, but most of the 12 points translate pretty well for robotics.
The biggest challenge is estimating what level of design complexity
your team can squeeze into each system integration cycle (i.e. combining the software, the electrical hardware, and the mechanical hardware, then testing and debugging them as a system).
At a minimum you want to be able to do one design iteration (with time for testing!) in the 45-day build season, but I'd argue it's not really Agile with 1 iteration. Ideally you'd shoot for 2 or 3 design iterations in that time. The key is
keeping the design simple enough that your team can execute it (design, fab, assemble, test) in 2 weeks, but still sophisticated enough to play the game. Off-the-shelf components go a long way toward keeping it simple.
My team (~40-50 students last year, nearly 50% of them 1st-year) did a good job of keeping it simple last year. We had a robot that drove - and only drove - by day 4 (it
really helps to have old robots you can take apart & rebuild), a wood/metal robot that could drive and lift totes by day 17, and our real competition robot started testing on day 31. [We did the driving-only robot because it was our first time with mecanum - this year we'll probably skip that iteration unless we think we really need a weird new drivetrain.]
It's also worth noting that building a 2nd robot helps A LOT. Last year was our first year doing this, and we saw a number of benefits: Less down-time during the build season because software & mechanical weren't competing for time with the same robot (as much). More student engagement in fabrication and assembly. More driver practice with a clone of the competition bot. We think the marginal cost for the 2nd robot was about $2k - nothing to sneeze at for a team with a tight budget, but still small compared to entry fees.