Kanban in Forschungsprojekten: eine kurze Fallstudie

von DI (FH) Andreas Lettner, RISC Software GmbH

© iStock/tadamichi

18.05.2021

Agile Methoden in klassischen Forschungsprojekten einsetzen – geht das? Andreas Lettner, Experte und Agile Coach in der RISC Software GmbH beschreibt, wie ein Forschungsprojekt zum Erfolg geführt wurde. Dabei waren die Voraussetzungen alles andere als positiv. Jedoch, der Einsatz von agilen Methoden in einem laufenden Projekt ist möglich und zielführend – auch in der Forschung!

Prolog

Die RISC Software GmbH ist ein Forschungs- und Entwicklungsunternehmern und verbindet Forschung mit Anwendungen in der Praxis. Unsere Arbeitsweise in Entwicklungsprojekten ist klar – agile Methoden nutzen, um ziel- und werteortientiert individuelle Softwarelösungen für die User entstehen zu lassen. Wie funktionieren aber agile Methoden in klassischen Forschungsprojekten? Der vorliegende Bericht zeigt eine einfache Fallstudie, wie in einem Forschungsprojekt, unter schwierigen Umständen, eine Auswahl an agilen Methoden eingesetzt wurde, um eine Verbesserung zu erreichen.

Eines noch: Die vorliegende Fallstudie zeigt Probleme, welche in einem Projekt auftraten. Projekte werden von Menschen abgewickelt – unseren Kolleg*innen. Und deshalb ist es wichtig, dass wir wertungsfrei mit den Informationen umgehen, welche wir erhalten. Wir sind allesamt keine Maschinen und das ist gut so.

1. September 2020

Ich erhalte eine E-Mail bezogen auf ein Projekt, bei welchem diverse Probleme im Anmarsch sind. Konkret besteht die Befürchtung, dass das Projekt nicht rechtzeitig fertiggestellt werden könnte und dass die Mitarbeiterzufriedenheit leidet. Mit diesem Wissen vereinbare ich schnellstmöglich ein Gespräch mit dem Projektteam.

2. September 2020

Ich sitze in einem Besprechungsraum. Mit mir das Projektteam. Bestehend aus Data Scientists, Entwickler*innen, Projektkoordinatoren und jemand aus der “Chefetage”. Selbstverständlich mit genügend Abstand. Corona gibt es ja leider noch immer. Ich sehe einige verzweifelte Gesichter und in manchen einen Funken Hoffnung, dass wir etwas bewegen können. Ich bin mir da nicht mehr so sicher. Ich entdecke nämlich gerade, dass es sich um ein Forschungsprojekt handelt. Mein Puls steigt. Meine Erfahrung beschränkt sich auf agile Methoden in Kundenprojekten im Industrieumfeld. Wie gut diese bei Forschungsprojekten passen – keine Ahnung. Außerdem habe ich kein Verständnis von dem Thema. Vor mir sitzen Profis – das ist definitiv nicht meine Liga.

Ich beginne meine üblichen Fragen zu stellen. Hauptsächlich W-Fragen. Wo drückt der Schuh? Weshalb drückt er? Was hättet ihr gerne anders?….. Nach und nach ergibt sich ein Bild. Meine Notizen nach wenigen Minuten:

  • Auslastungslöcher
  • Kommunikation könnte besser sein
  • in Wirklichkeit 2-3 Teams
  • Motivation sinkt
  • andere Projekte haben Einfluss
  • Zieltermin fraglich
  • Inhalte noch nicht allen klar

Danach eine kurze Pause. Ich sehe meine Notizen und werde optimistischer. Mir fällt ein Stein vom Herzen – das haben sie sicher alle bemerkt. Ich sehe Probleme und Herausforderungen vor mir, die man doch in vielen Projekten hat. Ich bedanke mich für die Informationen und mache einen Folgetermin aus, wo wir erste mögliche Maßnahmen festlegen möchten.

7. September 2020

Die gleiche Runde wie vor wenigen Tagen. Im Gepäck habe ich ein paar Vorschläge, welche mit dem Team besprochen werden.

Maßnahme 1: Product Owner und Verantwortlichkeiten

Bisher wurde die inhaltliche Koordination von einer Projektkoordinatorin übernommen. Da sie jedoch im Rahmen der Forschungstätigkeit und dem dazugehörigen organisatorischen Overhead nicht genügend Zeit aufbringen kann, wir ein Product Owner eingesetzt. Die Projektkoordinatorin übernimmt quasi die Rolle eines Stakeholders und stellt eine primäre Vision, welche dem Forschungsantrag entspricht. Der Product Owner entwickelt die Produktziele und -anforderungen. Bis hier gibt es kaum einen Unterschied zu einer herkömmlichen Produktentwicklung.

Eine Kleinigkeit ist doch anders: in herkömmlichen Projekten sammelt ein Product Owner Feedback von den Anwendern und lässt dieses in die weitere Produktentwicklung einfließen. Im Forschungsprojekt verlagert sich das auf eine andere Personengruppe – die Forscher. In unserem Fall die Data Scientists. Product Owner, Projektkoordinatorin und Data Scientists legen gemeinsam den weiteren forschungsrelevanten Weg fest. Der Product Owner entwickelt daraus wieder die nächsten Ziele und Anforderungen für die Entwickler*innen.

Maßnahme 2: Kadenzen und ein paar damit verbundene “Kleinigkeiten”

Die Kommunikation im gesamten Team soll fokussierter und reger stattfinden. Notwendig ist vor allem ein regelmäßiger Austausch der Subteams. Wir legen ein wöchentliches Meeting fest. Inhaltlich ist die initiale Idee ein hybrid aus Events, welche uns aus Scrum ein Begriff sind:

  • Review – was wurde gemacht?
  • Refinement – was wird gefordert und wozu?
  • Planning – was wird als nächstes gemacht?

Warum nur 1 Meeting und warum jede Woche? Wir möchten kleine Veränderungen durchführen und die Zeit in den Besprechungen niedrig halten. Zumindest ist es einfacher zu koordinieren, wenn nur 1 Termin pro Woche geplant ist.

Dieses wöchentliche Meeting hat aber auch einige “inoffizielle” Gründe:

  • das bisher lineare Vorgehen wird in eine iterativ-inkrementelle Entwicklung geändert
  • die Entwickler*innen haben ein fixes, unveränderbares Paket für einen Entwicklungszeitraum (analog zu einem Sprint bei Scrum)
  • bessere Messbarkeit der Entwicklungsgeschwindigkeit und Erhöhung der Vorhersagbarkeit
  • wir erhalten hoffentlich schnell ein messbares Feedback, ob unsere Maßnahmen funktionieren

Maßnahme 3: Transparenz

Im Projekt existiert bereits ein Backlog mit der Vision bis Ende 2020 und ein Kanban-Board für die Entwickler*innen und Data Scientists gemeinsam. Dennoch ist ein Status nicht schnell und einfach eruierbar und somit leidet auch die Vorhersagbarkeit, was die Zielerreichung bis Ende 2020 betrifft.

Wir teilen das Board in mehrere Bereiche:

  • Der Product Owner und die Projektkoordinatorin erhalten eine eigene Sicht auf die Anbahnung. Das Backlog erhält einen Prozess. Darin findet auch das Refinement seinen Platz.
  • Die Subteams (Data Scientists und Entwickler*innen) erhalten je ein eigenes Board, da sie auch unterschiedliche Rhythmen und Prozesse haben.

Das war es soweit. Die Maßnahmen wurden gemeinsam festgelegt. Ein paar Tage später wird noch ein initiales Refinement durchgeführt und die bestehenden Aufgaben in den neuen Prozess eingegliedert. Die “Weeklies” finden statt und es wird viel diskutiert. Langsam merkt man aber eine Veränderung. Machen wir einen Zeitsprung zum Ende des Jahres.

1. Dezember 2020

Es hat sich viel getan. Nicht im vereinbarten Prozess. Der wurde kaum angefasst. Aber in den Kanban-Boards ist so einiges zu erkennen. Außerdem ist heute ein besonderer Tag. Das Projekt wird beendet. 3 Wochen früher als ursprünglich geplant, aber es gibt Gründe, welche das notwendig machen.

Die gute Nachricht: die Inhalte des Forschungsantrages wurden erfüllt. Knapp – ja, so ehrlich muss man sein, aber sie wurden erfüllt. Vor 3 Monaten war die Aussage des Teams eher pessimistisch bis Ende Dezember 2020! Gespannt mache ich eine Auswertung und betrachte die Metriken. (siehe Abbildung 1: Cumulative Flow Diagram)

Die initiale Entwicklungsgeschwindigkeit (punktierte Linie) hätte tatsächlich nicht ausgereicht um das Projektziel (blaue Linie) zu erreichen. Durch die durchgeführten Maßnahmen war eine entsprechende Performanzsteigerung zu erkennen, welche den Projekterfolg möglich machten. Nein, natürlich sind es nicht die Maßnahmen, die das ermöglichen, sondern immer noch die Personen, die letztendlich die Arbeit leisten und sich auf diese Versuche einlassen. Die Maßnahmen unterstützen letztendlich das Miteinander.

Auch ist noch gut zu erkennen, dass es etwas Zeit brauchte, bis die Entwicklungsgeschwindigkeit zunahm. Daher zeigt sich einmal mehr, dass das wichtigste Mittel, welches wir haben, die Geduld ist. Wir hatten nichts mehr verändert. Es dauerte einfach nur, bis sich alles einspielte.

In der Zeit von Mitte Oktober bis Mitte November ist eine äußerst konstante Entwicklungsgeschwindigkeit feststellbar, welche auch noch die durchschnittliche Geschwindigkeit deutlich übertrifft. Die Kontinuität ist auch anhand der Delivery Rate gut erkennbar (Abbildung 2). Tatsächlich ergab sich Mitte bis Ende Oktober eine positive Stimmung im Team in Richtung erfolgreichen Projektabschluss. (siehe Abbildung 2: Kontinuität)

Zuletzt sind in Abbildung 3 noch gut die wöchentlichen Meetings zu erkennen, welche aufgrund des Refinements und Plannings entstehen. (siehe Abbildung 3: Plateaus)

Eine saubere Analyse verlangt aber auch, dass man nach den Ursachen fragt, weshalb vor den Maßnahmen das Projekt nicht “performte”. Der Grund für 2020 ist klar – Corona. Auch uns hat es getroffen, da wir einen nicht unerheblichen Teil an Kundenprojekten abwickeln und es so kurzfristig zu Kapazitätsschwankungen kam. Aber eines lässt sich an diesem Beispiel gut zeigen:

Agilität und motivierte und engagierte Mitarbeiter*innen erzeugen eine Resilienz gegen Corona. Selbst in Forschungsprojekten, wo man kaum Empfehlungen findet, wie agile Methoden sinnvoll eingesetzt werden können.

Nachwort für Agilisten

Der Titel der Fallstudie beinhaltet Kanban und im Text wird teilweise dennoch Scrum referenziert. Es handelt sich selbstverständlich nicht um Scrum, was verwendet wurde. Von Scrum ist man hier doch noch deutlich entfernt und es hätte aufgrund der Kurzfristigkeit und anderer Faktoren wohl kaum Sinn ergeben.

Warum ist es Kanban? Wir starteten, wo wir waren. Wir führten kleine Veränderungen ein und beobachteten diese. Wir sorgten für Transparenz. Wir schufen Feedbackzyklen….

Warum verwendeten wir dennoch Scrum-Begriffe? Scrum hatte die letzten Jahre wohl ein besseres Marketing. Die Begriffe sind in vielen Teams einfach präsenter, werden sofort mit Agilität in Verbindung gebracht und es besteht auch schnell Einigkeit darüber, was damit gemeint ist. Kanban, Scrum, LeSS, SAFe, etc. bieten uns ein entsprechendes Repertoire an Methoden, welche uns helfen Projekte professioneller, wertorientierter und menschlicher abzuwickeln. Letztendlich sollte es egal sein, wie wir die Dinge nennen. Wir müssen nur das gleiche Verständnis dafür schaffen.

Autor

DI (FH) Andreas Lettner ist Head of Unit Domain-specific Applications und Head of Coaches in der RISC Software GmbH.

>> Lesen Sie mehr

Kontakt

RISC Software GmbH
Softwarepark 32a
4232 Hagenberg
www.risc-software.at


zur Übersicht

Das könnte Sie auch interessieren: