Interdisciplinary System Courses – Teaching Agile Systems Engineering Andreas Seitz, Mariana Avezum, Bernd Bruegge Stefan Wagner Chair for Applied Software Engineering Institute of Software Technology Technische Universität München University of Stuttgart Munich, Germany Stuttgart, Germany seitz@in.tum.de, m.avezum@tum.de, bruegge@in.tum.de stefan.wagner@iste.uni-stuttgart.de Abstract—With the advent of technologies like the Internet of The ISC concept addresses the following three challenges: Things, Industry 4.0 and Cyber-Physical Systems, many software 1) Interdisciplinary teams with different skill sets, ways of engineering courses turn into system engineering courses. Recent advances in technologies such as 3D printing and low-cost working and terminology micro controllers enable to teach agile hard- and software co- 2) Producing hard- and software prototype system in a few design in system engineering courses. In this paper, we describe days up to a few weeks Interdisciplinary System Courses (ISC) – a teaching approach 3) Solving real problems by integrating industry as cus- based on interdisciplinary projects, light-weight agile techniques tomer and domain experts and solving real problems by integrating industry customers. We describe our experiences from an exploratory case study In order to achieve these goals, we will present how we where we applied ISC in a two-week international summer school implemented ISC through a 2-week course, overcame commu- with a customer from the aerospace industry. We derive a set of nication problems, and taught the participants to implement hypotheses on the effects of ISC. a system consisting of both hardware and software compo- Index Terms—interdisciplinary, teaching, agile, hardware, soft- ware, systems course nents.The paper is structured as follows: Section II deals with the basics of ISC and shows relevant fields of research. In I. I NTRODUCTION Section III, we explain the concept of ISC and its structure. In the case study in section Section IV, we show how we With the advent of technologies such as Internet of Things, applied ISC in a two-week summer school. The exploratory Industry 4.0 and Cyber-Physical Systems, systems engineering study enabled us to evaluate the concept of ISC. We present integrates evermore software engineering aspects. These sys- the general findings and derived hypotheses. The paper ends tems do not only consist of software but also various types with the conclusion in Section VI, where we summarize the of hardware. This means that we not only have software contributions and give an outlook on future work. engineers in the team but require interdisciplinary work, whose development process often is different than software. II. F OUNDATIONS At the same time, these software/hardware systems are more An established approach for the introduction not only of and more under the same pressures as pure software systems software engineering but also of concepts such as Scrum to be able to innovate quickly in short cycles. In software are capstone courses, which have been around for a while engineering, this gave birth to agile software development, [4] [5]. While these have been known to have good results, whose application to hardware development [1]–[3] is still in introducing interdisciplinary systems engineering and hard- its infancy. This makes working together in an interdisciplinary ware components can directly conflict with Scrum concepts project difficult. such as incremental and continuous iterations. To bridge these One approach to reduce this challenge in industry is to challenges, we look into relevant foundations to support the familiarize systems engineering students with these agile organization of the ISC course. concepts still in their studies. To let participants already experience these difficulties and to work on making agile hard- A. Systems Engineering Teaching and software development a reality, we propose the format After the publication of the Agile Manifesto in 2001 [6], of Interdisciplinary System Courses (ISC). The idea is to put different frameworks appeared as how to implement these participants with different backgrounds – such as computer values in practice, the most common of which is Scrum. While science, electrical engineering and mechanical engineering – these frameworks spread both in software engineering and in in a realistic project setting and let them work together in teaching, the shift has been slower in hardware development. an agile way. The format of a summer school outside normal Hardware development has traditionally used development university constraints allow us to work together in a focused processes that go deep into the requirement elicitation, and way while bringing in participants with various backgrounds many industries use the V-Model as it allows the system and and experience levels. its interfaces to be completely defined before the system is ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 11 assembled [7]. This critical need of the industry has influ- participants to present formal UML models can present a good enced systems engineering education, and university capstone learning opportunity. courses usually follow the same development process. A Furthermore, they are also presented with informal methods, review of engineering design capstone courses can be found which serve the same communication purpose, while giving in [8]. the participants a greater creative freedom, and sometimes These two different approaches pose a challenge for in- being easier for industry clients to understand. The Tornado terdisciplinary courses as participants may not be used to Model suggests that participants prepare a Software Theater communicating or working with a different development pro- of their results [12], which presents an opportunity to record cess. While there have been teaching projects where these the presentations, and use it as a communication mechanism differences are managed, such as [9], the system developed for all project stakeholders. in that study was a highly complex one, which makes it harder to reproduce the situation. As for industry, it has III. I NTERDISCIPLINARY S YSTEM C OURSES (ISC) also tried to adapt agile practices for hardware development, In the following section we describe the concept, structure however with mixed results [10]. One agile framework that and core values of ISC. deals with different development cycles, and the integration of the components thereof, is Scrum of Scrums. A. Features & Design The aim of ISC is to bring together participants from B. Scrum of Scrums different disciplines to work together on a challenging prob- Systems that involve components from multiple disciplines, lem. The chosen course format is not a traditional one but and both hardware and software subsystems, will unavoidably a condensed course, which helps the organisational aspects of involve a certain complexity and larger groups than are usually having students from different degree programs work together. found in Scrum teams. To adopt Scrum to larger teams, the The case study presented in Section IV takes place during Scrum of Scrums method was introduced. the semester break and is aimed at motivated and talented As the name suggests, this consists of layering different students who want to expand their horizons. ISC is not part of Scrum teams into a new Scrum group, where representatives a curriculum. Students can apply for this programme and will of the lower-layer Scrum teams report their status in a second then be selected based on their performance and a letter of daily Scrum meeting [11]. This approach helps decompose motivation. Travel and accommodation costs will be covered not only the developed system into smaller components, but for the participants. also the dependencies between the different teams and people ISC is characterized by the following goals and design involved. At the same time, it also ensures that the entire decisions: complete team is kept up to date with the project’s status. (1) Interdisciplinarity: The core of ISC is interdisci- Big dependencies on other components is a critical aspect plinarity. It is no longer sufficient for participants of individual of hardware development, and thus, reducing these as much disciplines to solely work in their one domain. It is necessary as possible makes it easier to introduce a faster development for them to be able to look beyond their subject areas and process. Furthermore, the Scrum of Scrums framework also collaborate with other participants in other subject areas. Novel allows for different development cycle lengths for each of technologies and the fusion of hardware and software require the subsystems involved in the project, which then allows the cooperation across disciplines. The challenge here is different hardware and software systems more flexibility in planning knowledge and processes. In addition, projects are becoming for a development phase that better suits their capabilities and more and more demanding and cannot be realized with the needs. knowledge of a single discipline. (2) Agile Light-Weight Development Process: With re- C. Tornado Model gard to the process, we deliberately opted for a loose, adapt- When working with different independent teams, it is es- able and flexible process. We believe that this freedom can sential to keep a close eye on system integration. As will be make cooperation more effective. In spite of all this freedom, presented in Section IV, our summer school case study used there are also fixed deadlines and delivery times that the the Tornado Model [5] to achieve this. It focuses on using participants have to meet. In ISC we apply the concept of a scenario-based development approach, useful for teaching Chaordic Learning [13]. We give the participants the freedom courses, where participants work toward a presentation at the to organize themselves, but create order through punctual end of the project. structures. The participants are expected to produce a light- By selecting a visionary scenario that presents features of all weight prototype of the system by the end of the course. components in the system, not only does a complete prototype (3) Challenging Problem of Industrial Partners: To be demonstration become possible, but also the minimal required able to challenge and motivate the participants of ISC, a real interfaces become clear. To further understand and correctly problem with innovative solution possibilities is required. The implement these interfaces, students from each sub-team are solution must require technical expertise from different fields tasked to define and document these in system-wide models, and must be dynamically extensible. ISC requires industry which can be accessed by all sub-teams. Encouraging the partners to formulate and define the problem on the basis of ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 12 their expert knowledge. Furthermore, they should be available distractions can be minimized, and the participants can fully for the preparation meeting, design review and final customer concentrate on dealing with the problem. acceptance test. Industry partner integration is also seen as a In addition to the working environment, the infrastructure motivation source as the participants know that their work will is also important. ISC assumes that participants who have be further used. everything they need to work can also work better and more ef- ficiently. Depending on the problem statement, this can imply B. Skills & Techniques special hardware and software. Since ISC involves elements To achieve these goals, the participants required core skills of systems engineering, it also covers areas such as agile and tools which were taught throughout the course. manufacturing. This requires special infrastructure such as 3D- Communication & Soft Skills: An important aspect to printers and hardware prototyping material. Micro controllers address the challenges of interdisciplinary is efficient commu- such as Arduinos and RaspberryPIs are often necessary to form nication. The terminology and prior knowledge of the partici- the interfaces between the hardware and software components. pants are initially heterogeneous. Their different backgrounds D. Structure result fundamentally different ways of working. While com- puter science and software engineering participants are usually ISC is divided into 3 phases: (1) Preparation Phase, (2) familiar with agile methods, other participants most often Development Phase and (3) Integration Phase (cf. Figure 1). have no such experience, and thus it is important to provide them with a relevant theoretical overview and materials, in Preparation Design Customer Kickoff Acceptance order for the necessary terminology to get better understood. Meeting Review Test Furthermore, ways and means must be found to facilitate cooperation between the disciplines. Videos as Communication Models: A saying goes, a 12 weeks 1 week 1 week picture says more than a thousand words. In ISC the motto Preparation (1): Research, & Component Preparation Development (2) & Integration (3) is: a video says more than a thousand words. In the course of ISC, we strongly rely on the use of videos as communication Fig. 1. Timeline of ISC: The preparation takes place before the actual course models. starts. During the period of the ISC course, development of the subsystems is first carried out and then integrated. First, it supports the problem description. Today, the web offers a variety of videos that can be used to illuminate and In the course of ISC different events with specific meaning underscore problems, especially useful for cases where logistic are planned. We explain in detail the different events: or organisational constraints make it hard for the students to Preparation Meeting: The Preparation Meeting is the first physically see the problem. Many problems today are solved time that the participants of an ISC course as well as the by analog or conventional approaches, which can be shown to organizers and industry partners come together. The aim of the students through videos. In order for the students in ISC the meeting is to get to know each other, to understand the to reach their goal and tackle these problems digitally, it is problem, and to distribute work packages for the participants. important that they understand the problem domain first. The industry customer presents the problem to be dealt with Second, videos are also used to visualize solution concepts. in the form of scenarios. Before this meeting, the industry The participants of ISC record their ideas in videos and share partners and organizers jointly create an initial top-level design them with their team members and project partners from of the architecture which is a key discussion point of the industry. meeting. This architecture is then presented to the participants On-Site Application Domain Expert: The participants of of ISC for the first time. Starting from the architecture, ISC are solution domain experts but usually have little prior technological requirements and subsystem are defined. These knowledge of the application domain. To close this gap, ISC form the basis for the teams that have to complete preparation relies on the fact that an expert of the application domain tasks in the next 12 weeks, and thus the initial team allocation is available for questions. This expert can thus influence the is done during the Preparation Meeting as well. developed solutions and ensure that the developed systems Kickoff: After the arrival at the location where ISC takes also meet expectations. In direct, non-formal communication, place the Kickoff Meeting happens. The problem statement the requirements of a system can be constantly updated and will be discussed in more detail on the spot. To support team checked. Having this expert physically present during the ISC building and create a nice atmosphere, an ice breaker is done also ensures efficient communication channels. with all participants. Ideally, the icebreaker can be based on the topic to be worked on and should clarify the motivation and the C. Infrastructure & Environment understanding of the problem. Subsequently, each sub-team An essential part of ISC is the working environment and presents the results of the project work they have achieved in infrastructure. ISC intends to take all participants out of the past 12 weeks during preparation. The focus will be on a their familiar working environment and to accommodate them demonstration of what has already been achieved and how it together in one place for a certain period of time. This way, should be incorporated into the common vision. ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 13 Design Review: The Design Review takes place halfway scenario that can be realized in the short time frame of the through the ISC course. All participants, application domain course and can also be demonstrated. Action items then result experts, and organizers come together to discuss the progress from the demo scenario. These should be realizable within of the project. Depending on their time availability, industry one day. Unlike Scrum, the daily result of ISC is not a partners may attend this or not. The focus is on design. Each potentially shippable product but either a demonstration or a sub-team will present its progress and any challenges they may video demonstrating the functionality. face and give a glimpse of what they expect to achieve in the time remaining. IV. C ASE S TUDY In preparation for this presentation, a video trailer can be In order to implement the objectives described in Section III, produced. This trailer serves as a means of communication Chaordic learning [13] was used to address a problem state- between participants and industry partners, to synchronize the ment presented by an aerospace industry partner. While the vision of both parties. The trailer can also be sent to the ISC instructors did provide general topics to be researched industry partner in case they could not attend the meeting. before the 2-week course and divided all the participants into Customer Acceptance Test: Finally, there will be a joint sub-teams, the exact definition of who was responsible for event: the Customer Acceptance Test. This event serves to what in each sub-team, which technologies to use, and what present the final results achieved by the participants and to tasks to prioritize was self-organized by the participants. have them accepted by the customer/industry partner. The form In the Kick-off meeting the participants were presented with of the presentation is left to the participants. While slides can a problem statement from an aerospace industry partner and be used for communication, the main focus is to demonstrate a used that as a common reference to set the tasks developed demo scenario and the functionality of the developed system. during the 2-week course. The industry partner wishes to assist rescue agencies such as the red cross after any type of natural E. Process disaster, and thus the ISC participants should develop a Multi Between the fixed events, ISC provides a lightweight agile Operational Drone Collaboration Platform (MODCAP). process. It is divided into three sprints. Sprint 1 between the Problem Statement: Agencies such as the Red Cross need Preparation Meeting and the Kickoff Meeting, Sprint 2 be- to coordinate and plan relief efforts after disasters. The focus tween the Kickoff Meeting and the Design Review, and Sprint of the project developed in our ISC implementation was to 3 between the Design Review and the Customer Acceptance collect and analyze data gathered by any available fleet of Test. During ISC, a typical day starts with a group breakfast, drones in disaster areas. followed by a Daily Stand Up Meeting. MODCAP is a platform that orchestrates a collection of drones to perform search and rescue missions after natural Team 1 Action Items disasters. Furthermore, the data collected by the platform Daily Event should be used to map geographical changes caused by these Wrap Up disasters, as well as to help in the survivor rescue operations. Visionary Scenario To further assist the survivor rescue operations, the MODCAP Team 2 Scenario Demo 1 Day platform should also allow for the modular integration of any Demo Team 3 Shippable smart wearable device the victim may be using, such as Smart Stand Up Video Watches, or any transceivers, as is common for skiers to use on avalanche-prone areas. Fig. 2. ISC Process: Starting from a Visionary Scenario, this is broken down A. Infrastructure & Environment to a Demo Scenario. This demo scenario will be divided into action items which will be processed by the different sub-teams. Daily Scrum Meetings The ISC concept was implemented during a 2-week course take place in the morning with each sub-team. where internet and hardware accessibility were limited, which is why most of the necessary infrastructure was transported by In this meeting everyone individually reports the progress the organizers to the location. In this section, we explain how of the previous day, the impediments they have and promises the environment and technical infrastructure made available what they want to achieve in the course of the day. In this con- influenced the implementation of the course. text, it is also worth mentioning that between the working days To facilitate the adoption of agile manufacturing techniques there are also days for leisure time. The combination of work and simultaneously keep a light-weight development process, and leisure is important since it motivates the participants. rapid prototyping equipment was made available to all of The process is visualized in Figure 2. While the division into the participants. This includes, but is not limited to, a 3D- sub-teams can be loosened, it is important for each participant printer and prototyping electronics such as Raspberry Pis and to have well-defined tasks, that do not rely too much on other Arduinos. Since the problem statement implemented by the subsystems, as that would hinder the agility of the process. The participant’s had some drone components, it was important visionary scenario describes the functionality to be provided for the available electronics to be able to interface to the by the future system [14]; this can be tailored to a demo drone’s software development kit. This hardware allowed for scenario. The demo scenario is an excerpt from the visionary the different teams to quickly test and iterate their components. ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 14 One example of hardware iteration can be seen in the scoop mechanism developed for the drone. The idea behind the mechanism was to modularly connect a component to the drone so that samples of the areas affected by the disaster could be collected. As this mechanism was to be attached to any available drones in the area, it was important to keep it as modular as possible, but also stable enough to grab any necessary samples of the area. To solve this, the participants initially designed a sample mechanism, designed for a DJI Phantom 4, however, the first iteration of the component did not really fit the drone. By the end of the first iteration, they had adjusted the size and tested the component in flight, however, the stability of the system proved to be insufficient to actually snatch any sample from the ground. This was then successfully fixed in the following phase of the project. An important aspect of agile development is the communi- Fig. 3. Work Environment cation between developers. While this is classically supported through the use of online issue tracking tools, this was not possible due to the limited internet connectivity of the location where we carried out ISC. Furthermore, the fact that all participants were located in the same place meant that they could exchange much information through informal meetings, which greatly helped communication and fast decision making. To allow all participants to keep track of the system’s status, pen and paper were used in the place of online issue trackers, and a Kanban board with Backlog, In Progress, and Done columns was set up, as can be seen in Figure 4. Post-its were used for each task, where the exact action item and person responsible for it were written down. At both the Design Review and Customer Acceptance Test Fig. 4. Kanban with Pen & Paper milestones, a system scenario was presented. In the Design Review, the status was discussed between all participants and the organizers, and a video trailer was used to demonstrate we believe that a team assignment based on personal pref- the scenario envisioned by the end of the two weeks. This erence increases team motivation and allows the participants really helped the participants to know which tasks to focus on the opportunity to learn new skills based on what they enjoy. during the second week of the project, as these were the exact Furthermore, the fact that this team assignment was made features to be demonstrated to the industry partner client at several weeks before the kick-off meant that the participants the Customer Acceptance Test. had time to research, prepare, and learn any fundamental skill It should also be noted that our industry partner appreciated sets that would be required during the two development weeks. the video trailer, as it allowed them to easily explain to objectives of the system to several other stakeholders inside To get everyone onto the same page as far as what was of the company, who were not involved in the process. possible or not during the two weeks, right on the first day of the ISC, each sub-team presented their research results. B. Team Work These were short 10-15min presentation from each sub-team, The fact that the ISC participants came from different study where some initial feedback was already provided as to how courses meant that they individually had very different skill far their expectations were realistic. These presentations lead sets. Furthermore, the Problem Statement presented to them to important discussions on necessary frameworks, interfaces, required different backgrounds and a considerable amount of and further capabilities. We have deliberately not defined a both hardware and software components. format here in which way the presentation should take place, As presented in Section III, all participants of the summer to allow for self-organization of the different teams. school met for a Preparation Meeting a few weeks before the Another activity that was important at the beginning of the Kick Off. It is relevant to note that the team assignment that ISC was the Ice-breaker. The participants simulated a search took place in the Kick-Off Meeting, was not done based on and rescue operation, with the use of an analogue transceiver. skill set, but on the participant’s personal preference. This helped them not only bond more and overcome their While a skill set based assignment could make the develop- different background, but also gave them insights in the current ment easier (and perhaps even produce a better final system), state of the art of the systems they would be working on. ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 15 V. C ASE S TUDY E VALUATION The participation in the Ferienakademie improved my skills in... 6 In this section, we will look at the exploratory study Strongly Agree ------------ Strongly Disagree we conducted during the case study and evaluate what the 5 participants thought of the ISC. Based on a questionnaire sent to the participants, we present the results below and discuss 4 the participants’ feedback. A. Objectives & Design 3 We carried out an exploratory study and collected data 2 from the participants by means of a questionnaire to verify our assumptions as well as to validate whether the goals 1 of the applied methodology are met. The questionnaire was distributed to the participants shortly after the Design Review, System Design Programming Prototyping Communication Team Work around halfway through the course. The questionnaire focuses on the following research questions: Fig. 5. Skill Improvement Box-Plot 1) Interdisciplinarity: Effects of different backgrounds of participants on how they work together. 2) Agile Light-weight Process: Effects of the chosen en- 2) Interdisciplinarity: The participants overwhelmingly gineering approach regarding high-level scenarios, daily stated that the communication with participants from other scrum meetings, demos, simple architecture descriptions areas was easy (median = 6, min = 2, max = 6). We also 3) Software Theater: The effects and implications of using asked how communication on the sub-team level worked. videos during the course to visualize problems. The Communication within the sub-teams (median = 5, min = 2, videos serve as a communication model between the max = 6) as well as with the other sub-teams (median = 5, participants and the industry partners. min = 1, max = 6) were seen as working well. The open question about describing the challenges and B. Questionnaire problems of working with fellow participants, however, reveals Altogether we distributed the questionnaire to 19 partici- challenges: The participants report that it was difficult to pants, all of whom answered. The questionnaire contains 29 define a common understanding of the tasks and problems questions which are divided into 4 free-form questions, 24 (e.g. “differing implicit assumptions”). We also observed a Likert item questions and 1 multiple-choice question. The heterogeneous previous knowledge that could be overcome questions are divided into the subject areas: interdisciplinarity, through the course of time (“Unclear what skills people have”). process model and utilization of videos within the course. Yet, several participants also reported no problems. The applied Likert scale ranges from 1 (strongly agree) to While the ISC structure probably contributed to the in- 6 (strongly disagree). The mean and median values in the terdisciplinary communication flow, there are further relevant following section refer to this scale. aspects that may also have avoided problems in this regard. C. Results The free-text answers of the questionnaire indicate that the location played an important role in relaxing the students, and In the following, we describe the answers to the general that the free time activities helped them bond together. While and to each research questions, for which we then propose an ice-breaker is part of the ISC structure, currently no data is hypotheses that are suggested by the data. 1) General Questions: Of our ISC participants, 26% have available whether that was enough to reduce communication never previously worked with participants from other depart- problems, or to what extent other activities contributed com- ments or disciplines. For 16% it was their second collaboration pared to it. The importance of the environment, however, is and 58% had already collaborated once with participants of supported by the fact that all participants of the questionnaire other departments or disciplines in projects before ISC. agreed with the statement ”You could work well in the created Figure 5 shows the self-assessed learning of the participants working environment (atmosphere, room, food).” with regards to communication, programming, prototyping, While the cause behind the improved interdisciplinary com- system design and team work. A learning experience could be munication may be disputed, our data indicated that cross established across all points. However, it is also clear that ISC team communication in the ISC worked well. Interdisciplinary is not a programming course, but a systems engineering course communication and work is commonly problematic in other where the focus on interdisciplinarity and team collaboration contexts, for example, because of misunderstandings [15], is more important than the actual implementation. [16], and we see little problems due to interdisciplinarity in The answer to the question whether the participants would ISC. Therefore, we formulate the following hypothesis: recommend the ISC summer school to other participants is extremely clear. Here, 16 out of 19 participants absolutely Hypothesis 1: The ISC concept reduces interdisci- agree and none of the participants disagrees with this opinion. plinary communication problems. We regard this as a success of the overall concept. ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 16 3) Agile Light-Weight Process: We also evaluated the ap- earlier the actual values would have been received earlier, and plied agile process. The whole process was considered suitable perhaps the system could have delivered a better performance. for the project (median = 5, min = 3, max = 6). In the free text answers, the participants suggest that some of the meetings Hypothesis 2: System iterations support development, lasted too long. There are also mentions that an earlier focus but complete subsystems decoupling hinders integration. on integration would be useful. When looking at the system iterations in particular, par- ticipants agreed that these were relevant to the development 4) Problem Statement Understanding: Due to the different process (median = 2, min = 1, max = 4). Given the fact that background from the participants, common understanding of students outside of the software engineering environment had the problem statement was of special importance. In the limited previous access to agile processes and iterations, this questionnaire, we asked how the different communication can be seen a meaningful contribution of ISC. Figure 6 shows approaches facilitated this. We initially communicated the the detailed distribution of answers. problem in written form as a problem description. 74% of the participants agreed on the importance of this. System iterations were an important part of the development The ice-breaker activity previously mentioned, further process. served the double function of showing the students how search 8 and rescue operations are manually done today. It is relevant to 7 note that this was in the beginning of the course, and thus, the 6 general understanding of the problem was somewhat vague. By 5 providing the students with a transceiver to find hidden objects 4 in a field, the students both had fun, and learned something 3 2 about the real world use of the system they were to develop. 1 The introduction of software theater aimed to further sup- 0 port the understanding. The participants also watched videos Strongly Agree Slighlty Slightly Disagree Strongly that showed them how search and rescue operations currently Agree Agree Disagree Disagree function, and this showed to be a good communication tool. 78% of the participants approved of the use of video tools. Fig. 6. System Iteration Value The free text answers suggest that participants considered Problem Statement Understanding the meetings communicating the status as useful and impor- 12 tant. It is however relevant to note that not all days spent 10 Number Occurrences during the ISC were work days, and there were some entire 8 leisure days as well. In these cases, the morning meeting in 6 the following day was sometimes criticised, as the participants 4 had not achieved any work progress during the leisure day, and the meeting content thus became repetitive. 2 One aspect of agile development that was not adequately 0 accessed in our evaluation were the problems and benefits Strongly Agree Agree Slighlty Agree Slightly Disagree Disagree Strongly Disagree of the Scrum of Scrums element. While both internal sub- Textual Description Manual Activity Videos Domain Expert team meetings and meetings with all sub-team took place, it is possible that the latter happened with too many participants, thus diminishing it’s efficiency. Perhaps a more rigorous, with Fig. 7. Value of Each Understanding Technique fewer people, implementation of the Scrum of Scrum process could have aided in the integration problems, however, it Figure 7 depicts the student’s assessment of the usefulness would likely also have diminished the learning effect, by of each of the different techniques used. As can be seen, limiting the number of students receiving input from other the tool which showed most useful for problem statement sub teams. understanding was the exchange with the expert from the Furthermore, the questionnaire also suggest insights as to application domain (median = 2, min = 1, max = 4). While why the system integration became problematic at the end, this may also be due to the fact that the remote location of even when the iterations were evaluated as useful. While the course made the expert a more reachable resource, wee the interfaces between each sub-team was defined, and the postulate that this finding may perhaps be generalized. participants did know what they had to deliver for the demo- scenario, the data received from the external drone control Hypothesis 3: Exchange with a domain expert encour- library was different than expected, and at the end of the ISC ages system understanding and problem solving. there was not enough time to fix this. Had integration begun ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 17 D. Discussion The paper explains the concept of ISC to make it feasible All in all, we can say that the assumptions we have made for other universities and organizations to apply the method. regarding the ISC concept are working out well. We discuss We plan to continue running ISC courses in the coming years the three goals described in the beginning and the feedback and want to apply the knowledge and experience to further from both the participants and industry partners. improve the teaching of these innovative course formats. As far as interdisciplinary teams go, both the quantitative R EFERENCES and qualitative feedback from the participants show that they [1] P. M. Huang, A. G. Darrin, and A. A. Knuth, “Agile hardware and learned how to communicate with people from other back- software system engineering for innovation,” in Aerospace Conference, grounds. Our industry partner also mentioned that the fact 2012 IEEE, pp. 1–10, IEEE, 2012. that participants from different disciplines participated in the [2] T. Punkka, “Agile hardware and co-design,” in Embedded Systems Conference, 2012. project as interesting for them. [3] S. Wagner, “Scrum for cyber-physical systems: a process proposal,” in At the end of ISC, the state of the developed system was 1st International Workshop on Rapid Continuous Software Engineering, only partially working. While the individual sub-teams mostly RCoSE 2014, pp. 51–56, ACM, 2014. [4] V. Mahnic, “A capstone course on agile software development using achieved their goals, the integration process required more scrum,” IEEE Transactions on Education, vol. 55, no. 1, pp. 99–106, time than was available in the end, thus resulting in one part of 2012. [5] B. Bruegge, S. Krusche, and L. Alperowitz, “Software engineering the demo scenario not working. While this was of concern to project courses with industrial clients,” Trans. Comput. Educ., vol. 15, our industry partner, who was interested in the actual achieved pp. 17:1–17:31, Dec. 2015. results, it was not critical for the participant’s view, as they [6] K. Beck, M. Beedle, A. Van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, et al., did learn from both the process and the non-performance. “Manifesto for agile software development,” 2001. Last but not least, the collaboration with our industry partner [7] A.-P. Bröhl, Das V-Modell: Der Standard für die Softwareentwicklung proved to be motivating for the participants. The visit from the mit Praxisleitfaden. Oldenbourg, 1993. [8] A. J. Dutson, R. H. Todd, S. P. Magleby, and C. D. Sorensen, “A review industry representatives in the Client Acceptance Test also was of literature on teaching engineering design through project-oriented a good opportunity for the participants to understand how these capstone courses,” Journal of Engineering Education, vol. 86, no. 1, systems are developed and considered in an industry context. pp. 17–28, 1997. [9] L. Boskovski and M. Avezum, “Combining hardware and software While the results of our case study can only be generalized development: A case study on interdisciplinary teaching projects.,” in with caution, they do suggest that the approach presented by Software Engineering (Workshops), pp. 12–15, 2018. ISC can stimulate more effective interdisciplinary teaching. [10] M. Glas and S. Ziemer, “Challenges for agile development of large systems in the aviation industry,” in Proceedings of the 24th ACM SIG- VI. C ONCLUSION PLAN conference companion on Object oriented programming systems languages and applications, pp. 901–908, ACM, 2009. In this paper, we present an approach to teach Interdisci- [11] L. Faria, “Scrum of scrums: Running agile on large projects,” Obtenido plinary System Courses. In a case and explorative study, we de scrumalliance. org, Junio, 2013. [12] S. Krusche, D. Dzvonyar, H. Xu, and B. Bruegge, “Software theater show the applicability of the method. ISC focuses on the three - teaching demo-oriented prototyping,” ACM Trans. Comput. Educ., core areas interdisciplinarity, lightweight agile development vol. 18, pp. 10:1–10:30, July 2018. process and real problem solving by having an industry part- [13] S. Krusche, B. Bruegge, I. Camilleri, K. Krinkin, A. Seitz, and C. Wöbker, “Chaordic learning: A case study,” in Proceedings of ner. The interdisciplinary aspect is achieved by focusing on the the 39th International Conference on Software Engineering: Software parallel development of hardware and software components, Engineering and Education Track, ICSE-SEET ’17, (Piscataway, NJ, the communication between individual sub-teams as well as USA), pp. 87–96, IEEE Press, 2017. [14] B. Bruegge and A. H. Dutoit, Object-Oriented Software Engineering collaboration between these. Using UML, Patterns and Java. Prentice Hall, 2009. The case study and its evaluation show that the concept is [15] E. Cooley, “Training an interdisciplinary team in communication and applicable and adds value for both the participants and the decision-making skills,” Small group research, vol. 25, no. 1, pp. 5–25, 1994. industrial customers. Although the developed system leaves [16] T. W. Reader, R. Flin, K. Mearns, and B. H. Cuthbertson, “Interdis- room for improvement, the realization of ISC and knowledge ciplinary communication in the intensive care unit,” British journal of gained by the participants has proven to be a success. anaesthesia, vol. 98, no. 3, pp. 347–352, 2007. ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 18