Gestern durfte ich an einer sehr interessanten und teilweise emotionalen Diskussion teilnehmen. Es war der Abschlusstermin der diessemestrigen Projektstudie Softwareentwicklung, von mir großspurig Retrospektive getauft. Ob es wirklich eine Retrospektive war sei einmal dahin gestellt. Auf jeden Fall haben wir uns über Bewahrenswertes, Verbesserungswürdiges und Bemerkenswertes unterhalten.
Ich möchte hier einmal die Ergebnisse zusammenstellen und ggf. kommentieren.
Auf jeden Fall möchte ich allen danken, die dafür gesorgt haben, dass eine Diskussion zu Stande gekommen ist. Da kann ich noch so “nett” sein. Letzten Endes ist es meine Aufgabe, die Arbeiten zu bewerten. Um so schöner finde ich es, dass wir es in diesem Semester zu einer offenen Diskussionskultur geschafft haben.
Danke schön!
So, nun die Punkte, die wir angesprochen haben. Meine Bemerkungen sind kursiv gekennzeichnet.
Bewahrenswertes
Teambildung
Die Zusammenstellung der Teams nach dem Zufallsprinzip wurde von allen positiv gesehen. Dadurch haben sich neue Bekanntschaften gebildet, insgesamt haben sich alle näher kennen gelernt.
Das Vorgeben (und Annehmen) von projektspezifischen Rollen führte nach Meinung der Teilnehmer zu einer professionellen Arbeitsweise, die sich von der üblichen Gruppenarbeit erheblich unterscheidet.
In diesem Semester kam es zum ersten Mal zu einer umfangreicheren Zusammenarbeit zwischen den Projektteams. Fehlten in einem Team bestimmte Kompetenzen, so halfen Mitglieder eines anderen Teams aus.
Das sehe ich auch so positiv. Das liegt aber nur zum Teil an der Umgebung, die ich bereit gestellt habe. Zum größten Teil ist das das Werk der Teilnehmer. BTW, heute habe ich einen interessanten Artikel über Gruppen- vs. Teamarbeit gelesen, der passt gut zur Situation der Projektstudie ;-)
Regularien
In der Projektstudie wurde nicht nur die Art und Weise vorgegeben, wie sich die Teams zusammensetzen. Neben der Festlegung auf bestimmte Werkzeuge (Trac, Mercurial) wurden weitere “Spielregeln” von mir definiert. Dazu gehörten wöchentliche Statusreports, Protokollierung aller Besprechungen, Verwendung des Ticketsystems, u.s.w.
Diese Vorgaben sollen beibehalten werden, evtl. sogar ausgebaut werden, um einen der verbesserungswürdigen Punkte, die Arbeitsbelastung, abzumildern.
Ich bin immer wieder erstaunt, wie gut feste Regeln ankommen. Zuerst denke ich, dass diese als Einschränkung empfunden werden. Im Laufe des Semesters stellt sich heraus, dass diese Regeln eher helfen. Daher werde ich in Zukunft die Regularien im Sinne von Hilfestellungen weiter ausbauen. Angedacht (und von Ihnen bestätigt) sind: definiertes “Standardteam” (1 Projektleiter, 1 Dokumentator, 1 Qualitätsmanager, Rest Entwickler), definierte Entwicklungsumgebung (Maven, Hudson, Mercurial, Trac), definierte Ablaufumgebung (Portal Server), weitere Vorlagen.
Organisatorisches
Die regelmäßigen Präsenztermine wurden positiv aufgenommen. Wir haben uns zu den festen Terminen in der großen Gruppe getroffen, offene Punkte gemeinsam besprochen, ggf. haben einige ihre Arbeitsergebnisse präsentiert und anschließen haben die Projektteams separat gearbeitet.
Dadurch wurde ereicht, dass sich jedes Projektteam regelmäßig getroffen hat, offene Punkte schneller erkannt und behoben wurden. In normaler Gruppenarbeit passiert es oft, dass man sich zu selten trifft und erst gegen Ende entdeckt: die Einzelteile passen nicht zusammen.
Ebenfalls wurde positiv angesprochen, dass ich während der Präsenztermine (und darüber hinaus) ansprechbar war. Mein “Management by walking around” hat vielen Teams weitergeholfen. Das sollte nach Ansicht der Teilnehmer ebenso bewahrt werden, wie der Einsatz eines studentischen Coaches.
Dieser Coach hatte angeregt, dass sich alle Projektleiter gerade in der ersten Zeit zu einem Erfahrungsaustausch treffen. Auch dieses Vorgehen hat vielen geholfen. Solche teamübergreifenden Treffen sollen zukünftig auch für andere Rollen (Entwickler, Qualitätsmanager, …) stattfinden.
Es freut mich, dass mein Herumlaufen nicht als Spitzelversich gewertet wurde, sondern eine Hilfe war. Auch in Zukunft werde ich versuchen, einen studentischen Coach zu finden, der den Teilnehmern die Hemmschwelle mindert, zu fragen und ggf. zu eskalieren. Die übergreifenden Besprechungen halte ich für eine sehr gute Idee.
Inhaltliches
Ingesamt wurde der Lerneffekt der Projektstudie als groß eingestuft. Im Grundstudium wurden eher theoretische Inhalte gelernt, die nun angewendet werden konnten. Trotzdem wurden auch die eher theoretischen Inhalte dieses Semesters als nützlich für die Projektstudie anerkannt. Die Teilnehmer äußerten, dass sie sich selbst besser kennengelernt haben, insbesondere auch was ihre eigene fachlichen Ziele betreffen.
Seufz, das ist das Ziel der Projektstudie. Und wenn das erreicht ist, bin auch ich zufrieden ;-).
Verbesserungswürdiges
Arbeitsbelastung
Die Arbeitsbelastung wurde von sehr vielen als zu hoch angesehen. Einige meinten sogar, dass man sich in diesem Semester zwischen der Projektstudie und sonstigen Prüfungen entscheiden müsste. Es gab aber auch Stimmen, die meinten, die Belastung sei hoch, aber nicht zu hoch gewesen.
Sicher ist die Arbeitsbelastung bei einer Projektstudie nicht unerheblich. Die Projektstudie ist mit 6 Credits bewertet, dass sind 180 Stunden. De facto kommen noch die 2 Credits von Projektmanagement 2 hinzu, dass man auf eine Nettoarbeitszeit von einem Monat kommen kann.
Ich denke, die Gründe für die als hoch empfundene Arbeitsbelastung sind vielfältiger Natur. Zunächst einmal ist es die erste Projektstudie im Studium. Vorher wurden Vorlesungen und Übungen besucht, bei denen man selbst nicht zu sehr aktiv sein musste. Das ist in der Projektstudie definitiv anders. Zum anderen haben fast alle Projektteams ihr Arbeitspensum selbst bestimmt und sich dabei überschätzt. Möglicherweise aus Gründen des Nichtversagenwollens unterblieben korrigierende Maßnahmen. Sicher auch aus Angst um eine schlechte Note. Es gab zu viele Details bei der Entwicklung zu beachten, mit denen sich die Teilnehmer bisher so nicht beschäftigt haben. Die Rollenaufteilung war in einigen Teams nicht optimal.
Viele dieser Punkte lassen sich durch Hinweise, durch Coaching und durch Regelungen (siehe oben) verbessern. Auch sollte die Einstufung und der Arbeitsaufwand für die Projektstudie überdacht werden. Daran bin auch ich interessiert.
Hinweise
Die Teilnehmer wünschten sich weitere Hinweise zu einzelnen Regelungen, wie z.B. zur Möglichkeit einer fließenden Rollenverteilung in Form der Definition einer Kernrolle und möglichen Varianten. Auch einige Werkzeuge, wie z.B. Mercurial und Ant bedürfen einer weitergehenden Erklärung. Einer der Teilnehmer meinte:
Mercurial ist bestimmt ein tolles Werkzeug. Wenn es näher erklärt würde, brächte es für alle einen riesigen, umfassenderen Nutzen.
Die weiteren Hinweise werde ich ab nächstem Semester gerne geben.
Transparenz bei der Benotung
Viele Teilnehmer wünschten sich eine größere Transparenz bei der Notengebung, nach dem Motto: “Wenn ich folgendes mache (unterlasse), bekomme ich eine um X% höhere (niedrigerere) Note”.
Ich fand die Diskussion über den Sinn und Unsinn von Noten spannend. Lernt man für eine gute Note oder um etwas besser zu können? Das ist natürlich eine Frage, die jede(r) für sich selbst beantworten muss. Genauso wie die der Relevanz guter Noten im Zeugnis.
Die Zusammensetzung der Note ergibt sich aus den gewichteten Teilnoten “Codepräsentation”, “Individuelle Leistung gemäß eigener Rolle”, “Teamleistung” und “Leistung für das Team”. Ich selbst (und die meisten Führungskräfte wohl auch) wäre froh, wenn man projekt- und teamunabhängig über einen festen Katalog z.B. die Leistung für das Team messen könnte. So müssen wir uns mit Heuristiken behelfen und alle das Gehirn eingeschaltet lassen ;-)
Bemerkenswertes
Ich fand die sehr intensive Nutzung des Wikis besonders bemerkenswert. Ich habe zwar noch keine Statistik erstellt, aber in diesem Semester wurde mehr mit dem Wiki (Trac) gearbeitet, als in den Semestern vorher zusammengenommen (damals: DokuWiki und Mantis). Möglicherweise hängt dies auch mit der zunehmenden Nutzung der Wiki-Technologie im Grundstudium zusammen.
Die Teilnehmer bemerkten die sehr intensive Kommunikation, sowohl innerhalb der Teams als auch zwischen den Teams. Das hätten sie sich nicht so (positiv) vorgestellt. Die darüber hinaus persönlichen Erfahrungen waren für die meisten ein Highlight.
Jetzt beim Schreiben fällt mir ein weiterer Punkt ein: viele Teilnehmer haben sich mit dem “warum” beschäftigt. Das finde ich toll. Und noch besser ist es, wenn sich alle die Frage stellen: Warum?
Bemerkenswert fanden viele (inkl. mir) die gute Moderation der Retrospektive durch zwei der Teilnehmer. Und das schöne Protokoll ;-)
Falls ich etwas vergessen oder ungeschickt dargestellt habe, einfach eine E-Mail an mich. Oder hinterlassen Sie einen Kommentar zu diesem Blogeintrag.
java, Projektmanagement, projektstudie, Softwareentwicklung
