SCRUM in der Forschung

Das Prinzip von SCRUM ist einfach und einleuchtend: Die Dinge passieren ohnehin anders als geplant. Warum nicht gleich die Planung minimieren und standardisieren? Ja, genau. Ich merke das gerade selbst. Ich hatte schon länger überlegt, SCRUM in mein Forschungsdesign mit einzubeziehen, war gedanklich aber noch nicht in die Tiefe gegangen. Als ich eben damit anfing, merkte ich schnell, dass ich Annahmen, die ich in den letzten Blogposts getroffen hatte, so nicht mehr halten konnte. Ich musste also die letzten Posts alle noch einmal umschreiben. Das hat mich ziemlich ins rotieren gebracht.

Innovation in kreativen, komplexen Systemen

Plötzlich an drei Artikeln gleichzeitig zu schreiben, die man schon als fertig und in sich stimmig angenommen hatte, hat etwas von Chaos. Eine leichte Panik macht sich breit, da plötzlich ein komplexes vormals in sich stimmiges System zusammenbricht und – nicht nur an einer, nein, gleich an sehr vielen Stellen – neu sortiert und bearbeitet werden muss. Dann hat man da plötzlich holprig formulierte Stellen, merkt, dass es hinten und vorne nicht mehr zusammenpasst und dass man nicht nur hier sondern auch dort und dort und da etwas tun muss. Wie kann man diesen kreativen Prozess öffentlich managen, ohne seine Leser auf eine Geduldsprobe zu stellen oder sie davon zu überzeugen, dass der spontane Schreiber keine Ahnung hat, was er/sie da tut? Diese Frage hebe ich mir für einen weiteren Post auf. Ich stelle jedenfalls fest, dass ein Blog sich nicht für derartig spontan auftretende Iterationsstufen eignet. Oder wird man in einer Öffentlichen Wissenschaft solche kreativen Phasen des Aufbruchs und der Zerstörung erdulden müssen, weil das eben dazu gehört? hmmm…

Der Vermittlungsbezug bei SCRUM als didaktische Methode

Aber zurück zum Thema. In diesem Beitrag werde ich noch genauer zu erklären, welche Elemente von SCRUM in das Gesamtkonstrukt im Rahmen des Forschungsprojektes eingebracht werden sollen. In einem Design Based Research Ansatz geht es ja darum, einen Prototypen zu erstellen. Dieser soll etwas vermitteln. Ich möchte an dieser Stelle den von mir angenommenen Vermittlungsbezug erläutern. Einschub: Wie konnte ich nur so töricht sein zu glauben, man könnte Forschern ein bereits fertig gestaltetes Prozess-Design unterschieben, das sie dann Schritt für Schritt durchlaufen? Man würde sich – zu recht – bevormundet fühlen und hätte keinerlei Motivation, an einem solchen Projekt teilzunehmen.

Im SCRUM gibt es folgende Rollen: Scrum Master, Project Owner, Developer Team, Stakeholder. Der Project Owner sorgt dafür, dass die Produkt-Spezifikation, die in SCRUM in Form von User-Storys kommuniziert wird, gut umgesetzt wird. Das Developer Team entwickelt das Produkt. Die Stakeholder testen und geben Feedback. Der Scrum Master kann als Facilitator bzw. Vermittler gesehen werden. Er macht in seiner Rolle keine Vorgaben oder vermittelt konkrete Lehrinhalte oder sondern sorgt stattdessen dafür, dass die SCRUM-Regeln eingehalten werden. Dabei setzt er u.a. auch Coaching ein. (Regeln siehe… ScrumGuide)

Ein neues Forschungsdesign muss her

Mein bestehendes Forschungsdesign ist – wie oben erläutert – gerade SCRUM zum Opfer gefallen. (vielleicht sollte ich hinzufügen, dass ich morgen auf dem JFMH16 nun ein Forschungsdesign vorstellen werde, das ich gerade eben im Rahmen eines kreativen Prozesses umgeworfen habe… Ich habs im Griff: Eine Folie ändern und schon stimmt wieder alles.)

Also… Klappe die Zweite: Kein Audiovisueller Onlinefragebogen! Die Befragung zu den Einstellungen der Wissenschaftler in Bezug auf Öffentliche Wissenschaft erfolgt während des Daily Scrum, der ja ohnehin stattfindet. Dadurch entsteht kein zusätzlicher Aufwand. Der Daily Scrum dauert 15 Minuten. Jedes Projektmitglied beantwortet drei Fragen: Was habe ich heute gemacht? Was hat mich daran gehindert? Was werde ich bis morgen machen?

Wenn Wissenschaftler öffentliche Praktiken tatsächlich als hinderlich ansehen, dann wird dies durch die tägliche Beantwortung der Fragen deutlich. Sehr wesentlich ist, dass der Daily Scrum aufgezeichnet wird. Es stellt sich die Frage, ob die teils sehr persönlichen Antworten öffentlich gemacht werden sollen. Ich denke nicht, denn sonst könnte Befangenheit entstehen. Auch in SCRUM Projekten erfolgt der Daily Scrum Team-intern. Es sollten hier also die üblichen Regeln gelten: keine personenbezogene Auswertung und Darstellung von Daten, keine Veröffentlichung.

Ein weiterer Aspekt brennt mir gerade auf den Nägeln. Rufen wir uns noch einmal meine Forschungsfragen ins Gedächtnis:

Untersuchungsgenstand des hier vorgestellten Dissertationsvorhabens soll daher die gemeinschaftliche Wissenskonstruktion von Forschern im Rahmen öffentlicher Wissenschaft sein. Fokus liegt auf der Fragestellung wie und an welcher Stelle die Wissensproduktion öffentlich gemacht werden kann, als wie praktikabel und sinnvoll sich dies erweist, welche Herausforderungen im Prozess entstehen, welche unterschiedlichen Haltungen die Forscher dazu entwickeln und welche Kompetenzen sie benötigen. (Hueber 2016)

Im Rahmen von SCRUM werden ja keine Prozesse festgelegt. Das bedeutet, dass die Forscher selbst entscheiden, ob sie offen arbeiten oder nicht. In irgend einer Form muss es aber möglich sein, zumindest ein gewisses Maß an Offenheit vorzugeben. Sonst würde das Forschungsprojekt seine Zielsetzung, nämlich Öffentliche Wissenschaft zu erforschen, nicht erfüllen können. Schließlich geht es darum, Wissenschaftlern Open Science zu vermitteln – wie die Prozesse dabei durchgeführt werden ist tatsächlich nicht wichtig. Aber es ist wichtig, dass die Projektteilnehmer die Teilhabe an einer Open Science Community erfahren und offene Prozesse umsetzen. Nur so können sie sich ein Bild machen und etwaige Nachteile bzw. Vorteile erkennen.

Wie auch immer ich das lösen werde, eine meiner Forschungsfragen bezieht sich ja auch auf Praktikabilität. Vielleicht ist es ja gar nicht praktikabel, maximale Offenheit zu pflegen. Ein Beschreibungsmodell, das sich zur Aufgabe macht, sich in einem realen Projekt zu erproben, sollte auf Basis von Forschungsergebnissen einen sinnvollen, praktikablen und angemessenen Grad an Offenheit entwickeln.

Es wird neben SCRUM in jedem Fall eine zweite Vermittlungsebene geben müssen, die sich auf kulturelle und soziotechnische Praktiken bezieht. Optimal wäre es, sich an eine bestehende Open Science Community anzudocken. Dann sind diese wenig greifbaren Elemente öffentlicher Wissenschaft schnell erlernt. Doch findet sich da eine passende Community? Die zweite Vermittlungsebene (neben SCRUM) ist ein Thema für einen weiteren Post.

(selfnote: neben den „Daily Scrum Questions“ muss ich auch noch definieren, wie ich die anderen Artefakte, die bei SCRUM anfallen für das Beschreibungsmodell auswerten und verwenden möchte und ob die zur Verfügung stehenden Daten ausreichen, alle Aspekte meines Wissensanspruchs abzudecken)

(selfnote2: Vergessen wir mal nicht, dass ich das Vorhaben morgen vorstellen werde und dort vermutlich auch wieder neuen Input bekomme. Wichtig sind auch die Forschungskooperationen.)

(selfnote 3: Ach, da fehlt ja auch noch der Input vom Cosca – Geschichte der Öffentlichen Wissenschaft, CERN… )

(selfnote4: Und da fehlt noch der Input vom Sommerfest. Gründe warum Öffentliche Wissenschaft nicht angenommen wird, außerdem pre und post Peer-Review)

Share SHARE
Dieser Beitrag wurde unter Agile, Open Science abgelegt und mit , , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*