Debriefing Session

Posted by Debby on 11th April and posted in Robotics, Teaching and Learning

Last night we had a great robotics session. No, we didn’t build anything. No, nothing blew up (although there was some fire involved). All we did was sit and talk for about half the class. And it was amazing.

One thing that I notice is that these guys get so caught up in the hands-on part that they forget to take the time to reflect and think. The planning journals each time helped out, but I wanted something that looked at the big picture of what happened with the project. The alumni, helpers, and myself had noticed a decided lack of communication between teams in each group and we wanted to see if they would be able to identify that as a key issue when given the chance to talk it out a little.

I sent each team into a different room with the charge to discuss what went well, what did not go well, and what they would do if they were given one more day to work on the project. They were specificially told that this was NOT a gripe session, a blame session, or a time to pull people apart. This was to stay constructive and thoughful. I asked Eric to stay in one room and Chuck to go with the other group to help moderate. I wandered between the rooms, listening and guiding their thoughts to areas they hadn’t really considered before.

After about 20 minutes or so, we came back together and both teams wrote their notes up on the board. We watched a 2 minute video montage [.wmv] of the event that Michelle put together. I asked each team to send up a spokesperson to talk and we started to discuss each task – rocks, bridge, log, rescue – in turn. They were still mostly looking at technical issues … this thing didn’t work, or that thing did something really cool. Then, Chris J. got an “ah ha” moment and said “We we missing overall team integration”. Shazam! Someone else tossed out the word “synergy” and we talked about how that (or lack thereof) played into the final results when they ran their project. What followed was a very dynamic discussion with many people getting a chance to voice their thoughts. Linda brought up that more time should have been spent on software development (programming) because that was left to the end. Even if the bridge robot wasn’t finished, a prototype could have been made for practice purposes. Someone else brought up that although the team had good programmers and good builders, what didn’t happen was a good allocation of human resources. The team initially self-selected who was going to be on which task, but didn’t think to shuffle the mix once the strengths of different team members were identified. A bit of self-imposed competition, even between the groups on a team, resulted in not taking advantage of the best assets available all the way around, impacting the success of the final team project.

A few started to take personal offense at some of the comments, and I made a point of bringing it back to the understanding that we are all working together here and part of being a team member is being willing to ask for help… and being willing to accept it when offered. Everyone had been so focused on their small part of the puzzle that they didn’t open up enough to fully integrate with their teammates. After a while, I asked the alumni and helpers to share their observations.

Chuck: Team integration. He brought up the Nasa probe that crashed because the different groups on the team were using different measurements (metric vs American). Lack of communication about simple things can bring down a project.

Eric: When you break a problem into smaller parts you have to make sure that all the groups are working with the same standards. Agree upon the measurements, the interface, and anything else that is vital to the integration of the parts back into the whole.

Remember, you aren’t being graded on whether you complete the task and the other group doesn’t. The bridge group on Team A should talk to the bridge group on Team B, etc.

Too much focus on striving to succeed and not enough on the fear of failure led people to not test enough, not work together enough.

It was an wonderful way to tie up the loose ends of a very energizing project. The lessons learned here will be applicable way beyond the classroom walls. They will help them as they go forth into the real world, dealing with real world projects. I for one, was very pleased with results!

Rock 'em Sock 'em Awesome Robots (RSAR)


Comments are closed

Powered By Wordpress || Designed By @ridgey28