“Team work. Team work. Team work.” “Students need to know how to work in teams.” “Working with other people of a diverse background is as important as knowing your discipline.” “I’ve never fired an engineer for incompetence; I’ve only fired engineers because they couldn’t work with others.” These are all statements that I’ve heard from industry partners, former students now working in corporate America, and friends in similar positions.
Teamwork is a cornerstone of Introduction to Engineering Design, a Ways of Knowing course for SMU’s new University Curriculum. The course is a project based learning experience for first-year engineering students where the students work in multidisciplinary teams to build autonomous robots that can traverse a playing field to find a water basin. Once found, the robots have to test the water for pH, temperature, and turbidity, and then remediate the pH of the water. Completing a robot of this complexity is no small feat for first-year students.
We’ve done many things over the years to help the teams be more effective, procrastinate less, and achieve more technical success. However, it is rarely the technical competence of the team members that stands in the way of that success. More often, it is the lack of experience concerning how to work effectively on teams that has caused the most problems. Teams would encounter typical problems such as the “slacker syndrome” where a few members leave all of the work to the others.
Recently, with the help of the Hart Center for Engineering Leadership in the Lyle School in consultation with the Center for Creative Leadership, we modeled the rhythm of the class and project based on a software project management framework called Scrum . Scrum is an iterative development framework that focuses not only on the “thing” being developed but on the team functionality. While not adopting each and every aspect of Scrum, we use several important parts that make sense for this type of project. Each iteration or “sprint” is approximately 3 weeks long. Class meetings (and hopefully other team meetings) begin with a “stand-up”. In a stand-up, students actually stand (hiding your cell phone in your lap is challenging when your standing up), and each member of the team answers three questions to the other team members:
- What have I done since the last meeting?
- What do I intend to complete before the next meeting?
- What is blocking me?
Each sprint ends with some sort of major deliverable (a presentation, a robot demonstration, etc.) One of the most important parts of Scrum, though, is the team retrospective. After the technical deliverable, the teams adjourn to another room where they spend time with a team facilitator discussing how their team is functioning, how to become a more productive team, and what the team should start, stop, and continue doing to aid in its future success.
We are now in our third semester using this framework for the course. We are seeing significant improvements in the technical success of the teams due in part to the incremental deliverables. Much of the increased success of the teams is due to the fact that they are truly learning to work together, rely on one another, and resolve their problems in a mature fashion.
Have you tried any particular project methodology from industry to manage projects and teams in your classes? If so, please post in the comments section. In future posts, I’ll expand on the various aspects of the Scrum methodology, more detail about how we have implemented it, and thoughts moving forward.