Erfahrungsbericht Agiles Studieren im Fach Praxis der betrieblichen Informationssysteme

Nachdem ich nun schon einige Erfahrungen mit der Methodik Agiles Studieren sammeln konnte, ist es nun an der Zeit, einen weiteren Erfahrungsbericht zu schreiben. Erfahrung konnte ich mit der Methode nun in zwei Fächern, Programmieren und Praxis der betrieblichen Informationssysteme (PBI), sammeln.

Beide Veranstaltungen unterscheiden sich auf Grund ihrer Inhalte stark. Während Programmierung ein Fach mit hoher Methodenvermittlung ist, ist PBI eher ein Fach, bei dem vorhandenes Wissen übergreifend verknüpft werden muss. Durch die Änderung unserer Studienordnung wurde PBI als neues Fach aufgenommen. Dies ermöglichte mir, die Veranstaltung komplett neu zu konzipieren und gleich auf Agiles Studieren auszurichten. Bei der Planung der Veranstaltung habe ich mich entschlossen, die grundsätzlich in Programmierung angewandte Methode leicht abzuändern und diese in PBI anzuwenden.

Folgende Änderungen wurden im Vergleich zu Programmieren vorgenommen:

  • Reduktion der durchzuführenden Lernthemen (Lernstories), aber damit auch Erhöhung des Umfangs pro Lernstorie.
  • Keine Bereitstellung von Unterlagen in Form von PowerPoint Slides oder ähnlichem.
  • Änderung des Reviews von abfrageorientierter Überprüfung hin zu gemeinsamen Lösen von Problemfällen.
  • Ausrichtung der Klausur auf den Stil des Reviews.

Die Reduktion der Lernthemen konnte vorgenommen werden, da bei PBI im Vordergrund weniger die Vermittlung von neuen Wissen stand, sondern vielmehr das Fach dazu verwendet werden sollte, das monolithische Wissen aus Veranstaltungen der vorangegangenen Semester in diesem Fach miteinander zu kombinieren. Damit dienen die Lernthemen dazu, das individuelle Wissen einzelner Personen in der Gruppe aufzubereiten und miteinander ein übergreifendes Verständnis über betriebswirtschaftliche Informationssysteme zu schaffen. Ziel der Reduktion der Lernthemen war den Studenten, durch eine geringere Anzahl unterschiedlicher, kleinteiliger Lernstories mehr Freiraum für Gruppendiskussionen zu schaffen.

Die Entscheidung, keine Unterlagen, ja sogar keine Literaturangaben, für die einzelnen Lernstories bereitzustellen, basierte ebenfalls auf der Überlegung, dass bereits vorhandenes Wissen verknüpft werden sollte. Während der praktischen Arbeit zeigte sich aber, dass häufig Wissen nachgeholt werden musste, da der Lehrstoff aus vorangegangenen Veranstaltungen nur noch teilweise vorhanden war. Dadurch waren die Studenten bei einzelnen Lernthemen etwas verunsichert, da sie sich nicht sicher waren, ob Sie „die richtigen“ Informationen erarbeitet hatten. Eine Verbesserung wäre sicherlich, die Lernstories um mehrere Literaturangaben anzureichern.

Eine wesentliche Änderung für diese Veranstaltung war die Art wie der Review abgehalten wurde. Der Review in Programmierung glich einer Abfragerunde. Zufällig wurden aus den einzelnen Teams einzelne Personen ausgewählt und auf die Bearbeitung der Tickets geprüft. Diese Vorgehensweise diente vor allem dazu, den Studierenden einen Spiegel über den aktuellen Wissensstand zu zeigen. Leider hatte diese Vorgehensweise auch einen massiven Nachteil: Wurden die Themen schwieriger, nahm auch die Anzahl der Studierenden im Review ab.
Dementsprechend war ich der Meinung, man müsste den Review von einem negative behafteten Format, wie einer Abfrage, in ein Format bringen, dass der Klausur und der Gruppenarbeit ähnelt. Dementsprechend entschloss ich mich, den Review in Form einer virtuellen Unternehmensberatung aufzubauen. Zu jedem Review habe ich passend zu den bearbeiteten Lernstories der Teams einen vage formulierten Problemfall erstellt. Dieser Fall war immer in der Form „ein Mandant kommt zu Ihnen und hat folgendes Anliegen – Helfen Sie dem Mandanten!“ aufgebaut. Das eigentliche Problem war nicht wirklich benannt nur Hinweise auf mögliche Problemgebiete wurden in dem Fall angedeutet. Ziel des Reviews war es nun, mit den Studenten anhand eines Beratungsansatz eine Problemlösung herauszuarbeiten. Dabei wurde immer nach dem gleichen Schema vorgegangen:

  • Problemidentifizierung
  • Abholung des Mandanten über die Themen durch Definition der verwendeten Themen und Begriffe
  • Herausarbeiten eines Lösungsansatzes
  • Ausblick und Zusammenführung

Durch diese Gruppenarbeit hatte ich die Chance, alle Studierenden durch direkte Aufrufe mit einzubinden. Ergänzend konnte ich noch fehlendes Wissen platzieren, falls ich merkte, dass Wissenslücken vorhanden sind und förderte durch die offene Fragestellung die Anwendung von unterschiedlichem Domänenwissen und Erfahrungen der einzelnen Studierenden. Einen Anreiz an den Diskussionen teilzunehmen, versuchte ich dadurch zu setzen, dass die Klausur in dem gleichen Stil durchgeführt wurde und somit den Review auch als Klausurtraining diente. Diese Vorgehensweise führte dazu, dass in dem jeweiligem Review (alle zwei Wochen) eine große Anzahl Studierender anwesend war, auch die, die die Bearbeitung der Lernstories nur bedingt vornahmen.

Aus meiner Sicht ist es wichtig, in den Bachelor Studiengängen, nach einer gewissen Anzahl an Semestern, ein übergreifendes Fach in der Studienordnung zu etablieren, das das vermittelte Wissen aus vorangegangenen Veranstaltungen zusammenzieht und so ein übergreifendes, vernetztes Wissen bei den Studierenden schafft.

Diese Veranstaltungen sollten mit relativ wenig vordefinierten Lehrpfaden aufgebaut werden, da unterschiedlichstes Wissen der Studenten vorhanden ist und so die Lehr-/Lerngeschwindigkeit individuell angepasst werden muss.

Aus meiner Erfahrung bietet sich hier Agiles Studieren in der hier dargestellten Form an. Lassen die Studenten sich auf die Vorgehensweise ein, zeigt die Erfahrung aus den vergangenen Semestern, dass hiermit solides Transferwissen aufgebaut und geschaffen werden kann. Ob dies nachhaltig ist, muss sich noch zeigen.

Leider zeigen aber auch die durchgeführten Veranstaltungen, dass Studierende sich immer wieder nicht auf das Konzept einlassen.
Ich nehme an, dass dies dann vor allem daran liegt, dass eventuell zu wenig Vorwissen aus den vorangegangenen Veranstaltungen vorhanden ist und somit die Arbeitsbelastung enorm steigt. Ein weiterer Hinderungsgrund kann natürlich auch eine mangelnde Teamfähigkeit sowie ein mangelndes Verantwortungsbewusst sein.

Betrachtet man Agiles Studieren allgemein, bin ich auf Basis meiner Erfahrungen von drei Semester mittlerweile der Meinung, dass dies sehr gut bei Fächern mit hohem praktischen Übungsanteil, wie Programmieren oder bei Fächern bei denen übergreifendes Wissen in Form eines Austausches generiert werden muss, wie PBI, angewandt werden kann.

Nachtrag: WissensTransferCamp

Zwar ist es schon etwas länger her, aber trotzdem soll hier das WissensTransferCamp vom März 2014 nicht unerwähnt bleiben. Knapp 80 Teilnehmer trafen sich in Friedberg zu einem Barcamp, bei dem es um das Thema Wissensaustausch in allen Facetten ging. Für mich war es mein erstes Barcamp. Karlheinz Pape hatte mich, wohl als Reaktion auf den ersten Beitrag, darauf aufmerksam gemacht.

Natürlich waren klassische Wissenstransferthemen, wie Informelles Lernen, Kompetenzentwicklung und -management gut vertreten. Ich war aber überrascht, wie agile Methoden auf Resonanz stießen. In der Doppelsession „Lernende Teams“ gab es für die Teilnehmer eine praktische, informelle Einführung in agile Methoden. In anderen Sessions ging es um Retrospektiven oder Flipped Learning.

So hatte ich die Gelegenheit, in einer eigenen Session „Lernen mit agilen Methoden“ die grundlegenden Ideen zum agilen Studieren vorzustellen und mit den Teilnehmern zu diskutieren. Anschließend wurde ich noch von Karlheinz Pape kurz interviewt. Das Ergebnis kann auf Youtube oder Mixxt.de angeschaut werden.

Insgesamt war das WissensTransferCamp eine gute Möglichkeit zum praktisch orientiertem Austausch von Ideen zum Thema Lernen, egal ob persönliches Lernen oder Lernen im Unternehmen.

Kurzfeedback von Studierenden

Im Wintersemester 2013/14 haben wir die Teilnehmer des agilen Studierens aufgefordert, auf anonymen Wege Rückmeldung zu geben. Es hat ein wenig gedauert, aber ich möchte die Ergebnisse nicht vorenthalten.

Die Teilnehmer haben die Rückmeldungen an die studentischen Vertreter der Studienkommission unseres Studiengangs gesendet. Wir als Professoren kennen die Autoren nicht. Zur Veröffentlichung habe ich den Satzbau ein wenig lesbarer gestaltet, die eigentliche Aussage aber nicht verändert.

Dem agilen Studieren stand ich sehr kritisch gegenüber, jedoch haben sich meine Befürchtungen mit der Zeit widerlegt. Ich finde das neue System des Selbststudiums einfach klasse weil es einen zum kontinuierlichen Lernen „zwingt“.

Ich hoffe, es hilft auch für Fächer, die nicht nach diesem Modell vorgehen.

Agiles studieren ist vor allem für Fächer wie „Programmierung 2“  und „Web Engineering 2“ gut. Für „Statistik“ ist das für mich agiler Schwachsinn, aber der Professor improvisiert sehr gut.

Das Fach „Statistik“ besitzt einen wesentlich größeren Anteil an Studienthemen, die jeder Teilnehmer alleine bearbeiten soll. In anderen Fächern überwiegen Themen, die ein einzelner bearbeiten und dann der restlichen Gruppe erläutern kann. Wir beobachten das weiter.

Agiles Studieren war nett gemeint, um es mal auszuprobieren. Aber ich finde es nicht effektiv, meine Meinung.

Hmm, agiles Studieren soll effektiver als eine normale Vorlesung, ggf. mit Übungen, sein. Es wäre schön, wenn sich der Autor dieses Satzes uns seine Meinung begründet (gerne anonym über die studentischen Vertreter).

Finde ich super, ich folge in meinen Vorlesungen schon seit 3 Jahren auf diesem Wege. Auch wenn Studenten dies am Anfang doch ungewohnt und als schwierig/unsicher empfinden, zahlt sich das im späteren Moment aus. Das Problem stellt sich halt in der Anwesenheit seitens der Vorlesung, dies müsste man mit kleinen Vorprüfungen anpassen.

Agiles Studieren ist so angelegt, dass es effektives Arbeiten unterstützt. In diesem Sinne freuen mich die ersten zwei Sätze. Mit dem letzten Satz ist vermutlich gemeint, dass die ganze Gruppe anwesend sein muss und die Gruppenauswahl auf Basis der freien Zeiten erfolgen sollte. Das ist ein Punkt, den ich im nächsten Semester zur (an sich freien) Wahl der Studiengruppen ansprechen werde.

Ich bedanke mich bei den anonymen Studierenden für ihre Rückmeldungen und fordere die Studierenden dieses Semesters auf, uns ebenfalls Feedback zu geben. Schließlich ist es Ihr Studium.

 

Erfahrungsbericht: Programmierung 2

So nun komme ich auch endlich dazu einen Erfahrungsbericht zum Agilen Studieren des letzten Semesters zu schreiben.

Zusammen mit Detlef Kreuz wuchs zu Beginn des WS 2013 die Idee Vorlesungen nach dem „Agilen Studieren“ abzuhalten. Mein Beweggrund war vor allem das Fach Programmieren 2 (Java). Bisherige Erfahrungen mit diesem Fach zeigten, dass ein Großteil der  Studenten sich nicht kontinuierlich mit dem Fach auseinandersetzen, sondern erst aktiv werden, wenn die Klausur vor der Tür steht.  Das dieses Vorgehen zum erlernen einer Programmiersprache nicht zielführend ist, wurde zwar immer und immer wieder erwähnt, stoß aber weitestgehend auf taube Ohren. Man kann nun mal Programmieren nur dann lernen, wenn man eben selber programmiert und das am besten kontinuierlich.

Bisher hatte ich versucht die Studenten zu kontinuierlichen Programmieren dahingehend zu bewegen, indem ich Aufgaben mit Bonuspunkten vergeben habe. Im ersten Semester wurden die Übungsaufgaben von wenigen gemacht und von vielen kopiert. Erst der Einsatz von Plagiatsscanner führte dann dazu, dass das Kopieren zurückging. Ich habe dann aber leider durch einige Kanäle erfahren, dass in den nachfolgenden Semestern die Bonusaufgaben von anderen Studenten (aus höheren Semester) gelöst wurden.

Unterm Strich war damit klar, dass die Methode Übungsaufgaben mit Bonuspunkten zu vergeben nicht zielführend sein kann.

Die Überlegung ein Fach, in dem es vor allem davon abhängt, dass die Studenten selber aktiv werden und die Programmierthemen selber anwenden, agil durchzuführen und somit die Vorlesungstermine zur Vertiefung der Themen zu verwenden, weckte bei mir großes Interesse und natürlich auch  gewisse Erwartungen:

Ich erwartete vor allem:

  • Studenten finden Spaß an der logischen und analytischen Tätigkeit „Programmieren“.
  • In den Vorlesungsslots fragen die Studenten vor allem die Themen nach, in denen Sie noch Hilfe brauchen.
  • Mangels vorhandener vordefinierter Folien, sinkt das Bulimie-Lernen vor der Klausur.
  • Studenten werden in unterschiedlichen Geschwindigkeiten lernen bzw. die Lernthemen abarbeiten.
  • Ich als Dozenten werde eine wesentlich höhere Betreuungsquote im Semester für das Fach aufbringen müssen, als bei dem klassischen Frontalunterricht.
  • Tutorische Veranstaltungen sind nur bedingt nötig. (Da diese bisher eh nur von den Studenten besucht wurden, die es eigentlich nicht unbedingt nötig hätten.)
  • Klausuranmeldungen werden zurückgehen, aber gleichzeitig werden die Ergebnisse der Klausur wesentlich besser werden als zuvor.

Ob die Erwartungen erfüllt wurden ? Das lässt sich nur bedingt beurteilen.  Ich glaube auch, dass man nach einem Semester  kaum eine fundierte Aussage treffen kann. Ich möchte hier nun auf einige meiner Erwartungen eingehen:

1. Erwartung: Studenten finden Spaß an dem Fach

Meine These ist, wenn ich mich lang genug mit einem Thema beschäftige, baue ich genügend Wissen auf, so dass ich dieses Thema fundiert anwenden kann. Dinge die man gut kann, machen mehr Spaß als Dinge, die man nicht kann. Dementsprechend bin ich der Meinung mit genügend Ausdauer und Eigeninitiative kann jedes Thema einem Spaß machen.

Leider ist dies bei dem Thema Agiles Studieren in Prog nur bei wenigen Studenten/-innen zum Vorschein gekommen.  Ich glaube, dass bis auf wenige Ausnahmen nur ein paar Studenten/-innen sich wirklich auf das Abenteuer Agiles Studieren eingelassen haben und somit bei vielen diese Freude für Dinge, die man dann gut kann, gar nicht erst aufkommen konnte. Weiter glaube ich, dass viele Studenten/-innen sich vor diesem Experiment „gedrückt“ haben. Eine kontinuierliche Anwendung von Agilen Studieren würde m. E. diese Ausweichtaktik massiv reduzieren und ich glaube immer noch daran, dass dann auch Fächer wie Prog für die große Masse der Studenten spaß machen kann.

2. Erwartung: In den Vorlesungen werden intensivere Diskussionen geführt und die Studenten fragen nach den Themen, in denen sie sich noch nicht stark fühlen.

Bezogen auf die erste Anwendung der Methode war dies sicher die Erwartung, die in der Realität am wenigsten bestätigt wurde. Zwar gab es wenige Studenten/-innen, die jede Veranstaltung genutzt haben sich erstens den Stoff erklären zu lassen und zweitens vertiefende Fragen zu stellen, aber im großen und ganzen war die Teilnahme der Studenten/-innen sehr ernüchternd. Vielmals war der Ruf zu hören, dass die Studenten/-innen viel lieber eine klassische Vorlesung hätten, da hier der Stoff aufbereitet vorgetragen wurde. Aus meiner Sicht nicht nachvollziehbar, da wenn von den Studenten/-innen die Themen pro Woche – wie es dann auch einige gemacht haben – eingefordert wurden, wurden diese ja in einem  ähnlichen Stil vorgetragen, wie bei klassischen Frontalunterricht. Ernüchternd war aber, dass die meisten Studenten Agiles Studieren mit „jetzt muss ich nicht mehr zu den Vorlesungsterminen“ gleichgesetzt haben.

Trotz dieser ersten Erfahrung bin ich immer noch von dem Konzept überzeugt. Auf der einen Seite zwingt es Studenten/-innen viel mehr in das eigenverantwortliche Lernen und auf der anderen Seite holt es auch die Dozenten aus der Bequemlichkeitsfalle, da jede Vorlesung eine adhoc Neukonzeption erfordert (Agil eben), da der Dozent ja nicht wissen kann, was heute eingefordert wird.

3. Erwartung: Weniger Anmeldungen – Bessere Noten.

Mir war während der gesamten Zeit wichtig, dass dieses Experiment mittels vergleichbaren Ergebnissen bewertet werden kann. Da Prog ein Fach ist, das als Hürde für das Studium angesehen wird, war mir wichtig, dass durch Agiles Studieren die Bestehensquote steigt. Leider konnte ich dieses Semester keine positive oder negative Evaluation hierzu ablegen. Dies lag daran, dass Prog2 mit dem Fach Web Engineering verrechnet werden kann. Dieses Semester ist diese Klausur aber sehr gut ausgefallen und die Noten waren den Studenten bekannt, bevor die Klausur Prog2 geschrieben wurde. Dementsprechend haben einige Studenten den Weg des geringsten Drucks gewählt und entweder die Klausur nicht besucht oder nicht Ihre volle Leistung abgegeben. (Dies zeigte sich in zur Hälfte bearbeiteten Klausuren u.a.)

Dementsprechend ist eine vergleichende Beurteilung im Moment für dieses Fach nicht möglich. Positiv sind einige Studenten aufgefallen, die sowohl aktiv agil studierten und deren Ergebnisse sehr gut ausgefallen sind.

Soviel zu meinen ersten Erfahrungen. Ich bin gespannt wie sich diese  Methode dieses Semester in einem anderen Fach schlägt. Ich hoffe die Teilnehmer dieses Kurses trauen sich, sich mehr auf diese Methode einzulassen.

 

Erste Förderung

Seit Ende Februar wird „Agiles Studieren“ durch die Studienkommission für Hochschuldidaktik (in Baden-Württemberg) im Rahmen des IQF-Projekts „Heterogenität als Chance“ gefördert. Zwar fällt die monetäre Förderung etwas geringer aus als beantragt, aber wir wollen uns nicht beschweren.

Im Gegenteil, wir sehen dies als Ansporn, agiles Studieren weiter zu entwickeln, es bekannter zu machen und die dadurch ausgelösten Lernprozesse (nicht nur bei den Studierenden) besser zu verstehen. Das Feedback, sei es über die Kommentarfunktion, über Twitter oder Google+ freut und ermuntert uns.

Nicht nur bei der Studienkommision möchten wir uns bedanken, sondern auch bei der „Assistenz“  im Prorektorat Studium und Lehre. Auf den letzten Drücker reichten wir in bester studentischer Manier unseren Antrag ein und Dank einiger unbürokratischer Aktionen kam dieser noch rechtzeitig bei der Studienkommission an. Danke!

Und nun wird gearbeitet.

Erfahrungen aus studentischer Sicht

Rebecca Lesiewicz, Studentin der Wirtschaftsinformatik an der Hochschule Heilbronn, schreibt in einem Gastbeitrag über ihre Erfahrungen aus studentischer Sicht.


Ich muss sagen, dass ich am Anfang sehr skeptisch war und das agile Studieren als große zusätzliche Belastung empfunden habe. Zum Hintergrund muss ich wohl dazu sagen, dass ich auch im ersten Semester sehr viel Zeit für das Studieren investiert habe. Mein Mann sagt, ich bin mehr beschäftigt, als mit einem Vollzeit-Job. Das ist wohl in meinem Fall so. Ich nehme das Studieren sehr ernst, habe mich bewusst dafür entschieden und mir macht es auch Spaß.

Trotzdem empfand ich das agile Studieren am Anfang sehr anstrengend. Es hat einige Wochen gedauert, bis wir uns in unseren Gruppen zurecht gefunden haben und wir wussten, wie wir im jeweiligen Fach vorgehen sollten. Wie wir uns die Themen einteilen, damit wir alle Tickets bis zum Semesterende bearbeitet haben. Wir haben am Anfang zu viel gemacht und daher war da dann auch die Belastung sehr hoch. Nach einer gewissen Zeit hat sich dies aber eingespielt.

Ich war in allen drei Fächern beim agilen Studieren dabei, also sowohl in PM1, als auch in Programmierung 2 und Statistik. Die Zusammensetzung meiner Gruppe war in jedem der drei Fächer anders und wir sind auch in jedem Fach anders vorgegangen. In Statistik und Programmierung hat jeder alle Themen bearbeitet, bei Problemen haben wir uns innerhalb der Gruppe besprochen oder Hilfe vom Dozenten geholt. In Programmierung gab es ziemlich regelmäßig verschiedene Impulsvorträge und zum jeweiligen Sprint auf unsere Nachfrage einen grobem Überblick, was bei den ausgewählten Themen wichtig ist. In Statistik haben wir i.d.R. die Themen vorab selbst vorbereitet und dann aber nochmal vom Dozenten erklären lassen und alleine und gemeinsam in der ‚Vorlesung‘ Aufgaben gerechnet.

In Projektmanagement sind wir ganz anders vorgegangen. Wir waren 7 Studierende in dieser Gruppe. Wir haben die Anzahl der Tickets für jeden Sprint so gewählt, dass jeder pro Sprint 2-3 Tickets bearbeiten muss. In der ersten Sprintwoche hat dann jeder ’seine‘ Tickets bearbeitet (Recherche und Dokumentation), dann haben wir diese in der ‚Vorlesung‘ in der Gruppe besprochen und in der zweiten Woche hatte dann jeder Zeit, die Tickets der anderen noch einmal durchzuschauen.

Gerade in PM1 hatten wir dann am Ende aller Tickets alle Themen dokumentiert und da (fast) alle Themen vom Dozenten abgenommen waren, hatten wir eine gute Grundlage für die Klausurvorbereitung.

Wenn ich das jetzt mit SE1 für mich vergleiche, bin ich da ähnlich vorgegangen. Ich habe die Vorlesungen jede Woche nachbereitet und hatte somit auch eine gute Grundlage für die Klausurvorbereitung. Ich habe alle Übungen bearbeitet und die Literaturvorschläge durchgearbeitet. Für mich mit einem Unterschied, ich hatte in SE1 im Vergleich zu PM1 (beide Fächer finden beim selben Dozenten statt) die Einschätzung des Dozenten, die Kommentare zu den Themen. Ich konnte in SE1 besser einschätzen, was dem Dozenten evtl. wichtig ist und was nicht. Dies hat sich auch in meinen Noten gezeigt, auch wenn ich sehr zufrieden mit den Ergebnissen bin, ist meine Note in SE1 etwas besser, als in PM1.

In Statistik und Programmierung, wo es mehr Vorträge von den Dozenten gab – nachdem die Studierenden dies eingefordert hatten – konnte ich dies besser einschätzen.

Ich weiß nicht, warum wir als Gruppe in PM1 dies nicht genutzt haben. Es gab nicht viele Situationen, in denen wir die Hilfe des Dozenten eingefordert haben. Dies würde ich jetzt anders machen.

Im Großen und Ganzen hab ich mich mittlerweile mit dem ‚agilen Studieren‘ angefreundet. Die Vorteile lagen klar darin, dass wir die Themen so planen konnten, dass wir alle Tickets in allen drei Fächern schon einen Sprint früher fertig gestellt hatten, sodass wir früher mit der Wiederholung für die Klausuren beginnen konnten und von Anfang an einen besseren Überblick über den gesamten Lernstoff hatten. Dies war zwar am Anfang ein Riesenberg, aber wir wussten, was auf uns zu kommt.

Alle Studierenden, die jetzt nach uns zum ersten Mal ‚agil Studieren‘ kann ich nur empfehlen, die Hilfe der Dozenten einzufordern. Am besten gleich am Anfang die Einschätzung des Dozenten, wie man die Themen am sinnvollsten einteilt. Also welche Themen der Dozent zusammen bearbeiten würde und in welcher Reihenfolge. Dann auch innerhalb der Gruppe absprechen, wie man vorgehen soll, damit alle einverstanden sind und wissen, vorauf sie sich einlassen. Konsequente Treffen der Gruppe fand ich auch sehr wichtig. Auch da haben wir Absprachen getroffen, ob wir uns auch treffen, wenn wir nur zu zweit sind und was wir machen, wenn jemand krank ist und sein Thema nicht vorstellen kann usw. Das hat uns sehr geholfen innerhalb der Gruppe.

Ich hoffe, dass mein Erfahrungsbericht nachfolgenden Studierenden hilft, von Anfang an offener mit diesem Thema umzugehen und sich darauf einzulassen.

Erste Ergebnisse: Projektmanagement 1

Das Semester ist vorüber, die Klausuren sind geschrieben und bewertet. Zeit also, eine erste Bilanz auf Basis der Klausurergebnisse zu ziehen. In diesem Beitrag soll es um die Veranstaltung „Projektmanagement 1“ (PM1) gehen.

Rahmenbedingungen

Ich bewerte die Klausuren schon seit einigen Jahren quasi-anonym: auf den Klausuren steht nur die Matrikelnummer, ich erfahre erst bei der Eingabe der Noten, welche Person diese Bewertung erhalten hat.

Neben dem Fach PM1 unterrichtete ich im vergangenen Wintersemester zusätzlich das Fach „Software Engineering 1“ (SE1) für die gleiche Zielgruppe an Studierenden (2. Studiensemester), aber nicht nach der Methode „Agiles Studieren“, sondern wie in den vergangenen Jahren auch. Damit habe ich eine Kontrollgruppe.

In beiden Fächern habe ich die identischen Aufgaben wie vor einem Jahr gestellt. Die Bearbeitung der Aufgaben lässt darauf schließen, dass dies keiner der Studierenden groß gemerkt hat.

Warum vergleiche ich mit Klausuren, die vor einem Jahr geschrieben wurden? Es gibt eine Art saisonale Schwankung bei den Klausurergebnissen.  Statistisch gesehen schneiden Studierende, die ihr Studium in einem Wintersemester begonnen haben, im Mittel um ca. eine Teilnote besser ab. Dies bestätigen mir viele Kollegen in Gesprächen. Über die Gründe kann ich nur mutmaßen und möchte sie hier nicht vertiefen.

Bei der Veranstaltung SE1 gab es allerdings eine relevante Änderung zum Vorjahr. Ab diesem Wintersemester habe ich in allen Veranstaltungen darauf verzichtet, den Studierenden auf Basis von Arbeiten während des Semesters (zusammenfassende Präsentationen, Dokumentieren der Lernergebnisse in einem Wiki) sog. „Bonuspunkte“ zu gewähren. Der Grund war die Fixierung der Studierenden auf die Bonuspunkte und nicht auf die Inhalte. Daher vergleiche ich hier auch nur primär die erreichten Punkte in der Klausur. Die Bonuspunkte haben auf das Bestehen der Klausuren keinen Einfluss.

Trotzdem besitzen die Bonuspunkte einen vermuteten Effekt: die Studierenden werden während der Vorlesungszeit aktiviert, sich mit den Inhalten zu beschäftigen, die sie im Rahmen einer Kurzpräsentation zusammenfassen sollen. Diese Inhalte beherrschen die Studierenden vermutlich besser als der Durchschnitt.

Erwartungen

Dieser Effekt lässt sich mit einer anderen Klausur dieses Wintersemesters belegen: „Software Engineering 2“ (SE2), üblicherweise belegt durch Studierende des 3. Semesters. Zwar habe ich in diesem Fach nicht die identische Klausur wie vor einem Jahr schreiben lassen, der Inhalt war aber vom Schwierigkeitsgrad sehr vergleichbar. In SE2 sank die durchschnittlich erreichte Punktezahl um 5,1 Punkte gegenüber im Vorjahr (gleiche Anzahl an Klausuren). Das entspricht in etwa ein klein wenig mehr als einer Teilnote. In SE1 sank dagegen die durchschnittliche erreichte Punktzahl um 6,5 Punkte (49 Klausuren vor einem Jahr, 39 Klausuren in diesem Wintersemester), das entspricht eher 1,5 Teilnoten.

In allen Klausuren, auch PM1, konnten durch Bearbeitung der Klausuraufgaben maximal 90 Punkte erzielt werden.

Da es in PM1 in der Vergangenheit keine Bonuspunkte gab, hätte ich nur eine kleine Verringerung der durchschnittlich erreichten Punktzahl erwartet, wenn ich die Veranstaltung wie bisher durchgeführt hätte. Sprich: wenn sich die Ergebnisse von SE2 und SE1 auf PM1 hochrechnen lassen, wäre ein Absinken der durchschnittlich erreichten Punkte um 1,4 Punkte zu erwarten.

Was waren meine Erwartungen für das agile Studieren im Fach PM1? Ich habe meine Erwartungen nicht vorher öffentlich dokumentiert, um die Studierenden nicht zu beeinflussen. Meine Erwartung war, dass die Ergebnisse in etwa denen der vergangenen Jahre ähneln. Wer schon einmal an Änderungsprozessen beteiligt war, weiß, nach einer Änderung vieles erst einmal schlechter wird. Wenn alle Beteiligten die Änderungen wirklich akzeptiert haben, verbessern sich die Ergebnisse (idealerweise auch gegenüber dem Stand vor der Änderung).

In diesem Sinne ist meine Erwartung durchaus gewagt. Das Konzept ist neu. Keinem von uns Lehrenden war zu Beginn klar, ob wir es so umsetzen können, wie geplant war. Für die Studierenden bedeutete es eine erhebliche Umstellung. Da von keiner Verschlechterung auszugehen, ist wohl eher optimistisch.

Ergebnisse

Nachdem ich  (geschickt?) die Erwartungen gedämpft habe, will ich die Ergebnisse für PM1 darstellen.

Der Durchschnitt der erreichten Punkte ist um 0,2 Punkte gesunken. Das ist weniger, als wenn ich weiterhin konventionell vorgegangen wäre (klassische Vorlesung mit Übungen). Allerdings ist die Anzahl der Klausurteilnehmer bei PM1 von 50 im letzten Jahr auf 33 in diesem Wintersemester stärker gesunken als bei SE1 (nur 10 Teilnehmer weniger).

Die wesentlich geringere Anzahl an Klausurteilnehmern führe ich auf das agile Studieren zurück. Meine These: ca. 7 Studierende haben sich erst gar nicht zur Klausur angemeldet, weil sie durch das agile Vorgehen entsprechendes Feedback zu ihrem vermeintlich ungenügendem Wissensstand erhalten haben.

Sollte meine These stimmen, dann wäre der Durchschnitt der Punkte zu hoch. Hätte ich PM1 konventionell durchgeführt, hätten sich diese 7 Studierenden zur Klausur angemeldet.

Um eine sehr pessimistische Abschätzung für den nach meiner These zu hohen Durchschnitt zu erhalten, habe ich die sieben schlechtesten Ergebnisse dupliziert. Damit erhalte ich die erwarteten 40 Klausurteilnehmer. In diesem Fall sinkt die durchschnittlich erreichte Punktezahl um 3 Punkte (im Vergleich zum letzten Jahr).

In einem anderen Szenario hätten die fehlenden Klausurteilnehmer vergleichbare Ergebnisse erzielt, wie die Studierenden, die so gut wie nicht am agilen Studieren teilgenommen hatten. Da mir eine Monte-Carlo-Simulation zu aufwändig ist, habe ich die Ergebnisse der Studierenden, die nicht am agilen Studieren teilnahmen, aufsteigend sortiert und per Abzählverfahren jedes 10. Ergebnis verwendet, bis ich 7 Ergebnisse hatte. In diesem Fall sinkt der Punktedurchschnitt um 1,5 Punkte (im Vergleich zum letzten Jahr).

Für mich ergibt sich, dass das Vorgehen nach dem agilen Studieren meine Erwartungen erfüllt. Trotz der ganzen Änderungen in diesem Semester wurden von den Studierenden ähnliche Ergebnisse, wie bei einem konventionellen Vorgehen, erzielt.

Bestanden?

Eine gravierende Änderung zum Vorjahr lässt sich aus diesen Werten nicht herauslesen: die Verteilung der Punkte. Das Konzept der Standardabweichung lässt sich hier nicht anwenden, da die Punkteverteilung so gut wie nie einer Glockenkurve ähnelt.

Jetzt wird die Notenverteilung doch noch relevant. Ich habe die Klausur genauso bewertet wie vor einem Jahr. Bis auf eine Ausnahme ähnelt sich die Verteilung der Noten von vor einem Jahr mit der Notenverteilung in diesem Wintersemester. Es gibt eine geringe Zahl an Einsen, etwas mehr Zweien und noch mehr Dreien. Bei denen, die nicht bestanden haben, gibt es doppelt so häufig die Note „5+“, wie die Note „5“. Eine Note „4-“ ist an der Hochschule Heilbronn nicht vorgesehen. So weit, so normal.

Was aber auffällt, ist das fast völlige Fehlen der Note „4“. Hatte ich im Vorjahr diese Note zu ca. 20% vergeben, war es jetzt nur ein Mal. Ein „gerade mal so bestanden“ gab es in diesem Semester so gut wie nicht. Das spiegelt sich auch am Anteil der nichtbestandenen Klausuren wider: in diesem Jahr haben vom Anteil her doppelt so viele Studierende die Klausur nicht bestanden, wie im letzten Jahr.

Wie schon oben angedeutet, haben viele Studierenden nicht wahrnehmbar am agilen Studieren teilgenommen. Das entspricht der geringen Teilnahme an konventionellen Veranstaltungsformen. Darüber hatte ich schon in Die Idee geschrieben. Wie verteilen sich die Ergebnisse zwischen den aktiven und den „weniger aktiven“ Studierenden?

Im Unterschied zu einer Vorlesung, selbst wenn diese „seminaristisch“ ist, können wir Professoren beim agilen Studieren sehr gut nachvollziehen, wer aktiv mitarbeitet und wer eher Inhalte konsumiert oder gar passiv ist. Das sehr klare Ergebnis hat mich überrascht.

Jeder aktiv am agilen Studieren teilnehmende Studierende hat die Klausur bestanden, wirklich jeder.

Mich hat das auch deshalb überrascht, weil darunter Studierende sind, die die deutsche Sprache nicht so gut beherrschen.

Es gab eine Gruppe von Studierenden, die sporadisch und selten in einer Gruppe am agilen Studieren teilnahmen. Von diesen hat die Hälfte bestanden. Die beste Note war eine „3+“.

Bei der Gruppe der Studierenden, die kaum oder gar nicht wahrnehmbar am agilen Studieren teilnahmen, haben nur ein Drittel die Klausur bestanden. Auch hier war die beste Note eine „3+“.

Fazit

Wie bewerte ich diese Ergebnisse, auch wenn sie nur eine Momentaufnahme sind?

Zum einen bin ich froh, dass die Ergebnisse trotz der ganzen Änderungen vergleichbar zu früheren Jahren blieben. Der Punktedurchschnitt ist im erwarteten Rahmen, alle aktiven Studierenden haben die Klausur bestanden. Das Experiment muss nicht abgebrochen werden. Im Gegenteil.

Zum anderen bin ich fast erschrocken, wie sehr der (Lern-, Klausur-, …) Erfolg eines jeden einzelnen Studierenden von der eigenen Aktivität abhängt. Das bestätigt für mich die (Binsen-?) Weisheit, dass jeder Studierende für den eigenen Lernerfolg zuerst selbst verantwortlich ist.

Wie geht es weiter?

Ja, es geht weiter. Ich kenne die Detailergebnisse meiner Kollegen noch nicht und bin darauf sehr gespannt. Aus meiner Sicht deuten meine Ergebnisse das große Potential der Methode „agiles Studieren“ an.

Studienphase

Der Begriff „agil“ bietet sich als Projektionsfläche für viele Hoffnungen an. Es gibt keine allgemein anerkannte Definition, nur ein umschreibendes „agiles Manifest„. So kann sich jeder heraussuchen, was für einen selbst „agil“ sein soll.

Für uns ist die Idee der schnellen Rückmeldung besonders wichtig. Studierende sollen nicht erst am Ende des Semesters in Form einer Prüfung erfahren, wie weit sie die Lernziele erreicht haben. Uns ist wichtig, diese Rückmeldungen schneller zu geben.

Wenn Studierende in Gruppen Studienthemen bearbeiten sollen, wie schnell können wir Professoren eine Rückmeldung über den Lernerfolg geben?

Im Idealfall könnten die Studierenden sofort nach Bearbeitung eines Themas eine Bestätigung, eine Begutachtung, eine Ablehnung ihrer Arbeitsergebnisse erhalten. Das wäre weder praktikabel noch wünschenswert.

Eine sofortige Rückmeldung müsste automatisiert erfolgen, wir können (und wollen!) nicht unsere Zeit mit Warten auf Bearbeitungsergebnisse verbringen. Es ist nicht einfach, automatisierte Rückmeldungen so geben zu lassen, dass sie auf die Bedürfnisse der Gruppe eingeht.

Weiterhin bedeutet die Bearbeitung eines Themas nicht, dass es fertig bearbeitet wurde. Eine Nacht über ein Problem zu schlafen kann Wunder wirken. Die Lösung einer Aufgabe sollte in der Gruppe besprochen werden. Die Studierenden einer Gruppe müssen sich immer wieder neu organisieren. Mehrere Lösungen können miteinander verglichen werden. Themen stehen miteinander in Beziehung. Lernen braucht Rhythmus.

Dieses vertiefende Lernen ist unser Ziel.

Ein Semester dauert 14-15 Wochen. Wenn wir es schaffen, alle zwei Wochen einer Gruppe von Studierenden Rückmeldung über die bearbeiteten Themen zu geben, können wir dies 6-7 Mal tun. Schaffen wir es nur alle drei Wochen, sind nur 4 Rückmeldungen möglich. Also organisieren wir das Lernen in einen 2-Wochen-Rhythmus und nennen diese 2 Wochen „Studienphase“.

Jede Studienphase besteht aus mindestens zwei Präsenzterminen, pro Woche ein Termin. Dieser entspricht den früheren Vorlesungsterminen.

In der ersten Woche bespricht jede Gruppe die Rückmeldungen zu letzten Studienphase. Hierbei können studentische Coaches / Tutoren oder wir selbst helfen. Zum Beispiel, wenn die Rückmeldung inhaltlich nicht verstanden wurde oder die Gruppe anderer Meinung ist. Eine gut organisierte Gruppe wird versuchen, diese Besprechung vor dem Präsenztermin durchzuführen, aber nicht immer gelingt dies.

Wenn die Gruppen in der vorherigen Phase ähnliche Inhalte bearbeiteten, können Ergebnisse im Plenum vorgestellt und besprochen werden. Dies hängt aber auch von Themen, Gruppenanwesenheiten oder -befindlichkeiten ab.

Danach sollte sich die Gruppe kurz innehalten und gemeinsam besprechen, was in der vergangenen Studienphase gut gelaufen ist, was verbesserungswürdig wäre und was bemerkenswert war.

Diese drei Punkte können erst ab der dritten Woche durchgeführt werden. Inhaltlich gehören diese zur vorherigen Studienphase.

Die Studienphase beginnt mit einer Planung der Themen, die in dieser Studienphase bearbeitet werden sollen. Hierbei ist jede Gruppe frei in der Auswahl. Für jedes Fach gibt es eine bestimmte Anzahl an Themen, die im Semester bearbeitet werden sollen. Daher ist die Wahl der Themen nicht ganz frei. Jede Gruppe kann aber selbst entscheiden, in welcher Phase wie viele Themen bearbeitet werden sollen.

Unsere Aufgabe ist die Beratung zur Themenauswahl. Dies erfolgt entweder individuell für jede Gruppe oder gemeinsam für alle Gruppen. Je nach Stand der Gruppen kann dies auch bedeuten, dass wir einen kurzen Impulsvortrag halten. Ziel ist es, dass jede Gruppe für sich sinnvolle Themen auswählt.

Besitzt zum Beispiel ein Gruppenmitglied Vorkenntnisse zu einem Thema, so kann dieses Thema wahrscheinlich schneller bearbeitet werden. Das Gruppenmitglied unterstützt die Gruppe beim Lernen. Erscheinen die Themen überwiegend schwer, so sollten weniger Themen für die Studienphase ausgewählt werden. Alternativ kann der Kontakt zu anderen Gruppen gewählt werden.

Nach der Auswahl beginnt das Bearbeiten der Studienthemen, noch während des Präsenztermins. Hierbei entscheidet jede Gruppe, ob das Thema nur zeitgleich bearbeitet werden kann, oder, ob einzelne Gruppenmitglieder das Thema für sich bearbeiten und die Ergebnisse später den anderen vorstellen.

Während der ersten Woche sollten alle Gruppenmitglieder die Themen wie abgesprochen bearbeiten. Sinnvoll ist sicher, sich auch einmal außerhalb der Präsenzzeiten zu treffen.

Der Präsenztermin in der zweiten Woche wird genutzt, um den bisherigen Arbeitsstand abzugleichen und offene Fragen zu beantworten. Ziel ist es, in der zweiten Woche die Bearbeitung aller geplanten Studienthemen abzuschließen.

Was bedeutet „Bearbeitung abschließen“? Die Mehrzahl der Gruppenmitglieder muss explizit dokumentieren, dass sie meinen, dass Thema inhaltlich verstanden zu haben.

Damit wir den Gruppen Rückmeldung geben können, muss die Bearbeitung spätestens 24 Stunden vor dem Präsenztermin abgeschlossen sein. Bei vielen Gruppen, vielen Themen oder vollem Terminkalender möglicherweise auch 48 Stunden vorher.

Mit unseren Rückmeldungen schließt sich der Kreis.

Spätestens jetzt sollte einsichtig sein, weshalb Studienphase mindestens zwei Wochen dauern müssen.

Wer sich mit agilen Vorgehensmodellen etwas auskennt, wird die Ähnlichkeit zu einem „Sprint“ bei Scrum, inkl. Retrospektive sicher erkennen.

Zusammengefasst:

  • Lernen braucht Rhythmus und zügige Rückmeldung.
  • Eine Studienphase ist der von uns vorgegebene Lernrhythmus und dauert zwei Wochen.
  • Zu Beginn plant die Gruppe eigenverantwortlich die Studienthemen, die sie in der kommenden Phase bearbeiten möchte.
  • Wir unterstützen diese Planung durch Beratung und ggf. Impulsvorträge.
  • Jede Gruppe entscheidet, in welcher Organisationsform sie die Themen bearbeiten möchte.
  • In der zweiten Woche ist Zeit für Rückfragen und zum Abgleich.
  • 1-2 Tage vor Ende der Studienphase müssen bearbeitete Themen uns vorliegen, damit wir Rückmeldung geben können.
  • Die Rückmeldung wird besprochen und fließt in die nächste Studienphase ein.

Studienthema

In der Idee zum agilen Studieren hatte ich angedeutet, dass der gesamte Stoff in Studienthemen aufgeteilt wird. Was ist denn so ein Studienthema genau, wie groß ist es, wie wird es formuliert?

Menschen mit Erfahrung in agilen Vorgehensmodellen werden sicher ahnen, was ein Studienthema ist: eine User Story, abgewandelt für zu lernende Inhalte.

In der Softwareentwicklung sind User Stories eine Möglichkeit, um Anforderungen aus Sicht des Anwenders kurz aber präzise zu beschreiben. Die Zusammenfassung einer User Story erfolgt mit Hilfe einer Satzschablone:

Als <ROLLE> will ich <ZIEL>, um <NUTZEN>.

Dabei ist <ROLLE> die Rolle des jeweiligen Anwenders, <ZIEL> der Wunsch oder das Ziel dieses Anwenders und <NUTZEN> eine Begründung für diesen Wunsch. Zum Beispiel:

Als Autor will ich weitere Autoren eintragen, um nicht alles alleine schreiben zu müssen.

Zu einer User Story müssen darüber hinaus Kriterien aus Sicht des Anwenders angegeben werden, nach denen bestimmt wird, ob eine User Story vollständig umgesetzt wird (Akzeptanzkriterien). In einer allgemeinen Beschreibung einer User Story werden ggf. weitere Details angegeben, z.B. Prioritäten, Zeitverhalten, Designvorschläge. Manchmal wird der Nutzen nicht in der Zusammenfassung definiert, sondern erst in der Beschreibung.

Auf Basis dieser Informationen lässt sich das Schema für ein Studienthema ableiten: es gibt eine Zusammenfassung auf Basis einer Satzschablone, Kriterien, wann das Thema als bearbeitet gelten kann und eine Beschreibung mit zusätzlichen Informationen.

Das Satzschema für ein Studienthema ist etwas komplizierter. Die Rollenangabe kann entfallen, es lernt der Studierende, daher wird immer ein „Ich“ angegeben. Zur Angabe des Ziels greifen wir aus Vereinfachungsgründen auf die Einordnung von kognitiven Lernzielen nach Bloom zurück. Jedes Lernziel, das wir zugleich als Ziel eines Studienthemas auffassen, kann einer von 6 Kategorien zugeordnet werden. Die Kategorien bauen aufeinander auf. Jeder Kategorie sind Verben zugeordnet, die das Studienthema charakterisieren:

  1. Wissen: benennen, definieren, zeichnen, …
  2. Verstehen: begründen, erklären, erläutern, …
  3. Anwenden: auswählen, modellieren, ändern, …
  4. Analysieren: klassifizieren, unterscheiden, unterteilen, …
  5. Zusammenfügen: formulieren, implementieren, konstruieren, …
  6. Bewerten: beurteilen, in Beziehung setzen, zusammenfassen, …

Die Zuordnung der Verben zu den Kategorien ist nicht trennscharf, aber es ist meistens aus dem Zusammenhang klar, was gemeint ist. Natürlich gibt es ein Studienthema auf einer Meta-Ebene:

Ich verstehe die Bedeutung der Verben zum Thema "Studieren"

Als Akzeptanzkriterien geben wir meist Tätigkeiten an, welche die Studierenden durchführen und dokumentieren sollen. Die Beschreibung enthält Verweise auf Quellen, die von den Studierenden studiert (!) werden sollen. Das können auch Verweise auf unsere früheren Präsentationsunterlagen sein.

Studienthemen können darüber hinaus gruppiert werden, damit die Studierenden bei der Auswahl der Themen eine orientierende Struktur vorfinden. Bei den Themen zur Veranstaltung „Projektmanagement 1“ nutze ich z.B. eine Gruppierung auf Basis der 9 Wissensgebiete nach PMI.

Eine Dokumentation eines Studienthemas sieht dann so aus:

Ich kann den Prozess der integrierten Änderungssteuerung erläutern.

Kategorie: Integrationsmanagement

Quelle: Präsentation PM1-01, Seite 35-39
Erläutern Sie den Prozess mit eigenen Worten auf der Wiki-Seite "ÄnderungsSteuerung".

Es bleibt der Studiengruppe freigestellt, ob jedes Gruppenmitglied das Thema für sich bearbeitet, oder ob ein Mitglied das Thema bearbeitet und es anschließend den anderen Gruppenmitgliedern vorstellt.

Der Umfang eines Studienthemas variiert relativ stark. Für die Fächern „Programmierung 2“ und „Statistik“, beides Fächer mit 5 Credit-Points nach ECTS (entspricht 150 Stunden pro Semester), haben meine Kollegen etwas mehr als 50 Studienthemen formuliert. Einige davon sind optional. In „Projektmanagement 1“ habe ich dagegen etwas mehr als 100 Studienthemen angegeben, und das bei 2 Credit-Points (entspricht 60 Stunden pro Semester).

Diese Unterschiede spiegeln m.E. die fachlichen Anforderungen wieder. „Programmierung 2“ und „Statistik“ orientieren sich eher an den letzteren Kategorien der Taxonomie von Bloom. Selbst wenn ein Studierender z.B. die diversen Befehle einer Programmersprache kennt, kann sie/er noch lange nicht selbst Programme erstellen. Dadurch ist für einen Anfänger das Erstellen einfacher Programme eher zeitaufwendig. Das Fach „Projektmanagement 1“ soll dagegen den Studierenden einen Überblock über die zahlreichen Facetten des Projektmanagements geben. Für jede, aus meiner Sicht, relevante Facette habe ich ein Studienthema formuliert.