I've been on FRC teams that meticulously plan their 6-week build. As a lead engineer I've been guilty of over-planning the season. A few years ago I realized... the seasons run better if you let the schedule evolve organically.
We stick to our basic underlying process, and we stay focused on our goals... but we let the process shape itself.
Chase excellence. Keep iterating. Trust the process.
The meeting we plan in the most detail, is the Kickoff meeting. We follow the same basic outline each year, with only a minor evolutionary change. (Everything is iterative, including Robowrangler kickoffs). You can read about our 2010 build season and process here, which includes a description of our kickoff agenda. It's funny to look back and see what's changed, and what hasn't in the past 6 years.
Here is the agenda for this year:
One major change we made in recent years is that we do very little analysis and decision making in the first few days of the build. We do basic analysis, but very quickly get to the "let's prototype some stuff and see what works" stage.
This has two main impacts:
- We don't hand-wave as many decisions, and will defer judgement on things. We wait until we have actual prototyping data to help us in our analysis / decision making. In some years this has kept us from making limiting assumptions early on.
Most of the decisions you want to make early on are going to rely heavily on past experience (which many of your team members won't have). By waiting until you can get some experimental info everyone will be more engaged, and you'll also end up making better decisions. (Your Mileage May Vary).
- The energy of the team is kept high. By spreading the analysis and discussion over multiple days with interludes of "BUILD SOME STUFF FROM VERSAFRAME!!!" the team morale stays high and we don't fall into a "slump" from too much time in front of the whiteboards.
Another "weird" thing we do on the Robowranglers is related to the Robot Rules. During Robowrangler Design we talk about the two types of specifications which define the solution to a problem: Functional Requirements and Design Constraints. The FRC Robot Rules are the largest set of Design Constraints we have in our process, but sorting through them can be boring as heck...
We make a big point of reading through the entire manual as a team. In past years this included the Robot section. Now, we go through the previous years' ROBOT rules in December. At this meeting we can spend an extended period of time talking about the major design constraints in detail. Since the Robot rules don't change a lot from year to year, we can get away with focussing on only the MAJOR changes on kickoff day and "skip" one of the more dry sections of the manual while still getting everyone up to speed.
The individual sub-teams will use this section in more detail during their work. (The Design team, EE team, etc each need to know their relevant sections backwards and forwards to do their jobs).
Tomorrow's the big day. We're ready. Keep following the Build Blog and see how our team keeps moving through our process!
Question: "Would you recommend 'Delayed Decision Making' for other teams? It seems like the Robowrangler resources enable this method which might cause problems in other programs."
Answer: I'd recommend it for every team... in moderation and according to their unique capabilities. I'm not saying: "delay everything until you have a fully functional prototype robot" I'm saying: when you're inevitably having those debates which require rhetoric as a justification tool... take a breath, and do some more prototyping before making a "hand-wave" decision.
Compromise... for this year, do your process as normal. While you're doing it, make note of how many decisions you make based on: past experience, the conventional knowledge of "the mob", or based on pure "I think this will work better, and I'm really good at convincing people I'm right" type arguments. Then for 2019 you can decide if it is worth making a change or not. :-)