Teaching Scrum at University is challenging. Students are typically at the beginning of their career and don’t understand the challenges of communication and coordination in software engineering well. In a prior post on Why I Still Teach Scrum I had made a cryptic remark to that end and through various channels was asked to clarify the remark.
Scrum is a framework that needs tailoring for the specific situation at hand. The specific challenges of teaching Scrum at a University are, in no particular order, and most certainly incomplete:
Comparatively little practical experience of students
Widely differing capabilities as the gap between students can be large
Transient teams as Scrum projects typically last only a semester
Zero-Sum-Thinking by some students as to teamwork and grade
Scrum is an agile method (framework) that when instantiated can be rather ornate. Most developers, when I talk to them, tell me that when given a choice they would not be doing Scrum. While Scrum may have felt much lighter than the competition back in the nineties, today it weighs in as rather heavy.
Given this, I wanted to reflect on why I still teach Scrum (and have a blog post to point any of my students to).
The project management tool “RPLAN” makes it possible to plan projects efficiently and transparently. The user’s planning effort should be as small as possible. This will be achieved through a smart product which proposes further steps independently to the customer. For this purpose, RPLAN is connected to the web interface “Slack”, automating the planning process using natural language.
Arrow.js supports the user to identify the correlation between multiple contexts and a single file. We score the relation between different resources. As the result the user gets a score, which describes the probability of a connection between these data sets. This service is accessible through a REST call.
A system to test, if new data and code versions for the DB ticket booking system are valid. The system is deployed in a Docker container to be used in a continuous delivery process. The data and code versions are integrated into a VM, given to us by DB Systel, which can get booking requests and replies with the same information the DB booking site would. By validating, if these replies are what we expected, we can detect if the new code has errors a lot faster than before, thus improving overall developing speed of DB Systel.
Over the last few years, we have shifted most of our courses from traditional upfront lecturing to project-based learning. Each course consists of multiple projects with three main stakeholders: students, teachers, and industry. Using AMOS, our “agile methods and open source” software engineering course as the example, we review our course concept and discuss our experiences. We take the perspectives of the three stakeholders in turn: Achieving learning goals and performing meaningful work (students), fulfilling both an educational and an economic mission (university), and receiving a return on time and monetary investment (industry). The perhaps surprising result is that these three perspectives can work together well and make reaching each stakeholder’s goal easier.