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.

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.