-Studies have shown that students retain more information when learning by doing, with practical projects. After graduation, students go on to work with real world projects, which often involve more than one discipline, and the components not covered in their university courses must then be learned on the job. Interdisciplinary university projects are often hard to implement due to lack of collaboration between respective parties, as well as different work practices used in each organization involved. While many advances have been made in teaching agile development to software engineering students, members of other faculties often have different, incompatible, work practices that require structured design and testing processes. We will show how incentivizing students from such different backgrounds to work together can have a huge impact in their learning experience and analyze multiple case studies of such interdisciplinary projects. Decisions such as team structure, collaboration, interdisciplinary change management and task prioritization will get evaluated based on the necessary complexity, and good practices will be drawn based on the results of the presented case studies.
Capstone courses have had several successes in teaching
agile project development to computer science students in
universities around the world [
Different reasons can be found as to why such interdisciplinary approaches are hard to implement. Beyond the fact that the necessary project partners often have little experience working with each other, they may not even know each other and find it hard to communicate. This distance becomes even bigger when applied to student teams. Moreover, when designing interdisciplinary systems to be developed by students, some design goals present themselves, which may be in direct contradiction with each other. While it is desired for the subteams in the different faculties to collaborate and work together in order to enhance the working experience, it is essential to limit the dependency (and thus effect) that they have on each other, as it must always be assumed that part of the designed system may fail.
The following paper presents the challenges, and approaches used in the WARR Hyperloop project, and deduce from that a few lessons learned from the team at the Technical University of Munich, where an attempt was made to allow 30 students from different levels and faculties to work together, in a project that heavily involves both hardware and software components. The project involves different iterations with evermore refined design requirements. After receiving instructor approval that the proposed design is viable to build, the students ultimately construct a physical hardware prototype, which participated in an international competition. All the while the team members, who were from seven different faculties, had to work collaboratively with very tight deadlines, which made sure that each individual had the highest interest in the rest of the team completely understanding their work.
Furthermore, we also give some project management examples of when and where problems occurred during the described course, as well as which techniques were used to mitigate it. Section II describes further details on how problem decomposition into smaller tasks can reduce the impact one group of students has on another, while still ensuring that they need to work together for the integration of the entire system. We will then finish by presenting some lessons learned from our experiences. As society changes, it is increasingly important to know how to communicate the skillset learned throughout life to people from different backgrounds, and to be able to learn from the experiences from others, which means that working with people from different backgrounds can be both a teaching and learning experience to all parties involved.
interdisciplinary educational project, is how to organize the
project and team so that students from all different areas can
benefit from the interdisciplinary aspect and learn additional
material without being blocked by other team members. This
is only possible to attain with a clear team structure and
responsibility definition between sub-teams, as team structures
often define communication channels [
An example of how important such communication is, can be found in the battery management system of the second WARR Hyperloop pod, developed at the Technical University of Munich. The interior of the battery compartment had to be pressurized to about atmospheric pressure, since the cuboid shaped battery shells would not withstand the force to inflating in vacuum and thus possibly incinerate themselves.
Furthermore, the batteries power the sensors and actuators of the pneumatic system, which controls the pressure levels of the battery compartments, among other subsystems. Notice how Fig. 1. The WARR Hyperloop II Team at their team building event at there is a cyclic dependency chain between the pneumatics Tegernsee, Bavaria. The team divided into sub-teams which competed in system and the battery management system, which automati- tbougiledthinegr. the most precise and powerful catapult out of limited resources cally leads to a high information flow between the according engineers. All in all, an alternated iterative work flow can be observed, which consists of requirements being passed along e 40,000 and an additional delay of two weeks. While our from one part of the team to the next, while always ensuring experience shows that students can become very motivated to that the latter has enough action items to work on indepen- solve problems when others depend on the results of their dently. With this information cycle, not only the development work and vice versa, this may not always be possible. If a efficiency is kept high, but also reciprocal functionality of the team later in the dependency chain is prevented from working software and hardware is assured constantly. because of the results of their predecessors, this may have
While this collaborative work is great for the educational big consequences not only for motivation, but possibly also process, much attention is necessary so that it doesn’t extrap- on several organizational aspects. Therefore it is important to olate time and budget limitations. Although time constraints strengthen the feeling of belonging to the team and build up are usually given by the semester dates at any given uni- trust and respect to the others very early, for example with a versity, budget may be harder to manage. Any project that team building event as seen in Figure 1. involves (buying) hardware components inevitably requires All of these challenges go a long way to show how more money than software-only projects. How much money important communication is, but this can become quite hard actually is necessary obviously depends on the complexity when you have team members with different backgrounds, that of the project and the number of students involved, but if may understand completely different concepts under similar this complexity starts to get too big, it may make sense to nomenclature. In the history of the WARR Hyperloop team, introduce some finance and/or business students to the project, there were in total 18 different nationalities among all particto help manage and acquire any financial resources necessary. ipants.
This, in turn, adds one more interdisciplinary aspect, by having There are not only social diversities, but also differences students manage their own budget, although it could add more in experience. The study advancement of the students differ external dependencies. from the first semester of the bachelor’s degree to almost the
Our experience shows that one of the biggest challenges end of the PhD study. The high gaps in experience between
in setting up an interdisciplinary teaching project is how to collaboratively working students might seem antipathetic, but
manage the risk that inevitably remains due to dependencies it actually can be utilized to benefit the learning process of
inside and outside of the project. As any given risk can be the students, which will be discussed in the Section III.
accessed by considering its probability and severity [
For example, an external hardware supplier canceled the An example of projects where hardware design and software
delivery of multiple essential components for the prototype development are deeply combined can be found in real time
of the WARR Hyperloop II team at a late point of time. systems where dozens of sensors are needed to autonomously
As a direct consequence, the team had to quickly contact a monitor, control, and react to the environment (e.g. the
protonew supplier, which lead to a price advancement of about type of the WARR Hyperloop II team. When time is limited by
deadlines, the system has to be presented, verified and assessed
[
We mitigated the lack of contact between various faculties by forming sub-teams, which are composed of software engineers as well as hardware designers. The flawless integration of both software and hardware components in the end product is only possible when direct communication between software developers and hardware designers is established, easiest archived by putting them in a small group of people who are in constant interaction, analogously to communication flows found in Scrum projects. A good example would be the electronics sub-team of the WARR Hyperloop III Team, which not only included electrical engineers who worked on the printed circuit board designs, and mechanical engineers, who worked in physical structure integration, but also of computer scientists, who developed the system’s architecture. This was only possible due to the big variety of studies in the team. Figure 2 reflects this.
people is also used in agile projects [
Problem decomposition and team subdivision reduces the
negative reaction of requirements adjustments by resulting in
a minor interaction in terms of communication and
coordination and supporting adaptability to external changes [
A good example for the importance of interchangeable
and/or excludable subsystems is the first iteration of the
WARR Hyperloop pod prototype. The so called Pusher Vehicle
built by SpaceX promised to accelerate the student’s prototype
to speeds up to 100m/s, which would allow for magnetic
levitation using electromagnetic suspension [
Nevertheless agile methodologies used in software
engineering are not always applicable in hardware design and
manufacturing due to limitations in hardware adjustments.
Therefore a forethought technical architecture and real time
management of risks are of crucial importance. As stated in
[
That said, the terms cohesion and coupling in [
Combining the incremental hardware design approach and
the iterative agile software development life cycle adds to
the student’s understanding of project management. These
principles are often taught to the students only based on
theory, and when a student then receives a good grade in
the final of the lecture, it is said that he/she has understood
the subject material and learned something useful. Although
this approach certainly has its advantages when referred to
software management techniques and methodologies,
”learning” in the sense of the acquisition of knowledge or skills
does not simply consist of immediate concrete experience as
the basis of observation and reflection [
Especially in an interdisciplinary context, different
people behave differently when it comes to meeting deadlines,
working in a team and showing initiative in group problem
solving. For example, while one student might only attend the
weekly team meetings and finishes his tasks solely at home,
another one needs the physical presence to be up to date with
the changes happening to the project. This self identification
only happens when truly experiencing the experiments inside
an interdisciplinary team [
As stated in Section II, experienced and unexperienced students were put together in small sub-teams, which were composed of both hardware and software components. An important sub-team, for example, was the propulsion mechanism, composed by both mechanical engineers and electronics. The business team, on the other hand, was composed by business students responsible for sponsoring, and web-developers responsible for the website.
By creating a practical learning environment similar to a
classroom, not only the students with little to no project
experience evolve individually, but also the lead of the
subteam in the role of a teacher [
In conclusion, in order for a multidisciplinary team to function together, it is essential that each team member respects the roles and issues of the others. By decomposing big systems into smaller sub-problems, we were able to have each subteam work on its own component, and always have continuous feedback about the complete system. We have learned, that the right composition of the team is necessary for it to function properly. The ideal sub-team configuration contains not only students from different faculties and backgrounds, but also with different levels of experience, which can help balance the learning experience for everyone involved.
In addition, techniques used in agile methodologies provide a good initial proposal of how to have these different teams collaborate with each other, as well as the structure of the emerged sub-systems in the system. Furthermore, it is of importance to define the grades of coupling and cohesion to guarantee a modular enough system design, while keeping the developing time low. Together with prospective risk management, the achievement of the project goals is thus best secured. By encouraging teams to work together and giving them goals that are dependent on complete collaboration, it is possible to ensure that every participant is able to experience new disciplines in a motivating manner.