Keeping an Eye on the Big Picture

[Kevin Leonard]

In order to keep tabs on our design, we have design meetings often during "prototyping season". I think this part of our design process can be separated into two sections:

When the design is based on the prototypes
And when the prototypes are based on the design.

I know this year we came to one point where we came up with the basic design of how the robot would function.
Before that day, we had prototypes of all sorts of different shooters/hoppers/collectors. After that day, we knew our robot was going to have a linear hopper, we knew we'd be going with the roller collector, and we knew some other subsystems that would be necessary.
After that day, we prototyped better packaging for the shooter, a side belt to bring the discs up to the shooter from the collector, our hanger and hard stop, and how to lift and lower our tray.
After that one design meeting, we knew what each subsystem would have to do, and how it would have to be integrated. We also knew to no longer prototype the bucket hopper, and to no longer prototype the 180 degree shooter.

[AllenGregoryIV]

Another thing that I find helps, is I try to keep the latest CAD model on the projector in the lab most of the time. That way people have a very good vision for what we are building and can see the changes on the fly if I happen to have time to work on it during a meeting. This also gives our students that don't know Solidworks a pretty good introduction since they can watch me work. We also share the CAD over Google drive so that all of the team has access to the same files.

[Gdeaver]

For the night by night, day by day management of build, the agile development method works quite well. While it was initially focused on software development processes, it can be modified and applied to all aspects of the build. I like to think of the Agile process as a bottom flowing up process. There needs to be a top flowing down process. Scrumming can be very effective but needs dedication by the entire team. It's easy during the craziness of build to loses focus and discipline.

[ElvisMom]

Madison, Allen (plus anyone else who has a similar process) -

I'm not an engineering mentor, but I am trying to resolve issues around organizing the CAD files, designing a process to maintain good master files, etc.

I like the idea of sharing the CAD live via the projector. We've also toyed with the idea of having monitors in our machining area so folks can more easily refer to the design in real time.

Can either of you share how you use cloud sharing and Google Drive specifically to organize the CAD files. One of the things the engineer-types have commented is that there isn't a way to view the files in Google Drive in native format.

I keep thinking Google drive should work. I think there is also an Autodesk cloud solution, but I don't know much about that.

Thanks in advance.

POLLY

[DonRotolo]

Originally Posted by sanddrag

If you wait to finish the CAD model before cutting any metal at all, you might have only a CAD model to compete with.

True. Several parts are 'standard' and can be fabricated right away, as can most drivetrain components. (I wonder if the CAD model might do better at competition though...)

Originally Posted by Madison

Appreciated. It's my own fault, of course. I am terrible and delegating tasks I think I can handle myself.

Yeah, I was young once myself, but then I got old and learned how to delegate ruthlessly. And later still I learned that I hated supervising, and I am now quite content and fulfilled as a worker bee.

Originally Posted by Gdeaver

For the night by night, day by day management of build, the agile development method works quite well.

I just read he Agile Manifesto on Wikipedia; I'd never heard of it before.

Wow.

Implementing it, to me, means getting everyone together for updates and collaborative decisions. The customer is the drive team.

[sanddrag]

This seems to be a good point in the discussion where I can add something JVN posted a while back in a similar thread. It was something to the effect of "We will never vote on a design. Voting is not an engineering decision making process."

I agree completely with that, and not everyone should have an equal say, or even a say at all.

If you look at how some of the most successful teams operate, you'll notice that they often have one person driving the design, from big picture to minute detail. They can delegate the work, but they are beginning with the end in mind, and know what the whole thing should look like before any of it is CAD modeled or built. These individuals are often mentors with many years experience in FIRST, and they have often closely studied the successes of others.

[DampRobot]

Originally Posted by sanddrag

This seems to be a good point in the discussion where I can add something JVN posted a while back in a similar thread. It was something to the effect of "We will never vote on a design. Voting is not an engineering decision making process."

I agree completely with that, and not everyone should have an equal say, or even a say at all.

If you look at how some of the most successful teams operate, you'll notice that they often have one person driving the design, from big picture to minute detail. They can delegate the work, but they are beginning with the end in mind, and know what the whole thing should look like before any of it is CAD modeled or built. These individuals are often mentors with many years experience in FIRST, and they have often closely studied the successes of others.

This is probably one of the best summaries I've ever seen about why the teams that are awesome are awesome. While hard work and resources are important, having a single extremely competent person with control over the design is probably the most important factor to team success.

[ttldomination]

Originally Posted by sanddrag

This seems to be a good point in the discussion where I can add something JVN posted a while back in a similar thread. It was something to the effect of "We will never vote on a design. Voting is not an engineering decision making process."

I agree completely with that, and not everyone should have an equal say, or even a say at all.

If you look at how some of the most successful teams operate, you'll notice that they often have one person driving the design, from big picture to minute detail. They can delegate the work, but they are beginning with the end in mind, and know what the whole thing should look like before any of it is CAD modeled or built. These individuals are often mentors with many years experience in FIRST, and they have often closely studied the successes of others.

I'm curious about how you would reply to people who would say that this method fails to engage students at a higher level? That is to say that if a mentor is managing the big picture, it robs students from getting a chance to weigh into major decisions.

For some teams that operate on the principal of "student built; student designed," the aforementioned structure seems to challenge the very foundations of some teams.

- Sunny G.

[AllenGregoryIV]

Originally Posted by ElvisMom

Can either of you share how you use cloud sharing and Google Drive specifically to organize the CAD files. One of the things the engineer-types have commented is that there isn't a way to view the files in Google Drive in native format.

I keep thinking Google drive should work. I think there is also an Autodesk cloud solution, but I don't know much about that.

We setup a folder on our team Google drive account that is shared with the students that do CAD (and anyone else that wants it). Each student has a subfolder where they upload their CAD files and I have a folder as well. From their thier is a master folder with the current CAD. We copy out the main file when we want to work on something and then we copy it back into main folder. I'm normally the person that adds in people's subsystems and keeps the main file up to date. That is how are system is supposed to work, but it does break down on occasion. We also normally end up stopping CAD at some point which is detrimental around week 4 or 5. We have a few students that should be really good at CAD this year and should be able to keep it all updated. This will help when we go to make new sheet metal assemblies during competition season. This year we never even mirrored the parts in CAD (so we only have about 66% of a robot) which is one of the reasons we didn't publish our robot this year. The CAD was so incomplete it wouldn't be helpful to anyone.

Originally Posted by ttldomination

I'm curious about how you would reply to people who would say that this method fails to engage students at a higher level? That is to say that if a mentor is managing the big picture, it robs students from getting a chance to weigh into major decisions.

For some teams that operate on the principal of "student built; student designed," the aforementioned structure seems to challenge the very foundations of some teams.

Just because I keep everything running along and coming together doesn't mean the students aren't involved at a high level. I'm not magic and I don't know everything. The students are the ones who do nearly all our prototyping (I rarely touch the tools), so most of the time there is a student sitting next to me while I CAD or if I do it at home I immediately bring it to the people prototyping and get them to tell me how to fix all the things I stupidly ignored about the design. If I made all the high level decisions by myself our robots would be very, very bad.

I completely understand teams that want to be "student built; student designed," and that works for them. In FRC you are able to build your team in many ways and can include whoever you want; which to me is one of the best things about it.

[xForceDee]

Originally Posted by ttldomination

I'm curious about how you would reply to people who would say that this method fails to engage students at a higher level? That is to say that if a mentor is managing the big picture, it robs students from getting a chance to weigh into major decisions.

For some teams that operate on the principal of "student built; student designed," the aforementioned structure seems to challenge the very foundations of some teams.

- Sunny G.

I'm curious of this also. In my opinion, the ideal setup would not be one person, but instead, it would be a small group of 2-4 people including a mentor. This way, the team gets the experience of the mentor while still being student driven. Just my opinion though; I have never been part of a top performing team so my thoughts are a little less significant I suppose.

[Gdeaver]

The Agile development method was created for software projects and most of the online articles are totally software development focused. However, if you look at agile process from the over all concept, they can be configured for other business processes. In fact this year there have been many articles published on adapting the Agile methods to other industries. Particularly in the finance industry. For First teams I would Focus on the scrum and sprint concepts. Also the the role of the scrum master or task master. Scrum comes from rugby. If you don't what a rugby scum is that would be a start.
We have a design team that consists of the mentor and student leads of the the other teams and sub-teams.

[DampRobot]

Originally Posted by ttldomination

I'm curious about how you would reply to people who would say that this method fails to engage students at a higher level? That is to say that if a mentor is managing the big picture, it robs students from getting a chance to weigh into major decisions.

For some teams that operate on the principal of "student built; student designed," the aforementioned structure seems to challenge the very foundations of some teams.

- Sunny G.

We very firmly believe in being a student run, student built team (in fact, it's our motto). In the years where we've performed very well (2007, 2008, 2010), we've had one person who filled that role. They just happened to be a student.

I don't deny that having a mentor be the "team tsar" detracts from student involvement and learning, but on some teams it's part of their culture. Frankly, I hardly find it surprising that high performing teams tend to have a mentor fill this role. It's extremely hard to find a student with enough dedication, let alone experience and political ability, to fill that role in a way a mentor could. If winning is a high team priority, a mentor almost needs to fill that role. (Now, before to all jump down my throat, winning isn't a bad goal...)

[ttldomination]

Originally Posted by xForceDee

I'm curious of this also. In my opinion, the ideal setup would not be one person, but instead, it would be a small group of 2-4 people including a mentor. This way, the team gets the experience of the mentor while still being student driven. Just my opinion though; I have never been part of a top performing team so my thoughts are a little less significant I suppose.

You don't have to be a part of a top performing team to have a well informed, popular thoughts considered as significant.

But going along those lines, I think that a group of 2-4 mentor/students is a happy middle ground between having the one, super-experienced person managing the project and general prototyping groups.

The 2-4 person group would obviously include the "one manager" and 1-2 students who would get a strong taste for design and leadership. It appears to be a nice blend of both sides of the argument.

- Sunny G.

[Pault]

Originally Posted by ttldomination

I'm curious about how you would reply to people who would say that this method fails to engage students at a higher level? That is to say that if a mentor is managing the big picture, it robs students from getting a chance to weigh into major decisions.

For some teams that operate on the principal of "student built; student designed," the aforementioned structure seems to challenge the very foundations of some teams.

- Sunny G.

In FIRST, there is no best way to do something. If your team prioritizes student involvement, and you believe that this method detracts from that to much, then you shouldn't do it. It's not the only way to achieve success. However, it is true that many of the most successful* teams out there do not put such a huge priority on student involvement (not to say that they are 100% mentor built, but they believe that there are more important things than avoiding mentor involvement, and that in most cases mentor involvement is actually a good thing). This enables them to use this method, and it works very well for them. I am not a believer in the student built; student designed philosophy. I don't think that it is the best way to reach the goal that we all strive for. But just because I don't believe in it, doesn't mean that it's bad. In the end, whether you are 100% student built or 100% mentor built (if there is such a thing), we can all reach the ultimate goal: the inspiration and recognition of science and technology.

*I'm mainly referring to successful in the robot sense, but the same applies to successful in chairman's award sense.

P.S. I hope this doesn't go in the direction of every other student vs. mentor built thread. There was a lot of really good discussion going on, and I don't want to see it fade away. I'm probably just fanning the flames, but I've been wanting to post something about the subject, and this was my chance.

[sanddrag]

Originally Posted by ttldomination

I'm curious about how you would reply to people who would say that this method fails to engage students at a higher level?

I wouldn't.

However, I will give a little more insight into the methods of my own team. We used to be a team where everyone got a voice, and often times, everyone got a vote (shudder). Then, we realized our robots weren't very good (every year, and declining) so we set out to change. We began to question why certain things needed input from the whole team, when a select few experienced individuals could manage it just fine. We realized that we spent more time talking, sharing, debating than actually designing or building anything, and even if we ever did reach a consensus that everyone was happy with, it was so late it the game that it all got cobbled together anyhow. The design details were purely vocal, speculative, and if we were lucky, poorly sketched on a whiteboard. Team meetings were woefully inefficient, with each person taking a turn to share what he or she did, in great detail. Most of the time, these details were irrelevant to a majority of the others listening. And while these meetings took place, work did not. When I became the lead mentor, I threw these meetings out the window, and now I just let people work. There are very few times that something needs to be addressed as a whole team, and when it does we do. But we do not make a daily or even weekly habit of it. A good leader does not need to frequently halt all work to gather his people to ensure that work is getting done. He will be walking the floor and he will know it as it's happening.

Our designs are now driven by logic, testing, and experience, not speculation, opinion, and feelings. You'd be amazed how much a team can improve once they do a little self-reflection.

Many teams (including past years of my own) have this "we learn from failure" philosophy that makes me just cringe. It builds a culture of students who think there will always be a next time, and that mistakes are always okay, and who accept lousy work because they are learning. To learn from failure is fine, but to do so without giving every possible effort to succeed is just wrong. And by every possible effort, I mean including the expertise of mentors.

Aww shoot, I guess I did end up responding... Anyhow, this horse has been well beaten, so let's steer the thread back on track as the OP intended.

Who or how is the whole robot envisioned while it's still in the preliminary or pieces or sub-assemblies design stage? Some teams (such as 118) seem to have a VERY integrated design that I'm sure must be envisioned as a whole before any part of it can start to be detailed.