“Agile – What?” oder doch besser Why?

Ende August hatte ich die tolle Gelegenheit, bei einem Netzwerktreffen studentischer Unternehmensberater an der Technischen Hochschule Ingolstadt mehrere Workshops zu gestalten. Die Überschrift lautete zwar „Agile – What?“, doch die Jung-BeraterInnen merkten schnell, dass es mehr um das „Why“ als um das „What“ geht.

Denn warum machen wir das, diese Agilität? Wie die meisten nach ihrer ersten agilen Schulung wissen, ist Agilität mehr als ein Rahmenwerk. Zwar ist die Methodik die Basis, doch die funktioniert nur, wenn die formulierten Werte und Prinzipien gelebt werden. Oft fallen dann in Schulungen und Workshops Sätze wie: „Das ist mir ein bisschen zu esoterisch!“ oder „Ich brauche etwas, das einfach funktioniert!“ Um heute und in Zukunft zu überleben, brauchen Unternehmen Ideen, die zügig umgesetzt werden können. Doch es ist kein rationaler Prozess: Ideen können nicht wie am Fließband produziert werden, sondern entstehen oder eben nicht. Intuition ist daher jene Stärke, die mehr denn je benötigt wird. Wir merken, dass das Bauchgefühl eine große Rolle spielt.

Neben dieser menschlichen Komponente gibt es aber eine weit rationalere, systemische Komponente, die uns zeigt, warum man es mit der Agilität versuchen sollte.

Schöner scheitern – fail fast

William Ross Ashby formulierte schon in den 1950er-Jahren das nach ihm benannte Gesetz der erforderlichen Varietät. Dieses Gesetz besagt: Je größer die Varietät eines Systems ist, desto mehr kann es die Varietät seiner Umwelt durch Steuerung vermindern. Oder mit den Worten von Prof. Peter Kruse (siehe dieses Video): „[…] wo immer wir ein hochkomplexes dynamisches Problemsystem haben, brauchen wir im Minimum ein so komplexes dynamisches Lösungssystem. Doch von alleine besitzt ein Unternehmen nicht dieselbe dynamische Komplexität, wie die ihres Umfelds. Was es dazu braucht, ist eine Kultur, in welcher die Menschen die Möglichkeit erhalten, Dinge auch einfach mal auszuprobieren, um damit wirklich kreativ zu sein.“

„Fail fast“ sollte also das Motto sein. Ein Zustand, der gerade in Großunternehmen eher fern zu sein scheint. Fehler werden in einer hierarchischen Organisation direkt sanktioniert und Kreativität hat hier mehr mit dem „Tanz aus der Reihe“ zu tun. Ein möglicher Weg, den viele große Unternehmen wählen, ist die Veränderung der Kultur durch ein Change-Programm.

Das Kulturveränderungsprojekt – kann man Kultur wirklich entwickeln?

Ja, kann man, aber wie Professor Kruse schon sagte: Kultur ist eine indirekte Variable. Kultur ist leider keine Projektarbeit. Es können nur Rahmenbedingungen geschaffen werden, in denen sich die Muster einer Kultur in irgendeine Richtung entwickeln. Welche Richtung die Kultur einschlägt, ist dabei nicht vorhersehbar.

Diese Aussage bietet gerade den agilen Frameworks eine Steilvorlage. Denn Agilität bedeutet nicht mehr als flexibel, proaktiv, antizipativ, aber vor allem initiativ zu agieren, um notwendige Veränderungen anzustoßen. Agile Frameworks wie Scrum bieten die Möglichkeit, in regelmäßigen Abständen komplett neu auf diese Welt zu blicken, um womöglich eine völlig neue Richtung zu gehen.

Ein Beispiel: Die Entwicklung des Space Shuttles

1982: Das Space Shuttle der NASA wird fertiggestellt. Interessant im Kontext agiler Produktentwicklung ist dabei der Umstand, dass die Entwicklung über zwei Jahrzehnte gedauert hat und das Space Shuttle teilweise auf IT-Systemen aus den 1960ern aufbaute. Dieser sicherlich extreme, zeitliche und technologische Abstand zwischen dem Stellen der Anforderung und der Lieferung kann als Beispiel für ein Problem angesehen werden, das in den 1990ern mit Beginn der PC-Ära als sogenannte „application development crisis“ oder „application delivery lag“ bzw. als Software-Krise bekannt wurde. Mit der Verbreitung des PC änderten sich die Geschäftsmodelle immer rascher. Bei Entwicklungszeiten von mehreren Jahren konnte es daher passieren, dass die Lösung bei Fertigstellung veraltet war. Ein Projekt kann so als gescheitert betrachtet werden, selbst wenn die anfänglich festgelegten Anforderungen geliefert und der Budgetrahmen eingehalten werden.

Agilität ist Hinterfragen des Sinns

Neben dem Warum für Agilität soll es sie daran erinnern, ständig die Sinnhaftigkeit der zu leistenden Arbeit zu hinterfragen. Denn Agilität entsteht durch den Blick auf das Wesentliche, durch Achtsamkeit dem eigenen Tun gegenüber. Das Ausrichten des eigenen Handelns auf den größtmöglichen Wert. Das kontinuierliche Liefern eines für sich allein stehen könnenden Teilprodukts. Mit iterativen, reflexiven Abläufen schafft es Agilität, das Erreichte zu hinterfragen und die Wertschöpfung immer wieder auf das Wesentliche auszurichten. Ist das einfach? Nein. Aber dafür ist es ziemlich spannend und man schafft Wert! Vielen Dank an die TeilnehmerInnen, ich hatte sehr viel Spaß daran, mit euch die Themen zu erarbeiten! Ich wünsche euch viel Erfolg bei euren nächsten Projekten.

 

Der Bundesverband Deutscher Studentischer Unternehmensberatungen (BDSU) engagiert sich seit mehr als 25 Jahren als Dachverband und starker Netzwerkpartner für die führenden Junior Enterprises in Deutschland. An der Technischen Hochschule Ingolstadt wurde 2010 consult.IN gegründet, das inzwischen zu den zehn besten studentischen Unternehmensberatungen in Deutschland gehört. Über 70 hochmotivierte Studenten und Studentinnen sammeln hier während des Studiums Projekterfahrung für den Einstieg in die Berufswelt.

Foto: CC0 Creative Commons – pixabay, NASA-Imagery

Agilität muss man aushalten können – Szenen aus der Praxis

1. Sackgasse Selbstorganisation – wenn keiner pullt

Auch bei borisgloger consulting richten wir den Blick regelmäßig nach innen. Retrospektiven sind für uns ein fester Bestandteil, um gemeinsam herauszufinden, mit welchen konkreten Maßnahmen wir Verbesserungen herbeiführen können. Mit zwei weiteren Kollegen übernahm ich die Planung einer dieser Retrospektiven. Die Wahl fiel auf ein Format, bei dem das Team in zwei Gruppen aufgeteilt wird, die sich am Ende die erarbeiteten Ergebnisse gegenseitig vorstellen. Warum? Weil man bei diesem Format gleich zweimal Feedback bekommt: einmal in der Teilgruppe und danach beim Vorstellen und Challengen der Ergebnisse am Ende.

Alle waren mit dem Ergebnis zufrieden. Zuletzt sollten noch die zuständigen Kollegen gefunden werden, die die erarbeiteten Maßnahmen dann angehen und umsetzen würden. Die Frage „Wer kümmert sich drum?“ stand im Raum. Schweigen. Auch nach einer Weile gab es kein „hier“ zu hören. Selbst in selbstorganisierten Unternehmen ist das nicht unbedingt überraschend. Dennoch, für einige im Team war das höchst unbefriedigend. Die Gründe für die Zurückhaltung sind vielseitig: Die eigene Priorisierung der Aufgaben, wichtige andere Commitments am gleichen Tag etc. Wie schafft man es trotzdem, die Verantwortung zu verteilen? Das Pull-Prinzip, nach dem wir arbeiten, fordert, dass die Arbeit im agilen Kontext freiwillig gezogen und eben nicht angeordnet wird.

Option A: Vielleicht werden die definierten Maßnahmen später gezogen oder auch gar nicht, wenn anderes einfach höher priorisiert ist.
Option B: Der ScrumMaster weist daraufhin, dass die Aufgabe auch gemeinsam übernommen werden kann und motiviert dadurch neuere Teammitglieder, den Sprung ins kalte Wasser zu wagen.
Option C: Der Product Owner priorisiert diese Aufgabe höher und vermittelt damit, dass die Aufgabe wichtig ist und gezogen werden sollte.

Wenn Teams mit Scrum zu arbeiten beginnen, ist das freiwillige Pull-Prinzip oft schwierig zu akzeptieren oder schwer nachvollziehbar. Ist es nicht viel einfacher, Aufgaben direkt zu verteilen anstatt zu warten? Das wäre am Anfang tatsächlich einfacher. Nur, ist es eine nachhaltige Alternative, die Aktivitäten per Ansage zu verteilen? Wie groß ist dann die Wahrscheinlichkeit, dass sie mit der notwendigen Motivation und Konsequenz umgesetzt werden? Was bleibt dafür im Gegenzug liegen? Hier braucht es Mut, unterschiedliche Optionen auszuprobieren und darauf zu vertrauen, dass die Teammitglieder eine Lösung finden werden.

2. Commitment muss gelernt werden

Gleiches Thema, anderes Setting. Ich hatte zu einer teamübergreifenden Retrospektive eingeladen. Es sollten Vertreter von zwei Teams geschickt werden. Ich erhielt die Zusage aller Kollegen und bereitete die Retro vor.

13:59 Uhr am Tag der Retro – Wir warteten auf vier Teilnehmer. Dafür hatte ein Team noch weitere Kollegen mitgebracht. Enttäuscht über das Nichterscheinen der Kollegen schlug jemand vor, die Retro abzusagen oder zumindest dafür zu sorgen, dass aus jedem Team gleich viele Personen am Meeting teilnehmen würden, damit es gerecht blieb. Das kam für mich nicht in Frage.

Ich konnte die anderen überzeugen, die Retro genau mit jenen Personen durchzuführen, die gekommen waren – ein Grundsatz, der auch im Open Space Format Anwendung findet. Mit der Aussage „Diejenigen, die kommen, sind die richtigen“ haben wir unsere Retrospektive durchgeführt und sogar die Timebox eingehalten. Es kamen tolle Ergebnisse dabei heraus und das Meeting war ein voller Erfolg!

Auch hier waren die Beteiligten erst unzufrieden mit der Situation. Und auch in diesem Fall spielt das Prinzip der Freiwilligkeit eine Rolle. Im „Open Space“ kennt man zudem das Gesetz der zwei Füße, das besagt, dass jeder nur dann erscheint, wenn er oder sie etwas lernen oder einen Beitrag leisten kann. Das war in diesem Meeting der Fall.

Agilität braucht viel Geduld und Durchhaltevermögen. Die Beteiligten dürfen die Prinzipien selbst in schwierigen Situationen nicht fallen lassen, auch wenn es Zeit braucht, bis alle an Bord sind und die agilen Werte und Prinzipien leben können.

Bis dahin gilt: In solchen Situationen muss man Agilität einfach mal aushalten können.

Foto: CC0 Creative Commons – pixabay, Pexels

Scrum4Schools: Agiles Arbeiten im verteilten Hochschulprojekt

Ein weiteres SCRUM4SCHOOLS-Projekt nimmt Fahrt auf. Gemeinsam mit der FH des BFI in Wien, einer berufsbegleitenden Studieneinrichtung, mit der wir schon frühere Produktentwicklungserfolge wie unsere Scrum-Checklist für Android und iOS feiern konnten, entwickeln wir nun eine Lernplattform, auf der wir das Wissen unserer Consultants an einem Ort im Internet konsolidieren und als Open Source anbieten. Als Product Owner des Projekts bin ich natürlich sehr gespannt, wie den Studenten das Arbeiten mit Scrum gefällt. IT-Genie Sebastian Mühlbauer ist nicht nur unser Kollege bei borisgloger consulting, sondern auch Teil des studentischen Entwicklerteams schon machen konnte. Welche Erfahrungen er in diesem Projekt gemacht hat, verrät Sebastian Mühlbauer im folgenden Interview.
Hi Sebastian, welche Rahmenbedingungen gelten für das Projekt?
Im Rahmen unseres Studiums müssen wir ein zweisemestriges Projektpraktikum absolvieren. Dabei sollen wir neben dem regulären Studium gemeinsam mit einem echten Auftraggeber ein Projekt durchführen. Unsere Projektgruppe hat sich für borisgloger consulting entschieden, weil es der einzige Auftraggeber war, der uns angeboten hat, agile Methoden auszuprobieren. Zurzeit sind wir fünf Personen exklusive FH-Projektbetreuer und dir als Product Owner.
Hast du vor diesem Projekt schon einmal mit agilen Methoden gearbeitet?
Nicht wirklich. Sowohl in meinem jetzigen als auch in meinem letzten Studium habe ich immer mit traditionellen Projektmanagementmethoden gearbeitet. Unter anderem haben wir ein fiktives Projekt nach den Regeln des IPMA/PMA Projekthandbuchs durchgespielt.
Wie hast du den Einstieg in Scrum empfunden?
Vor allem die vielen Scrum-spezifischen Begriffe waren anfangs nicht leicht merkbar – Eselsbrücken haben aber recht gut geholfen. Dadurch, dass wir in Scrum mit dem Prinzip “Learning by Doing” eingestiegen sind, hat es nicht allzu lange gedauert bis zumindest der Scrum-Flow gesessen hat. Man lernt aber immer noch jeden Tag etwas Neues dazu. Das Spannendste, was ich mitnehmen konnte, war die Fokussierung auf ein funktionierendes Minimum Viable Product statt auf das komplett fertige Produkt. Die Methodik stammt aus dem Lean-Startup-Konzept. Man entwickelt nur das Mindeste, das man braucht, um das Produkt zum Fliegen zu bringen. Wenn wir nur unser Endprodukt als Ziel gehabt hätten, hätten wir wohl um einiges länger dafür gebraucht, einen funktionierenden Prototyp zu erstellen.
Das Projektteam arbeitet an verteilten Orten. Wie bekommt ihr das mit der Synchronisation hin?
Unsere Kommunikation und Kollaboration findet größtenteils über das frei zugängliche Slack und Trello statt. Für Dateien verwenden wir eine Google Drive, die auch in der kostenlosen Version mit den zwei Tools verbunden werden kann. Die Lernplattform entwickeln wir zentral auf einem Webspace, der uns von borisgloger consulting zur Verfügung gestellt wurde. Da alle unsere Teammitglieder nebenbei berufstätig sind, mussten wir die Scrum-Meetings auf unsere speziellen Bedürfnisse anpassen: Wir haben alle zwei Wochen ein eineinhalb- bis zweistündiges Skype-Meeting, bei dem das Entwicklerteam aus Wien mit dem Product Owner in Stuttgart die Synchronisation abwickelt. Darüber hinaus sieht sich das Entwicklerteam auch immer wieder auf der Fachhochschule. Wir versuchen Besprechungen also in unseren FH-Alltag einzubinden, um effizient arbeiten zu können.

Dein Studium ist berufsbegleitend. Konntest du agile Methoden schon in deine Arbeit einfließen lassen?
Da ich durch das Projekt meinen Weg zu borisgloger consulting gefunden habe: ein ganz klares Ja. Auch darüber hinaus konnte ich in diversen ehrenamtlichen Projekten, in denen ich mitarbeite, bereits Teile des agilen Projektmanagements umsetzen – sei es die Visualisierung auf Taskboards oder die Verbesserung der Meetingkultur mit dem, was wir in der Scrum-Einschulung von Damla Nalbant gelernt haben. Ich versuche hier, konstant Neues zu probieren und meinen Horizont in diesem Bereich zu erweitern. Bis jetzt hat es gut geklappt.
Sebastian, vielen Dank für das Interview – ich wünsche dir noch viel Erfolg im Projekt.

Scrum4Schools – IMS Maria Lanzendorf: Wo Jugendliche die Geschichte selbstorganisiert erforschen

Scrum4Schools ist in die nächste Runde gegangen – dieses Mal in Österreich. Samuel Plessing ist Geschichtslehrer an der Interessenorientierten Mittelschule (IMS) Maria Lanzendorf in Niederösterreich und er hat sich mit einer 4. Klasse (in Deutschland wäre das die 8. Klasse) auf das Experiment Scrum im Unterricht eingelassen. Kurzerhand hat er seinen Unterricht in den letzten Wochen vor dem Schulende umgestaltet.
Samuel Plessing schlüpfte dafür in die Rolle des Lehrmeisters (in Scrum: Product Owner), und formulierte sein Ziel klar: Da im Lehrplan der 2. Weltkrieg vorgesehen war, bekam jedes Lernteam den Auftrag, ein Büchlein mit Zeitzeugenberichten zu erstellen. „Mir war wichtig, dass die Schülerinnen und Schüler durch den Kontakt mit noch lebenden Zeitzeugen ein besseres Bewusstsein für die Geschehnisse dieser Zeit entwickeln konnten“, beschreibt Samuel Plessing seine „Vision“. Jeweils vier bis fünf Schülerinnen und Schüler sollten an einem Büchlein arbeiten. Zur besseren Orientierung wurden Teilziele mit entsprechenden Anforderungen vorgegeben: Ein Teilziel war beispielsweise, über das Alltagsleben in den Jahren 1937 bis 1955 zu berichten. Als Anforderungskriterien wurde definiert, dass sich die Schüler dabei auf die Kindheit konzentrieren sollten, aus welcher Region der Zeitzeuge stammte und welche Veränderungen der Anschluss Österreichs mit sich brachte. Ansonsten durfte jedes Lernteam seiner Kreativität freien Lauf lassen und Bonuspunkte sammeln, denn am Ende des Sprints wurde im Klassenverband das beste Büchlein gekürt – die Sieger erhielten einen Preis.

Wie lief der Unterricht nach den Prinzipien von Scrum ab?

Zu Beginn jeder Arbeitseinheit, ob in der Schulstunde oder in einem selbst festgelegten Zeitfenster zuhause, traf sich jedes Lernteam zum Daily, um sich optimal abstimmen zu können: Welche Anforderungen wurden schon behandelt, was soll in der kommenden Einheit von wem erledigt werden und wo wird noch Hilfe benötigt? Am Beginn jeder neuen Woche fand ein Review statt, in dem jedes Lernteam seine Teilziele im Plenum präsentierte. Durch die unterschiedlichen Kompetenzen der Lernteam-Mitglieder fiel es zu Beginn nicht jedem Schüler leicht, sich auf diese neue Art des Arbeitens einzulassen. Der entstehende Teamspirit trug allerdings dazu bei, dass dieses Gefühl schnell verflog und die Schüler sich gegenseitig unterstützten und bestärkten.

Benotung: Die SchülerInnen entwickeln eine differenzierte Sicht auf Leistung

Am Ende des Sprints wurde jedes Teammitglied individuell benotet. Zunächst durfte jeder Schüler und jede Schülerin eine Selbsteinschätzung an Samuel Plessing kommunizieren, anschließend wurde gemeinsam im Team über die Benotung entschieden. Bei der individuellen Bewertung hatten sich einige Teammitglieder selbst eher schlechter bewertet als andere im Team – warum? Ein Schüler begründet dies damit, dass er weniger in Kontakt mit dem Zeitzeugen war als seine Teammitglieder. Aus seiner Perspektive hatte er weniger zum Produkt beigetragen. Doch was hier schön zu beobachten war: Die anderen Teammitglieder bestärkten den Schüler sofort und hoben hervor, dass er andere Teilaufgaben bearbeitet hatte, ohne die das gesamte Team nicht das liefern hätte können, was das Zeitzeugenbüchlein nun ausmachte. Die Schülerinnen und Schüler hatten also ein Gefühl dafür entwickelt, dass für eine gute Leistung – oder ein gutes „Produkt“ – weit mehr notwendig ist als das Offensichtliche und jeder Beitrag einen Wert hat.

Retrospektive: Lernen aus dem eigenen Tun

Am Sprintende waren viele tolle Zeitzeugenbüchlein entstanden und fast alle Jugendlichen konnten die Note 1 erzielen. Darüber hinaus hatte den Schülerinnen und Schülern das Arbeiten mit Scrum wahnsinnig viel Spaß bereitet. Samuel Plessing hat die Rückmeldung bekommen, dass den Jugendlichen vor allem das selbstorganisierte Arbeiten gefallen hat und damit die Möglichkeit, sich die Aufgaben selbst einteilen zu können. Auch dem Herrn Lehrer selbst machte der Unterricht nach agilen Prinzipien viel Freude, weil auch er über den Tellerrand hinausblicken konnte. Er war zunächst überrascht und dann motiviert davon, wie sehr das Teamwork in seiner Klasse aufgeblüht ist. Völlig verblüfft habe ihn das selbstorganisierte Arbeiten und Denken seiner Schülerinnen und Schüler, durch das ganz unterschiedliche Sichtweisen und Perspektiven zum Vor-schein kamen, die im normalen Frontalunterricht vermutlich verborgen geblieben wären. „Ich denke, wenn man die jungen Menschen schon in der Schule mit Vorgehensweisen wie Scrum arbeiten lässt, sind sie ziemlich gut auf die moderne Arbeitswelt vorbereitet“, ist Samuel Plessing überzeugt.
Das Gewinner-Team des Zeitzeugenprojekts hat übrigens einen Gutschein für den Wiener Prater bekommen, den es bei dem Ausflug einlösen konnte, den die Klasse zum Schulabschluss gemeinsam dorthin gemacht hat. An der Interessenorientierten Mittelschule in Maria Lanzendorf geht es im Herbst übrigens mit Scrum im Unterricht weiter: Eine zweite Klasse (6. Klasse in Deutschland) wird in Geschichte und Englisch damit arbeiten. Wir sind gespannt und werden berichten!

Foto: CC0 Creative Commons – pixababy, geralt

Agile Game Experience: Keep Talking and Nobody Explodes

Bei unserer zweiten Agile Game Night in Frankfurt haben wir den Schwerpunkt auf Kommunikation gelegt. Eines der beiden Spiele war „Keep Talking and Nobody Explodes“ bei dem das Team innerhalb von fünf Minuten eine Bombe entschärfen muss.

Die Ausgangslage

Aus den insgesamt 13 Teilnehmern haben wir drei Teams gebildet. In jedem Team durfte sich eines der Mitglieder an den Laptop setzen, auf dem zuvor die entsprechende Software zum Spiel installiert worden war. Es gibt Bomben mit verschiedenen Schwierigkeitsleveln, wobei wir mit der drittleichtesten Stufe gestartet haben. Sobald das Spiel beginnt, sieht das Teammitglied am Laptop, der „Bombenentschärfer“, eine Bombe, die aus mehreren Modulen besteht, die einzeln entschärft werden müssen. Die Anleitung zur Entschärfung der Module hat der Bombenentschärfer selbst nicht, sondern sein Team. Damit die Bombe nicht in die Luft fliegt, muss er präzise erklären, wie sie aussieht und das Team muss auf Basis dieser Informationen mithilfe der Anleitung schnell genug den richtigen nächsten Schritt ermitteln.

Agile Game Experience

(c) borisgloger consulting

Die Schwierigkeit

Natürlich handelt es sich in der Anleitung um Texte, die unter Zeitdruck schnell falsch gelesen werden können. Es sind Knobelaufgaben, die an ein Escape-Game erinnern und die ein „Um-die-Ecke-Denken“ erfordern. Die Kunst ist es, das richtige Maß an Vorüberlegungen und Trial-and-Error zu finden.

Der Deming Cycle in kurzen Iterationen

Agile Game ExperienceDirekt vorab hatten wir den Teams mit auf den Weg gegeben, dass sie nach jeder Bombenentschärfung, ob erfolgreich oder nicht, eine kurze Retrospektive durchführen sollten, um ihre Vorgehensweise zu optimieren. Dabei stellten die Teams beispielsweise fest, dass es bei einigen Modulen durchaus sinnvoll war, sich Notizen zu machen oder dass es effizienter war, wenn die Teammitglieder sich auf verschiedene Module spezialisierten.

Unsere Erkenntnisse aus dem Debrief

In der ersten Runde waren die Beschreibungen der Bombenentschärfer für die Teams sehr abstrakt, da sie selbst kein Bild vor Augen hatten. Die Entschärfung der Module lief in den folgenden Runden deutlich reibungsloser, da jedes Mal ein anderes Teammitglied am Laptop saß, das gezieltere Fragen zu ihm bereits bekannten Modulen stellen konnte.
Stellen wir hier einmal eine Verbindung zum Scrum-Alltag und zum Sinn multidisziplinärer Teams, die gemeinsam User Storys bearbeiten. Erst wenn ich als Fachmitarbeiter ein Gefühl dafür habe, wie die Entwicklungsumgebung der IT-Mitarbeiter aussieht, kann ich sinnvolle Fragen stellen und zur innovativen Lösungsfindung beitragen – und umgekehrt.
Agile Game ExperienceKonkret heißt das: Ich muss über meinen Horizont auch in andere Bereiche schauen, damit mein Scrum-Team von der Interdisziplinarität profitieren kann. Dadurch eigne ich mir das notwendige Vokabular und Grundwissen an, damit im Team alle effizient an der Produktentwicklung arbeiten können. Neben dieser Haupterkenntnis haben die Teilnehmer*innen auch den Mehrwert der Retrospektiven nach jeder Entschärfung unmittelbar wahrgenommen und sehr viel Spaß gehabt. Es wurde viel gelacht, mitgefiebert und nach jeder erfolgreichen Bombenentschärfung haben wir den Triumph genossen.

Interesse geweckt?

Wer das Spiel selbst testen möchte, kann es unter diesem Link um € 12,99 herunterladen, außerdem gibt es online das kostenfreie Handbuch dazu.
Durch die kurzen Spielzeiten reicht eine Spieldauer von 30 Minuten, die entsprechend dem Workshopaufbau auch ausgedehnt werden kann. Aus meiner Sicht eignet sich das Spiel hervorragend zum Teambuilding in bereits bestehenden Scrum Teams, um zwischendrin das Teamgefühl durch gemeinsame Erfolgserlebnisse und Erkenntnisse zu stärken.
Viel Spaß beim Testen und meldet euch einfach, wenn ihr Fragen haben solltet.

Foto: CC0 Creative Commons – pixabay, OpenClipart-Vectors

Mut zum Spiel – im Unternehmen!

Als Abwechslung zu monotonen Meetings werden in Unternehmen regelmäßig mehrstündige und sogar mehrtägige Workshops abgehalten. Aus meiner Sicht wird dabei in den seltensten Fällen das volle Potential dieser Workshops ausgeschöpft. Zwar wird viel auf Flipcharts und Post-its festgehalten, nachhaltig wirken die gewonnenen Erkenntnisse jedoch nur, wenn der Moderator es schafft, Emotionen zu wecken. Spiele lösen bei jedem Menschen im Kindesalter die größten Emotionen und damit auch die nachhaltigsten Lernschritte aus – daher nutze ich diesen Effekt gerne für erfolgreiche Workshops im Business-Kontext und kann es wärmstens empfehlen.

Welche Voraussetzungen sind nötig, um agile Spiele im Unternehmen anwenden zu können?

  1. Vertrauen in den Moderator

    In den meisten Unternehmen sind Spiele weit davon entfernt, das Medium der Wahl zu sein. Im Gespräch mit Kunden, Bekannten und Freunden begegnet mir regelmäßig der Zweifel, ob Spiele wirklich zielführend für die Kommunikation zwischen Erwachsenen sind. Meine klare Antwort darauf ist: Ja, sie sind es!
    Vor allem für unternehmensinterne Moderatoren ist es wichtig, ihre Kompetenzen zunächst durch unkonventionelle Methoden unter Beweis zu stellen. Ob man vorab durch die Visualisierung eines Meetings oder durch die Einführung kreativer Retrospektiven geglänzt hat: Das alles ist für die initiale Unterstützung der Teilnehmer und für die Umwandlung von Skepsis in Begeisterung entscheidend.

  2. Wahl des richtigen Spiels

    Für einen Moderator ist es essentiell, das Ziel des Workshops vor Augen zu haben und es vorab mit den Stakeholdern oder Teilnehmern abzustecken. Ist das Ziel einmal definiert, empfiehlt es sich, in der Literatur (z. B. Gamestorming: Ein Praxisbuch für Querdenker, Moderatoren und Innovatoren) oder auf einer der zahlreichen Internetseiten (z. B. Agile Games oder tastycupcakes.org) nach geeigneten Spielen zu suchen. Bevor das Spiel der Wahl mit den Teilnehmern erprobt wird, gibt es noch die beiden folgenden Punkte zu beachten:

    a) Gute Einschätzung der Teilnehmer

    Wenn ich die Teilnehmer nicht kenne, mache ich mich über sie schlau. Wenn ich sie kenne, ist es umso einfacher einzuschätzen, wer von ihnen ein potentieller Unterstützer und wer ein Skeptiker sein wird. Wenn ich mir vorher diese Gedanken mache, kann ich später im Spiel die Rollen so verteilen, dass die positive Energie der Unterstützer im Spiel verstärkt wird. Für den Umgang mit Skeptikern kann ich empfehlen, vorab im Zweiergespräch die Zielsetzung und die Vorgehensweise des Spiels zu erläutern, um Diskussionen vor dem Spiel gering zu halten. Vor allem, wenn es sich um Führungskräfte handelt, die starken Einfluss auf ihre Mitarbeiter haben, kann dieser Widerstand verheerend auf die Zielerreichung wirken.

    b) Sehr gute Vorbereitung

    Wenn man in einem Unternehmen Spiele zum ersten Mal anwendet, ist eines der schlimmsten Szenarien, dass die Teilnehmer keinen Mehrwert darin erkennen. Jeder weitere Versuch, Spiele einzusetzen, wird dann zu einem Hindernislauf. Hier hilft die ständig wachsende Agile Community, die in Meetups neue Spiele mit motivierten Teilnehmern erprobt und mit ihnen in einer Retrospektive analysiert, welche Erkenntnisse jeder Teilnehmer für sich und ggf. für sein Unternehmen gewinnen kann. In Frankfurt bietet dafür die von Ellen Hermens und Sieglinde Fritz initiierte „Agile Game Night“ ein geeignetes Forum, das wir vom borisgloger-Team in Frankfurt unterstützen und mitorganisieren. Mit der Epic Bedtime Story haben wir im Juni diese Meetup-Reihe gestartet und damit ein Spiel erprobt, das die Vorteile eines gemeinsamen Teamraums verdeutlichen soll. Die dabei entstandene Geschichte von „Pachito, die kleine Zitrone“ war ein Erfolgserlebnis für die Teilnehmer und hat im Anschluss für angeregte Diskussionen und zahlreiche Erkenntnisse gesorgt. An Kreativität, Motivation und vor allem Spaß hat es dabei definitiv nicht gemangelt. Und für die Zukunft bleibt in Erinnerung: „Die Geschichte von Pachito hätten wir sicherlich besser abstimmen können, wenn die räumlichen Barrieren nicht gewesen wären.“

  3. Mut zum ersten Schritt im eigenen Unternehmen

    Bevor Spiele in einem Unternehmen zum ersten Mal eingesetzt werden, muss jemand den ersten Schritt wagen und sich vor Augen halten: „Keine Chance ohne Risiko.“ Bei guter Vorbereitung bleibt das Risiko gering. In jedem Fall gilt: Wir können und müssen mehr im Arbeitsalltag spielen, um nachhaltig miteinander zu kommunizieren, Ideen zu entwickeln und um mehr Spaß an der Arbeit zu haben.

Ich für meinen Teil wage diesen ersten Schritt bei meinen Kunden gerne und freue mich über Interessenten und Spielbegeisterte, die sich mit meinem Kollegen Christian Böhmer und mir bei der Agile Game Night in Frankfurt auf Experimente mit Lego, Buntstiften, Spielkarten, Knete etc. einlassen möchten. Daher mein Appell: Wagt den Schritt, kommt vorbei und macht mit!

Foto: CC0 Creative Commons – pixabay, PublicDomainPictures

"Ja, aber …" oder woran ich erkenne, dass ich agil bin

Wie bei jeder Reise, die wir unternehmen, wollen wir auch in Veränderungsprozessen wissen, ob wir Fortschritte machen. Wenn wir wissen, wie weit wir schon gekommen sind, können wir eine Prognose darüber anstellen, wie viel mehr Energie wir einsetzen müssen, bis wir unser Ziel erreicht, unsere Vision erfüllt haben. Gehen wir daran, agile Arbeitsmethoden, wie zum Beispiel Scrum, zu implementieren, ist die Einhaltung des Rahmenwerks ein konkreter Indikator dafür, wie vollständig, wie gut ich schon agil „mache“:

In der Praxis hat sich allerdings gezeigt, dass man nur vollständig agil „machen“ kann, wenn man auch agil ist, d.h. wenn das dahinterliegende Mindset, die Kultur im Unternehmen etabliert ist. Es gibt eine Wechselwirkung zwischen machen und sein. Nun lässt sich das agile Machen – wie oben beschrieben – recht einfach messen: Ich zähle einfach die Häkchen, die ich hinter die verschiedenen Elemente des Rahmenwerks machen kann. Falls ich nicht auf die volle Zahl Häkchen komme, lässt sich interessanterweise mutmaßen, dass es beim Mindset hapert. Anders ausgedrückt: Tatsächlich sind die Hard Facts ein Indikator dafür, ob es bei der Etablierung eines agilen Mindsets in eurem Unternehmen noch Verbesserungspotenzial gibt. Und wie beschrieben, lassen sich die Hard Facts recht leicht messen. Wer sich mit Objectives und Key Results auseinandergesetzt hat, weiß wahrscheinlich, dass Ergebnisziele und Fortschrittsziele zwei verschiedene Dinge sind. Auf unser Anliegen übertragen heißt das: Ich messe den Erfolg der Einführung agiler Methoden anhand der „Treue“ zum Scrum-Framework.

Ja, aber wie messe ich nun die Soft Facts?

Nur wie lässt sich messen, wie weit meine Bemühungen zur Etablierung des Mindsets gediehen sind? Wie messe ich meine Fortschritte auf dem Weg zum Ziel? Wie messe ich Kultur? Für den Start reicht es einmal genau zuzuhören. Zählt einmal, wie oft ihr „Ja, aber …“ in eurem Team und Unternehmen hört – und wie oft ihr selbst „Ja, aber …“ sagt. „Ja, aber“ heißt in Klardeutsch „Nein“. Alles, was hinter dem Aber kommt, negiert die erste Satzhälfte. lehnt damit die Position des anderen ab. Erst wenn ein Team in der Lage ist, verschiedene Standpunkte nebeneinander in der Schwebe zu halten, können dem Spannungsfeld der verschiedenen Sichtweisen neue und kreative Lösungen entspringen. Dann hat das Team dialogische Kompetenz entwickelt – eine wichtige Kulturtechnik für ein agiles Unternehmen. Im praktizierten Pluralismus liegt die Chance zur Schaffung eines neues Ganzen, das größer ist als die Summe seiner Teile.

Was könnt ihr für die Entwicklung dieser Kompetenzen tun? Was sind eure Fortschrittsziele?

In multifunktionalen Teams treffen häufiger Menschen mit unterschiedlichen Persönlichkeitstypen aufeinander als in Silo-Teams, deren Teammitglieder meist denselben Beruf gewählt haben. Analysen von Persönlichkeitstypen, wie beispielsweise disc oder der Myers-Briggs-Typenindikator helfen den Teammitgliedern zu verstehen, wie ihre Kollegen ticken. Das erhöht auch die Bereitschaft, Andersartigkeit zu tolerieren und den genannten Pluralismus zunehmend wertzuschätzen. Der ScrumMaster spielt in der Förderung dieser Entwicklung eine wichtige Rolle. Er erklärt den Teammitgliedern die Bedeutung von „ja, aber …“ und spiegelt ihnen, wie sich Kommunikation gestaltet, wenn es verwendet wird oder wenn es ausbleibt.

Scrum4Schools an der Hochschule München: Im Review und in der Retrospektive voneinander lernen

Die neuen Abläufe in Prof. Holger Günzels Kurs Agile Management for Entrepreneurs an der Hochschule München haben sich mittlerweile eingespielt. In diesem Semester erarbeiten seine Studierenden die Studienarbeit mit Scrum4Schools. In Woche 3 dieses Kurses hat die Gruppe beschlossen, das wöchentlich stattfindende Review anders zu gestallten. Als Hauptveränderung haben sich die Studierenden darauf verständigt, die Ergebnisse jeder abgeschlossenen User Story ausgedruckt mitzubringen. Ziel war es, den kommunikativeren Austausch in der Gesamtgruppe zu fördern und mehr Feedback einzuholen. Davor hatte das Review der einzelnen Gruppen eher den Charakter eines Vortrags.

Woche 4 – voneinander lernen

Das veränderte Review

In dieser Woche läuft das Review bedeutend reibungsloser und lebendiger ab. Die Studierenden haben pro abgeschlossener User Story maximal zwei Powerpoint Slides vorbereitet. Sie haben diese ausgedruckt mitgebracht und zu Beginn der Stunde an einer der Wände im Seminarraum befestigt. Das Review beginnt. Die gesamte Gruppe formiert sich halbkreisförmig um die Ergebnisse des ersten Studierendenteams. Die Aufgabe bestand darin, herauszufinden, wie man die agile Kultur in einem großen traditionellen Automobilkonzern aktivieren kann. Während der Kurzpräsentation der Wochenergebnisse notieren viele der restlichen Studierenden ihr Feedback auf Post-its. Nach der Präsentation entsteht schnell ein Gespräch über die Lieferung. Es gibt viel positives Feedback, aber auch Ideen, wie das Team die einzelnen Punkte noch präzisieren kann sowie Anregungen zu hilfreichen weiterführenden Materialien.
Die Zeit für das Feedback ist aufgrund der acht Studierendenteams begrenzt. Diejenigen, die nicht mehr zu Wort kommen, kleben ihre Feedback-Post-its einfach zu den präsentierten Slides. Prof. Günzel ist mit den Veränderungen zufrieden: „Die Studierenden haben sich gegenseitig deutlich mehr Fragen gestellt und Feedback gegeben. Und auch zeitlich lagen wir sehr gut. So hatten wir nach dem Review genug Zeit für die Retrospektive in den einzelnen Teams.” Das Feedback von den Studierenden ist ebenfalls positiv. „Im Nachgang an den Kurs haben mir einzelne Studierenden erzählt, dass sie die Vorzüge des gegenseitigen Lernens durch diese Form der Präsentation sehr zu schätzen wissen“, sagt Prof. Günzel.

“Die Studierenden haben sich gegenseitig deutlich mehr Fragen gestellt und Feedback gegeben.”

Wann ist etwas fertig?

Mittlerweile haben die Studierenden vier Wochen an Ihrem „Produkt“ gearbeitet. Ergebnis des Kurses soll neben der schriftlichen Studienarbeit, die im Nachgang an die letzte Seminarstunde vollständig abgeschlossen wird, eine managementtaugliche Präsentation sein. Darin sollen die Studierenden ihr jeweiliges Thema ausarbeiten und präsentabel genug für einen Management-Pitch darstellen. Die Qualität der Ergebnisse der einzelnen Studierendenteams geht laut Prof. Günzel stark auseinander: „Viele Teams haben bereits die richtigen Inhalte auf ihren Folien. Aber die Form ist noch nicht für den Kontext ‚Management’ geeignet. Das fängt bei der Gestaltung der Folie an, hat aber auch viel mit der sprachlichen Ausarbeitung und präzisen Darstellung der Punkte zu tun.“
Für Prof. Günzel sind die im Review präsentierten Folien von einigen Teams noch keine abgeschlossenen und fertigen Teillieferungen des Endprodukts. Genau darin liegt aber die große Stärke von Scrum: Kontinuierlich fertige und potentiell auslieferbare Teilergebnisse zu produzieren. Entwicklungsteams, die neu mit Scrum zu arbeiten beginnen, müssen das in den ersten Sprints zunächst einmal lernen. Genauso ist es bei den Studierendenteams. Dabei hilft es, dass einzelne Teams genau das schon tun und ziemlich gute Ergebnisse im Review präsentieren. Das hilft auch den anderen Gruppen. Sie können voneinander lernen und der Qualitätsanspruch der gesamten Gruppe steigt kontinuierlich in jeder Seminarstunde.

Scrum fördert den Austausch und motiviert

Scrum fördert den Austausch und motiviert „Und das ist toll zu sehen“, findet Prof. Günzel. „Die Studierenden arbeiten engagiert mit und lassen sich auf das Experiment ein.“ Die Anwesenheit ist freiwillig, denn an der Hochschule München gibt es seit einigen Jahren keine Anwesenheitspflicht mehr in den Kursen. „Besonders in Modulen mit der Prüfungsform Studienarbeit müssen sowohl das Veranstaltungskonzept als auch die einzelnen Veranstaltungen stimmen – ansonsten kann es auch schon mal passieren, dass von 30 Studierenden nur fünf an der Stunde teilnehmen.“ Das war jedoch in diesem Seminar noch nicht der Fall. Prof. Günzel führt es auf die Interaktion mit ihm und auf die wesentlich intensivere Interaktion zwischen den Studierenden zurück. Jeder bekommt in jeder Seminarstunde kontinuierliches Feedback aus mehreren Perspektiven und entwickelt damit Stück für Stück die eigene Studienarbeit. Das motiviert offensichtlich. Wir sind auf die Endergebnisse gespannt.

Scrum4Schools an der Hochschule München: Auch Professoren lernen immer wieder dazu

Es sind noch gute zehn Minuten bis zur nächsten Seminarstunde von Prof. Holger Günzels Kurs “Agile Management for Entrepreneurs”. Rund die Hälfte der Studierenden sitzt bereits in verschiedenen Ecken des großzügigen Hörsaals, der wegen der flexiblen Gestaltungsmöglichkeiten auch „Lehrraum der Zukunft“ genannt wird. Die Studierenden diskutieren angeregt und geben ihren Präsentationenden letzten Schliff für das gleich stattfindende Review der letzten Studienarbeitsiteration. Die Gruppe arbeitet in diesem Semester mit Scrum4Schools.

Woche 3 – Verbessern und optimieren

Arbeiten mit dem Taskboard – Transparenz entsteht

Mittlerweile befinden wir uns in der dritten Woche des wöchentlich stattfindenden Seminars. In der letzten Woche hat der erste Sprintwechsel, bestehend aus Review, Retrospektive und anschließendem Planning stattgefunden. Diesmal wirkt alles schon etwas eingespielter und die Präsentationen der inhaltlichen Konzepte der einzelnen Studierendenteams nehmen Gestalt an. Jedes Team hat im Review 10 Minuten Zeit, um seine aktuellen Ergebnisse zu präsentieren und Feedback einzuholen.
Die meisten Teams zeigen zum Start der Präsentation ihr Taskboard. Auf dem Taskboard ist auf einen Blick transparent, an welchen User Stories (=Teillieferungen des fertigen Produkts) das Team in der vergangenen Woche gearbeitet hat und welcher Studierende welchen Task (= Aufgabe) dabei übernommen hat. Um auch zwischen den Seminarstunden den Arbeitsfortschritt zu sehen, nutzen die meisten Gruppen ein digitales Board. Dazu bietet sich beispielsweise das frei verfügbare Programm Trello an.

Kontinuierliches Feedback statt Stress vor der Abgabe bringt bessere Ergebnisse

Die Studierenden aus den anderen Teams füllen während jeder Kurzpräsentation der verschiedenen Gruppen den im ersten Termin gemeinsam erstellten Feedbackbogen aus. Auch Prof. Günzel gibt nach jeder Kurzpräsentation eine Rückmeldung, worauf die jeweilige Gruppe sich noch stärker fokussieren kann – allerdings haben die meisten Teams die Aufgabenstellung richtig verstanden und arbeiten in die richtige Richtung. Bei manchen Teams gibt es mehr Feedback von Mitstudierenden und von Prof. Günzel. Sie sind bei der Bearbeitung der Aufgabenstellung nicht konkret genug geworden und müssen ihr Konzept nochmals überarbeiten. Prof. Günzel ist begeistert von dem Ansatz: „Normalerweise kommen die Studierenden – wenn überhaupt – wenige Tage vor der Abgabe zu mir, um sich Feedback für ihre Arbeiten einzuholen. Dann ist es meistens schon viel zu spät. Über die Arbeit mit Scrum gibt es kontinuierliches Feedback. Und das nicht nur von mir, sondern auch von anderen Studierenden.“

Verbesserung des Prozesses – wie ein effizienteres Review aussehen kann

Das Review und die anschließende Diskussion nach jedem Team haben länger gedauert als geplant. Wertvolle Zeit ging auch durch das Umstecken der Laptops zwischen den einzelnen Präsentationen verloren. Die Seminarstunde ist inzwischen fast zu Ende und Prof. Günzel bittet die Teams, die letzten fünf Minuten für eine kurze Retrospektive zu nutzen. Die Teams analysieren in der Retrospektive, wie sie ihre Zusammenarbeit in der kommenden Woche verbessern können. Er selbst reflektiert, was im Review passiert ist. Die Präsentationen, die die einzelnen Teams gezeigt haben, erinnerten ihn eher an klassische Seminarvorträge. Es gab viele PowerPoint-Folien und zum Teil waren die Folien auch noch nicht ganz fertig. Prof Günzel erinnert sich an das Ziel des Reviews: Das Einholen von Feedback zu abgeschlossenen Teilergebnissen.
Er hat eine Idee, wie er in der kommenden Woche das Review besser gestalten kann, und gibt seinen Studierenden drei Punkte mit:

  1. Im nächsten Review dürfen nur noch abgeschlossene User Stories vorgestellt werden.
  2. Pro User Story dürfen maximal zwei Folien erstellt werden, die die Studierenden ausgedruckt mitbringen und zu Beginn der Stunde an der Wand befestigen. Im Review geht dann die gesamte Seminargruppe von Teamwand zu Teamwand.
  3. Die Studierenden schreiben ihr Feedback zu den einzelnen Präsentationen auf Post-its und geben sie den einzelnen Gruppen mit.

Prof. Günzel erhofft sich dadurch einen reibungsloseren Ablauf des Reviews. Es geht ihm aber vielmehr darum, dass ein kommunikativerer Austausch in der Gruppe entsteht und die Studierenden sich gegenseitig mehr Feedback geben. Er ist gespannt, ob es funktionieren wird.
Die Erlebnisse von Prof. Günzel in seiner Reviewstunde zeigen, dass es kein Patentrezept dafür gibt, wie man Scrum4Schools am besten einführen sollte. Das Rahmenwerk muss immer auf den jeweiligen Kontext wie beispielsweise die Lernaufgabe und die zur Verfügung stehende Zeit angepasst werden. Dabei ist jeder gefragt. Und es braucht immer eine gewisse Zeit, bis eine Gruppe den optimalen Modus für sich gefunden hat. Grundvoraussetzung dafür ist die Bereitschaft, neue Dinge auszuprobieren und den eigenen Prozess kontinuierlich zu verbessern.

Scrum4Schools: Agile Studienarbeiten an der Hochschule München

„Warum müssen wir um Himmelswillen diese Tasks schreiben? Ich weiß doch, was ich machen muss.“ „So viel Overhead, wann haben wir mal Zeit zum Arbeiten?“ oder „Jede Woche liefern? Das ist zu wenig Zeit.“ Das sind beliebte Fragen von Entwicklungsteams, die sich mit dem Framework Scrum vertraut machen. Doch nicht nur in Unternehmen trifft man auf diese Bedenken, sondern auch in einer Wirtschaftsvorlesung von Prof. Holger Günzel an der Hochschule München. Er möchte nämlich mit seinen Studenten in den nächsten sechs Wochen Scrum4Schools als Experiment einführen und damit eine der Hausarbeiten erarbeiten lassen.

Woche 1 – Scrum kennenlernen

Die Aufgabenstellung

Prof. Günzel, in der Rolle des Product Owners, ist gut vorbereitet und hat sein Release-Ziel sauber formuliert. Jede Gruppe erhält eine eigene Aufgabenstellung, die in einen für Wirtschaftsstudenten relevanten Kontext eingebettet wurde. So sollen sie zum Beispiel laut Auftrag des Managements in einem großen Konzern Agilität einführen. Hierfür braucht es natürlich erst einmal eine Vision, Messkriterien für den Erfolg und die ersten Schritte, die getan werden müssen. All das soll in Form einer schriftlichen Arbeit erfolgen, damit das Management auch etwas in der Hand hat und zu einem späteren Zeitpunkt die Ergebnisse nachvollziehen kann. Die Constraints dieser Lieferung sind Zeit (6 Wochen), Organisationsvorgaben (Wir arbeiten in Dreier-Gruppen) und Arbeitsmethoden (Verwendung von Scrum und den damit verbundenen Artefakten). Als Akzeptanzkriterien finden sich die formalen Kriterien wie Zitier- und Quellenvorgaben, die Prof. Günzel an eine Studienarbeit stellt sowie das Verproben des Konzepts an mindestens drei Personen aus dem relevanten Kundenkreis. Inhaltliche Punkte, die er aus der Kundenperspektive mitgibt, verpackt er vorbildlich in User Stories. Hier finden sich Themen wieder wie Rollendefinitionen, Monitoringvarianten des Fortschritts, Pro- und Kontra-Argumente oder auch eine kleine Planung der nächsten Schritte.

Der Ablauf

Zu Beginn der Veranstaltung verteilt Prof. Günzel das Handout und Scrum-Checklisten von borisgloger consulting, die sehr gut an eine vorhergehende allgemeine Einführungsveranstaltung zu agilen Methoden anschließen. Wie in einem richtigen Sprint Planning erklärt er die Zielstellung und die einzelnen User Stories. Die Studenten haben im Anschluss die Möglichkeit, Verständlichkeitsfragen zu stellen und in die Verhandlung der Akzeptanzkriterien zu gehen. Nachdem Gruppen von je drei Studierenden gebildet sind, erarbeitet jede Gruppe eine eigene Definition of Done, in der sie ihre Qualitätskriterien beschreibt und ihre gemeinsame Arbeitsweise festlegt. Jede Gruppe soll auch die User Stories priorisieren und grob nach ihrer Größe schätzen. Für diesen Zweck verteilt Prof. Günzel Planning-Poker-Karten. Mit der daraus resultierenden Planung können nun die Taskboards mit den notwendigen Aufgaben pro User Story bestückt werden.

Und genau in dieser ersten Kennenlernphase sind Studenten eben auch nur Menschen, die eine neue Form der Zusammenarbeit und des Lieferns kennenlernen. Daher ist es nicht verwunderlich, dass sie exakt die gleichen Fragen stellen wie andere Scrum-Teams. Wir sind gespannt, wie die erste Iteration verläuft und berichten weiter.