Video: Der Scrum Flow

Es gibt unzählige Darstellungen und Erklärungen dazu, wie Scrum eigentlich funktioniert. Dieses kurze Video zeigt euch meine Darstellung. Würde mich freuen, wenn ihr sie für eure Zwecke nutzt. Zeigt sie Kollegen oder euren Chefs. Ich bin mir sicher, dass ihr damit in eurem Umfeld das Verständnis von Scrum verbessern könnt.
Viel Spaß beim Anschauen — Boris
 

Was ist so cool an Timeboxing?

In Scrum und Design-Thinking arbeiten wir eigentlich immer mit Timeboxing. Warum? Was ist so toll an Zeitbegrenzungen?
Wenn Sie einen alten Bekannten an der Bushaltestelle treffen und sagen: “Hey, mein Bus kommt in drei Minuten. Erzähl mir schnell, wie es Dir geht.” Dann können Sie sicher sein, dass er unter den vielen tausend Informationen automatisch die wenigen herauspickt, die er in diesem Moment für die wichtigsten hält. Sicher variieren die Informationen, je nachdem, wie Ihre Beziehung zueinander ist und wie er sich Ihnen gegenüber darstellen möchte. Aber in sekundenschnelle priorisiert Ihr alter Bekannter in der Gewissheit, dass Sie seine Informations-“Lieferung” bewerten werden. Und mit der Sicherheit, dass diese Situation für die nächsten drei Minuten stabil bleibt, dass Sie höflich zuhören und sich auf ihn einlassen werden.
Das machen wir uns auch in unserer täglichen Arbeit zunutze. In meiner Erlebniswelt gibt es drei Aspekte, warum ich Zeitbegrenzungen nicht mehr missen möchte:

  1. Lieferung
    Der wohl offensichtlichste Effekt ist, dass am Ende einer Timebox immer ein bewertbares Ergebnis steht. Am Ende eines Scrum-Sprints wird ein Produktinkrement geliefert. Am Ende einer Research Session steht Information bereit. Am Ende des Meetings stehen Entscheidungen oder ein Informationsaustausch. Und am Ende eines Brainstormings stehen viele Ideen. Die Zeitbegrenzung hilft dabei, die Arbeit zu planen, so dass die Arbeitspakete in die Timebox passen. Eine User Story muss so klein sein, dass sie innerhalb eines Sprints erledigt werden kann. Ein Prototyp muss so gestaltet sein, dass er innerhalb der Präsentations- oder Testzeit bewertet werden kann. Ein Teamtreffen bekommt eine Agenda, die in der bereit gestellten Zeit abgearbeitet werden kann. Das Schöne am Ende der Timebox ist, tatsächlich etwas geschafft zu haben. Und je kleiner die Timeboxen sind, desto häufiger kann man dieses schöne Gefühl genießen. Und sollte es am Ende einer Timebox einmal nicht die erwartete Lieferung geben, so ist auch das ein Ergebnis. Erinnern wir uns an das Sprichwort “lieber ein Ende mit Schrecken als ein Schrecken ohne Ende”. So wird auch aus diesem Ergebnis eine Chance. Die Chance, Dinge, die zu lange brauchen, zu beenden.
  2. Aufmerksamkeit und Fokus
    Mit der Zeitbegrenzung fokussieren wir uns ganz automatisch. Je kürzer die Timebox ist, je stärker der Zeitdruck im Nacken sitzt, desto eher lenken wir unsere Aufmerksamkeit auf die dringendsten Dinge. Stellen Sie sich eine Teenager-Party vor, die Eltern sind das ganze Wochenende verreist … Plötzlich: Es ist Samstag Abend, die Eltern rufen an. Sie kommen noch heute zurück und werden in einer Stunde zuhause sein! Was passiert im Kopf der Tochter / des Sohnes? Ein uraltes Überlebens-Programm springt an: Was dürfen die Eltern auf gar keinen Fall sehen? Und es wird sofort gehandelt! Zeitbegrenzungen lenken unsere Aufmerksamkeit und bringen uns ins Handeln. “Doing as a way of thinking” ist einer unserer Leitsätze bei Boris Gloger Consulting. Der wichtigste Schritt ist der erste! Je weniger Zeit wir haben, desto schneller müssen wir den ersten Schritt gehen.
  3. Stabilität
    Eine Timebox begrenzt in der Regel nicht nur einen Zeitrahmen. Wir legen für die begrenzte Zeit auch andere Rahmenbedingungen fest und schaffen eine stabile Umgebung. Dies ist einer der wichtigsten Aspekte, warum wir mit Scrum wieder Herr des Chaos werden können: In chaotischen und komplexen Umgebungen schaffen wir mit einem Sprint eine Blase der Stabilität. Für 2 Wochen sind die Anforderungen festgeschrieben, auch die benutze Technologie bleibt stabil. Rituale (Meetings) geben einen Rhythmus vor und damit die Sicherheit, dass die Grenzen morgen die gleichen sein werden wie heute. Es ist wie mit Kindern: Auch Kinder benötigen Grenzen, um Sicherheit, um Verlässlichkeit zu spüren, um den Rahmen zu füllen und sich geborgen zu entwickeln. In Scrum ist das der Rahmen, in dem Selbstorganisation wachsen kann. Mitarbeiter und Kollegen “wissen, woran sie sind”. Mit dem nächsten Sprint kann diese Blase der Stabilität natürlich neu positioniert werden, aber der verlässliche Rahmen bleibt immer. Gleiches gilt für kurze Timeboxen. In einer Ideation-Phase im Design-Thinking: Beispielsweise einigen wir uns für 20 Minuten darauf, dass wir die Aspekte der Machbarkeit oder Wirtschaftlichkeit nicht berücksichtigen. In diesem stabilen Rahmen können wir ernsthaft überlegen: “Wie würde Superman das Problem lösen?” oder “Wie funktioniert das auf Raumschiff Enterprise?”

Integration und Konsequenz

Mit großen Timeboxen könne Sie schnell Stabilität erzeugen und mit kurzen Timeboxen erhöhen Sie  schnell die Produktivität. Aber seien Sie vorsichtig: Es geht nicht darum, die Kollegen permanentem Stress auszusetzen. Vielmehr sollen sich Phasen hoher Konzentration und Phasen des Entspannens sinnvoll abwechseln. Achten Sie darauf, dass die Konzentrationsphasen maximal 90 Minuten lang sind und dann von einer Pause unterbrochen werden, die es erlaubt, die Aufmerksamkeit in eine ganz andere Richtung zu lenken.
Und noch ein letzter Hinweis: Zeitbegrenzungen müssen eingehalten werden, damit sie funktionieren! Das klingt einfacher als es ist. Wie Sie sich diese Aufgabe mit einem TimeTimer und einem Gong erleichtern können, lesen Sie in einem anderen Blogbeitrag.

Auch wenn's mal wieder länger dauert: Pull die wichtigsten Themen zuerst

Vor kurzem erläuterte ich den Umgang mit einem Product Backlog in einem skalierten Umfeld, das sich mitten in der Umstellung vom klassischem Projektvorgehen zur agilen Entwicklung befindet.
Das Product Backlog bezieht sich auf das Gesamtprodukt und ist auch dementsprechend priorisiert. Die Teams arbeiten somit an den Top-Prio-Einträgen des Backlogs und stellen diese fertig, bevor sie anfangen, neue Items zu bearbeiten. Dabei ist, und hier liegt die große Änderung zu vorher, die Anzahl der Items, die gleichzeitig bearbeitet werden “dürfen” begrenzt. So viel zur Theorie.
Jemand aus dem Teilnehmerkreis brachte dann den Einwand: “Wenn die Teams nur noch das nächste Item im Backlog bearbeiten “dürfen” hat das für mich aber nichts mehr mit PULL-Prinzip zu tun.”
Diese Äußerung machte mich im ersten Moment etwas verdutzt, da ich mich freute, dass wir nun endlich damit anfangen würden, dass sich jedes Team immer etwas von oben aus dem Backlog pullt.
Definiert man das PULL-Prinzip “inhaltlich” – also so, dass sich ein Team immer genau das aus dem gesamten Backlog zieht, was es am schnellsten, am liebsten oder am besten umsetzen kann, wenden wir uns tatsächlich davon ab. Denn es führt leider in der Regel genau zu dem altbekannten Anforderungsstau. Es gibt viele Anforderungen, die nur ein Team umsetzen kann, diese sind aber sehr wichtig für das Business. Andere Teams pullen sich diese für das Business wichtigen Items nicht, weil sie wissen, dass es ein anderes Team gibt, das mehr Skills in dem Bereich hat, es anstrengend ist, sich durch fremden Code zu wühlen oder weil die notwendige absichernde Testautomatisierung nicht vorhanden ist, die verhindern würde, dass etwas Schlimmes passiert.
Aus diesem Grund definiert man das PULL-Prinzip “zeitlich”. Das Team entscheidet, wann es so weit ist, sich ein nächstes Item zu ziehen – nicht aber unbedingt welches. Wohlwissend, dass man nicht immer gleich alle Skills für die Herausforderungen des nächsten Items zur Verfügung hat, gibt man den Teams die Zeit, die sie brauchen, um es fertig zu machen und im Gesamtprodukt zum Funktionieren zu bringen. Einer der Reize des Commitments ist genau das: nicht alles vorab zu können, aber es schaffen zu wollen und einen Weg ausfindig zu machen.
Damit will ich nicht sagen, dass es immer sinnvoll ist, dass alle Teams alles können und sich jedes Item ziehen müssen, das direkt an erster Stelle steht. Trotzdem plädiere ich dafür, an den für das Business aktuell wichtigsten Themen zu arbeiten – auch wenn’s mal etwas länger dauert.
Schnapp Dir nen Snickers und accept the challenge! Die ersten Male werden hart, aber das Durchbeißen lohnt sich.

Tun ist seliger denn nicht tun

In dem Unternehmen, in dem mein Freund arbeitet, wurde vor einiger Zeit ein internes Projekt gestartet. Es sollte ein Analysetool entwickelt werden, das die Firma bei Kunden einsetzen wollte. Und mein Freund – noch ganz frisch an seinem neuen Arbeitsplatz – sollte daran mitwirken! Völlig begeistert von dem Gedanken, versuchte er die wichtigsten Anforderungen in Use Cases bzw. User Stories zu formulieren und er hatte bereits angefangen, einen Prototypen zu bauen.
Doch kaum hatte er den Begriff “Scrum” in den Mund genommen, blockierte sein Chef. Man müsste das ganzheitlich denken, man könne doch nicht einfach anfangen, etwas zu entwickeln. Es sei eine Meta-Perspektive nötig. Man müsste erst einmal alles durchdenken und miteinander verknüpfen, bevor man die Entwicklung starten könne. Jetzt, wo man das alte Tool ablösen wollte, musste man es ja „richtig“ machen – nicht wieder einfach Stück für Stück etwas dazufrickeln.
Etwas zerknirscht ließ sich mein Freund also auf die Suche nach dieser geheimnisvollen Formel ein. Eine wirkliche Wahl hatte er nicht, denn einen Prototypen durfte er nicht entwickeln. Es ging nur schleppend voran. Alles lief in den Anforderungen, Ideen, aber auch Beschränkungen des Chefs zusammen. Diese änderten sich nicht nur permanent, sondern man entdeckte immer noch eine weitere Abzweigung oder Möglichkeit, die im Gesamtkonzept berücksichtigt werden wollte und damit das bisherige Konzept wieder in Frage stellte. Die Angst, etwas nicht komplett Ausgereiftes und zu 100% Fertiges zu liefern, gebar ein Meta-Konzept nach dem anderen. Den anderen Chefs der Firma wurde natürlich weiterhin kommuniziert, dass man an der Lösung arbeite. Sehen durften sie von alledem jedoch nichts.
Die marginal verfügbare Info nutzte einer der Chefs, um das neue Tool bereits fleißig zu verkaufen. Er tat es so hervorragend, dass er mit der alten Lösung nicht mehr alle Anfragen bearbeiten konnte. Vielleicht hätte er nicht fragen sollen, wann denn das neue Tool nun fertig sein würde bzw. ob er es denn nun endlich nutzen könne. Nichts war fertig. Bis auf die Konzepte.
Kurzerhand kaperte dieser Chef das Projekt – natürlich sollte der andere Chef nichts davon wissen. Die Anforderungen sprudelten nur so aus ihm heraus und unbedingt, unbedingt, unbedingt solle man jetzt diese „Scrum-Programmierung“ ausprobieren. Und obwohl mein Freund streng war, und in den nächsten zwei Tagen erst mal die Kernfunktionalitäten prototypisch umsetzte, verkürzte sich die Bearbeitungszeit für eine Analyse von ca. 5 Stunden auf 30 Minuten. Außerdem wurde bei der ersten Strukturierung der Daten deutlich, welche Neustrukturierung sinnvoll wäre bzw. welche Möglichkeiten der Meta-Analyse es gab. 😉
Als der Vertriebs-Chef nach 1,5 Jahren der Konzipierung und 2 Tagen Prototyping die ersten Ergebnisse sah, sagte er nur: „Das mit dieser Scrum-Programmierung ist toll! Da kommt man so schnell voran und sieht Ergebnisse.“ Das ganze Wochenende über spielte er mit dem Prototypen.
Noch so ein Nebeneffekt dieser Scrum-Programmierung: Nachdem mein Freund mir am Freitag Abend stolz sein Ergebnis präsentiert hatte, und ich ihm Feedback zu einer möglichen Visualisierung gegeben hatte, bekam ich ihn kaum vom Computer weg. Sein Meta-Konzept-Frust der letzten 1,5 Jahre schien vollkommen verflogen.
Natürlich musste ich beim Begriff „Scrum-Programmierung“ schmunzeln. Warum? Weil es mir mal wieder gezeigt hat, dass man nicht wissen muss, was Scrum ist, um zu verstehen, wofür Scrum gut ist.
Es geht nicht um Meetings, Rollen, Artefakte – es geht ums Tun, Ausprobieren und Liefern. 
Macht die Dinge angreifbar, baut etwas. Seid stolz auf das, was ihr gemacht, nicht was ihr gedacht habt. Seht das Gemachte als Gedankenanstoß – nicht als Endprodukt! Bindet andere ein und nehmt jegliche Art von Feedback als Kompliment. Ihr habt etwas gebaut und ermöglicht so, dass sich andere damit auseinandersetzen. Die Zeit, die sie dafür investieren, ist das beste Kompliment, das man bekommen kann.

Mut zur Wahrheit: Der erste Releaseplan

Nicht vieles ist so schön wie das Gefühl, einen Plan zu haben. Das gilt sowohl für das Privatleben – beispielsweise für den lang ersehnten Urlaub – als auch für den Beruf, speziell in der Projektwelt. Doch was passiert, wenn der sorgsam geschmiedete Plan nicht den Hauch einer Chance auf eine halbwegs vernünftige Umsetzung hat? Das Hotelzimmer liegt nicht wie angekündigt direkt am Meer, sondern man schaut in den dunklen Innenhof, wo Bauarbeiter seit 7 Uhr mit einem Presslufthammer den Boden rausreißen und außerdem ist dem jüngsten Spross speiübel, die Tauchausflüge sind also gestrichen.
Beim Lieblingsprojekt des Vorstandes verhält sich das nicht anders: Werdende Mütter und Väter, die den Großteil des Entwicklungs-Know-hows auf sich vereinen, nehmen Elternzeit, noch bevor sie es geschafft haben, wenigstens einen Teil ihres Wissens mit den Kollegen zu teilen. Der nächstbeste Mitarbeiter wurde von der alljährlichen Grippewelle ereilt und natürlich kommt auch noch ein gesetzliches Muss-Thema reingeflattert, womit die restlichen Reserven fast vollends aufgebraucht wären. Und, hat damit jemand gerechnet, als man das Projekt vor etwas mehr als einem Jahr auf „naja, sagen wir mal 2000 Personentage“ geschätzt hat? In den meisten Fällen leider nicht. Die Leidtragenden sind in solchen Fällen meist die Übriggebliebenen, die nun die gleiche Arbeit mit der Hälfte der Ressourcen erledigen müssen – der Termin steht ja schließlich schon seit einer halben Ewigkeit fest, Verzögerungen werden mit Argwohn quittiert.
Doch wie kann man hier Abhilfe schaffen? Ist das Projekt zeitlich bereits so weit fortgeschritten wie oben beschrieben, bleibt den Teams nicht sehr viel mehr, als mit den gesammelten Informationen für Transparenz bezüglich der tatsächlich leistbaren Arbeit herzustellen und entweder auf Verständnis zu hoffen, oder eben zusätzliche Ressourcen zur Verfügung gestellt zu bekommen.
Diese Transparenz lässt sich besonders einfach mit Hilfe eines Releaseplans realisieren. Hierbei werden sämtliche User Stories der vergangenen Monate nach Bearbeitungszeit sortiert (diese lassen sich in elektronischen Tools wie JIRA relativ einfach bestimmen). Am Ende erhält man sowohl die kürzeste, als auch die längste Durchlaufzeit für eine User Story und kann mit großer Wahrscheinlichkeit sagen, dass keine der noch offenen User Stories länger dauern wird, als die bisher auf „done“ gesetzten Stories. Da man außerdem eine durchschnittliche Velocity pro Sprint erhält, kann man nun auch eine Aussage darüber treffen, wie viele Sprints das Entwicklungsteam für die noch offenen und bereits geschätzten Stories noch benötigen wird.
Da hier in der Regel eine deutliche Diskrepanz zwischen Planung und Realität zu Tage tritt, hat ein solcher Releaseplan erfahrungsgemäß mindestens zwei Konsequenzen: Er sorgt für eine noch deutlichere Priorisierung der offenen Projekte und User Stories. Und zweitens tritt der ebenfalls erwünschte Effekt ein, dass die Scrum Teams nun häufiger und früher in die Planung einbezogen werden, um böse Überraschungen zukünftig zu vermeiden.
Der Releaseplan ist also ein einfaches und wirkungsvolles Tool, um auf der Basis bisher gesammelter Erfahrungen und tatsächlich gemessener Velocity relativ valide Aussagen darüber treffen zu können, auf welcher Stufe sich mein Produkt gerade befindet. Probieren Sie es aus!

Das Daily Scrum – ein How-To für das kürzeste Scrum Meeting

Als Management Consultant bekomme ich regelmäßig die Möglichkeit, die Scrum-Implementierung in den unterschiedlichsten Branchen und Unternehmen zu beobachten bzw. zu begleiten. Interessanterweise ähnelt in der Auslegung von Scrum kaum ein Unternehmen dem Nächsten – nicht einmal, wenn es um die Abhaltung der Scrum-Meetings geht. Selbst das kürzeste Meeting im Scrum Flow, das Daily Scrum, sieht stets anders aus. Vor allem bei Scrum-Neulingen habe ich die Erfahrung gemacht, dass ein gewisser, vorher gemeinsam mit dem Coach geübter Ablauf dem neuen ScrumMaster etwas Sicherheit bietet. Mein Vorschlag sieht meist so aus:

Zweck

Synchronisation innerhalb des Dev-Teams, um das Sprintziel und somit das Release zu schaffen.

Ziel

Als Team wissen wir, was erledigt werden muss, damit die committeten Stories auf Done gesetzt werden können.

Ablauf

  1. Das Dev-Team trifft sich im Halbkreis vor dem Taskboard. Der ScrumMaster steht seitlich ca. einen halben Schritt außerhalb dieses Halbkreises. Gäste stehen komplett außerhalb des Halbkreises.
  2. Begrüßung durch den ScrumMaster – ein “Guten Morgen” reicht aus. Hier ist ein motiviertes Auftreten wichtig: Wenn der ScrumMaster als Coach des Teams schon keinen Bock hat, wie soll das Team dann erst Lust bekommen? Der ScrumMaster startet mit einer Begrüßung und macht auf die geplanten Termine für den Tag aufmerksam.
  3. Falls jemand im Dev-Team noch keine Vorstellung hat, welche Arbeit er an diesem Tag leisten kann/ möchte/wird, sollte er sich gleich anfangs zu Wort melden, damit das restliche Team ihn für potenzielle Aufgaben in Erwägung ziehen kann.
  4. Nacheinander erzählt jedes Teammitglied seinen Kollegen Folgendes:
    1. Was habe ich seit dem letzten Daily umgesetzt? (falls fertig, wird der Task von Work In Progress in Done gehängt) Falls die Aufgabe wider Erwarten innerhalb des letzten Tages nicht fertiggestellt werden konnte, erklärt das Teammitglied kurz, wodurch die Aufgabe behindert wird. Dann wird ein Punkt auf das Post-It gemacht. Ggf. wird diese Störung am Impediment Backlog, auf dem Task bzw. an der Story visualisiert.
    2. Was werde ich heute tun? Hier zieht sich das Teammitglied eine Aufgabe aus der To Do Spalte der höchstpriorisierten User Story und hängt sie in Work In Progress. Falls möglich, plant das Teammitglied gleich Pair Programming mit einem Teamkollegen bzw. Unterstützung, die er in Anspruch nehmen möchte.
    3. Was behindert mich in meiner derzeitigen Arbeit? (Visualisierung nicht vergessen…)
    4. Wo benötige ich Hilfe?
    5. Meine heutige Verfügbarkeit
    6. Das nächste Teammitglied übernimmt und beantwortet dieselben Fragen gegenüber dem restlichen Team. Dies passiert reihum, bis das Team seine Arbeit synchronisiert hat und jeder weiß, was er heute mit wem bearbeiten soll.
    7. Ist eines der Teammitglieder nicht da, übernimmt ein anwesendes Teammitglied die Punkte des abwesenden Kollegen und hängt die jeweiligen Aufgaben auf dem Taskboard für ihn um.
  5. Der ScrumMaster fasst abschließend folgende Punkte zusammen:
    1. Neue Impediments, die in diesem Daily ans Tageslicht gekommen sind und um die er bzw. jemand im Team sich kümmern wird
    2. Inwieweit sind aktuelle Impediments schon gelöst bzw. ist dafür die Hilfe des Dev-Teams nötig?
    3. Neue Termine, falls ein detaillierter Abstimmungsbedarf zwischen Teammitgliedern sichtbar geworden ist
    4. Die eigene heutige Verfügbarkeit, ggf. einer Vertretung
    5. Falls der Product Owner anwesend ist: Spätestens jetzt noch fragen, ob er weitere  Anmerkungen hat
  6. Das Burn-Down Chart wird von einem Teammitglied aktualisiert.

Alles was man für dieses kurze Stand-Up benötigt, sind ein ScrumMaster, ein Dev-Team, ein Taskboard und ein Burn-Down Chart. Gäste, vor allem der PO, sind immer herzlich willkommen. Die Rahmenbedingungen von max. 15 Minuten, täglich, stehend, selber Ort, selbe Zeit dürfen deshalb aber nicht außer Acht gelassen werden.
Was haltet ihr von diesem kleinen “How-To”? Wie sieht der Ablauf des Daily Scrums bei euch aus?!

First things first

Ich gebe zu, man könnte es als luxuriös bezeichnen, eine komplette Woche mit einem neuen Team zu verbringen, bevor der tatsächliche Sprint startet. Mittlerweile betrachte ich es aber als notwendig, vor allem wenn das Team vorher nicht zusammen und nicht mit Scrum gearbeitet hat. Vor allem aber, wenn die Teammitglieder nicht daran gewöhnt sind, zu diskutieren und sich einzubringen.
 

Was man eine ganze Woche lang macht?

1) Scrum Basics vermitteln
Jeder hat über den Flurfunk oder die Unternehmenskommunikation im Rahmen der Einführung von Scrum bestimmte Buzzwords mitbekommen. Manche haben sich selbst eine Vorstellung gemacht, andere nachgelesen und wieder andere können mit den Begriffen nichts anfangen. Also, in Kürze – einen Tag – Rollen, Meetings, Artefakte. So legt man zumindest gleich zu Beginn die Grundlage für ein gemeinsames Verständnis – und eine gemeinsame Sprache verbindet zusätzlich.
 
2) Das Team kennenlernen
Ob ScrumMaster, Product Owner oder Teammitglied: Jeder ist neu im Team. Daher sollte man sich die Zeit nehmen, sich über die gewöhnliche Vorstellungsrunde mit Namen und Abteilungskürzel kennenzulernen. Ich bereite zwar eine Art Story Map vor, lasse dann aber die Teammitglieder durch Punkte entscheiden, was sie machen wollen, um sich, Scrum, die Hintergründe und den organisatorischen Rahmen kennenzulernen.
 
3) Vision und Backlog
Sich (als ScrumMaster) Zeit nehmen, den Product Owner gründlich auszufragen: Was ist das Produkt? Wer die Nutzer? Und welchen Nutzen wollen wir für sie bereitstellen? Kann man eine Vision erarbeiten oder fehlt es dafür an etwas?
 
Oft wundert man sich, dass es ein Team gibt und man vermeintlich starten kann, aber noch gar nicht richtig klar ist, was gemacht werden soll. Wenn man Glück hat, ist es für eine “strategische Runde” noch nicht zu spät, bevor die Verwirrung das ganze Team erfasst. Im besten Fall kann der PO nochmal drüber schlafen und nochmal weiterentwickeln, schärfen oder verwerfen, bevor er das Ergebnis zum ersten Mal mit dem Team diskutiert.
 
Vor allem einen nicht fertige Vision, ein mageres Backlog und die gemeinsame Erarbeitung der Personas mit dem Team laden zum Teilen der Meinungen ein. Durchstreichen erwünscht – und das ist “analog” einfacher als in einer ppt. Gemeinsam geschriebene User Stories, selbst wenn man nachher nicht alle braucht, machen deutlich, wie schwierig oft der Nutzenaspekt ist. Vor allem wenn man den Kunden bereits kennt und in der Regel einfach abarbeitet.
 
Gebt den Teammitgliedern etwas Zeit, wenn sie nicht gleich zu Beginn eifrig diskutieren. Oft sind sie es nicht gewöhnt, gefragt und gehört zu werden.
 
4) Infrastruktur und Wissen
Einen Raum beziehen, Rechner neu aufstellen, ein Taskboard bauen, weitere benötigte Infrastruktur- und Testumgebungen identifizieren, ggf. eine Schulung zu für das Team wichtigen Inhalten organisieren.
 
5) Definition of Done
Was ist selbstverständlich? Was wäre gut, wenn man es tun würde? Und was würden wir gerne tun, haben aber nicht die Mittel? Arbeitsweisen und Begriffsverwendungen variieren oft schon, wenn man die Seite des Flurs wechselt, ganz zu schweigen von Abteilungen. Das Sammeln der Antworten auf die Fragen oben ist für mich eine Herangehensweise, dem Team die Möglichkeiten und weniger die Doku-Regeln hinter der DoD zu vermitteln. Außerdem füllt sich das Impediment Backlog fast wie von selbst und das Team gibt bereits vor dem ersten Planning ein Commitment ab – und sei es nur um zu versuchen, die selbst gesteckten hohe Qualitätsziele zu erreichen.
 
First Things First – sich Zeit für die strategische Planung nehmen, bevor man in der Taktik der neuen Situation versinkt. Es lohnt sich und ist genauso ein Bestandteil von Scrum wie die Sprints.

Ein Tag in der Modellfabrik

Wer verstehen will, wie Produktionsabläufe in der Automobilindustrie funktionieren, kann in eine Vorlesung gehen. Er wird dann viel über Supply Chain Management, Logistik und Prozessoptimierung hören. Oder er kann die Produktion selber in die Hand nehmen. Achsen, Reifen und Führerstände darf er dann eigenhändig bestellen, zusammenbauen und ausliefern. Genau das passiert in der Modellfabrik der Hochschule Koblenz. Wir von bor!sgloger waren für einen Tag zu Besuch dort. Gastgeber war Ayelt Komus, Professor für Organisation und Wirtschaftsinformatik. Ayelt Komus ist nicht nur zertifizierter ScrumMaster, sondern auch Herausgeber der Studie zur Verbreitung und Nutzen agiler Methoden – die größte im deutschsprachigen Raum.
Unsere Mission: Ein Spiel zu entwickeln, das die Fertigungsstraße der Modellfabrik als Referenz nimmt, um agiles Arbeiten deutlich zu machen.

Probieren geht über Studieren!

Doch zuvor standen wir vor einer weit größeren Herausforderung: Die Fertigung eines Lasters  durchzuspielen, und so die Logik von strikter Arbeitsteilung, Push- und Pull-Prinzipien sowie Just-inTime-Lieferung am eigenen Leib zu erleben. Es dauerte nicht lange, da war das System schon mächtig unter Druck: Drei Fertigungsstände meldeten per Kanban-Signalkarten gleichzeitig Bedarf an Steckteilen und überforderten damit den Teilebeschaffer gnadenlos. Da hatten wir ihn: Den klassichen Bottleneck. Dass nach zehn Minuten die drei bestellten Laster im Wert mehrerer hunderttausend Euro dennoch ausgeliefert werden konnten, grenzt da schon fast an ein Wunder. Die Modellfabrik war vorerst vor dem Bankrott gerettet.
Aber zurück zur Mission. Wir hatten knappe sechs Stunden, um unser agiles Spiel vom Reißbrett auf zu entwerfen. Wir teilten uns initial in vier Gruppen auf. Der Vormittag bestand aus zwei Brainstorming-Sessions, an dessen Ende 16 Spielideen standen. Leicht entmutigt gingen wir in die Mittagspause: Wie sollte aus so vielen Ideen ein praktikables Konzept werden?
Dass wir am Ende doch noch die Kurve kriegten, verdanken wir einer Erkenntnis, die wir unseren Kunden gegenüber oft genug wiederholen: Probieren geht über Studieren! Als wir zur fortgeschrittenen Stunde dann endlich zum Spielen kamen und die Reaktionen von Teilnehmern und Beobachtern in Echtzeit sehen konnten, stieg das Vertrauen in das eigene Konzept sprunghaft an. Jetzt ging es noch um das Feintuning und die Optimierung.
Die drei Spiele, die es bis zum Schluss geschafft haben, könnten kaum verschiedener sein. Das eine Spiel heißt “Handicap” und setzt auf “blinde” und “einarmige” Teilnehmer, die nur über Kooperation einen Laster erfolgreich bauen können. Das zweite Spiel ist eine Abwandlung des Ball Point Games, in dem die Teilnehmer in Iterationen mit variabler Taktung und klarer Arbeitsteilung ausprobieren müssen, wie sie möglichst viele Laster zusammenschrauben. Das dritte Spiel schließlich setzt auf die Unterschiede zwischen Einzelgänger und Team: Lasse vier verschiedene Produkte von jeweils vier Personen alleine bauen – und mach dann das Gleiche in einem Team.
Zugegeben: Die Phase des friendly test haben unsere Spiele noch nicht überwunden. Aber Professor Komus hat seine Studenten – und wir haben unsere Scrum-Teams. Ihr dürft also auf den nächsten Beitrag gespannt sein, in dem wir Euch erzählen, wie die Spiele bei unseren ersten Probanden angekommen sind. Beim nächsten Besuch Anfang April bringen wir übrigens noch etwas mit: Wir geben dort ein ScrumMaster Advanced-Training, um den Studenten die Rolle des ScrumMasters näher zu bringen. Denn was heute noch gespielt wird, kann morgen schon berufliche Selbstverständlichkeit werden.

Warum Obama nur graue und blaue Anzüge trägt: Von Stabilität in Veränderungsprozessen

Wenn wir zu unseren Kunden gehen, dann immer mit der Absicht, etwas zu verändern. Wir implementieren Scrum, was einhergeht mit einer Veränderung der Rollen, Prozesse und Werte der Zusammenarbeit. Und wir möchten am liebsten, dass alle Mitarbeiter freudig aufspringen und rufen: „JA! Wir wollen uns verändern!“ Stattdessen jedoch sind viele Mitarbeiter erst einmal verhalten: „Ja, die agile Idee ist klasse und wir haben schon viel von Scrum gehört und gelesen, aber ich bin mal gespannt, wie ihr das hier machen wollt.“
 
Und dann starten wir mit ersten Trainings und damit, die ersten Teams auf Scrum umzustellen. Das bedeutet für die Mitarbeiter viel Veränderung: Die Teams werden neu gemischt, Mitarbeiter bekommen andere Rollen, wir implementieren Regelmeetings, alles wird transparent gemacht und wir sprechen plötzlich offen mit allen über Hindernisse in der Organisation. Uffz! So anstrengend haben sich die Mitarbeiter die Umstellung gar nicht vorgestellt. Plötzlich spürt man in den Teams den Gedanken: „Och, eigentlich war es doch immer ganz gemütlich hier. Können wir nicht wieder zurück?“ Dann bekommen die Consultants eine anstrengende Aufgabe, nämlich die angestoßene Veränderung konsequent weiter aufrecht zu erhalten. Die Veränderungen müssen im Verhalten der Mitarbeiter und den Prozessen im Unternehmen verankert werden.

Nicht zu früh abweichen!

Aber das Zurückrudern meinen die Mitarbeiter nicht böse – für diese Reaktion gibt es eine rein biologische Erklärung. Professor Gerhard Roth, Neurobiologe an der Universität Bremen sagt: „Für unser Gehirn gibt es kaum etwas schwierigeres, als Gewohnheiten abzulegen.“ Wir haben uns bereits an Verhaltensweisen gewöhnt und können sie automatisch anwenden. Das ist gut so, denn wir müssen selektieren, worüber wir uns Gedanken machen, sonst läuft unser Arbeitsspeicher im Gehirn voll.
 
Barack Obama trägt nur blaue und graue Anzüge. Warum? Er sagt: „Ich will mich nicht entscheiden, was ich anziehe oder esse, weil ich zu viele andere Entscheidungen treffen muss.“ Gewohnheiten und Routinen sind wichtig, um uns Luft zu verschaffen und sie geben uns Sicherheit. „Das Gehirn versucht unentwegt, so viele Handlungen wie möglich in Routinen zu verwandeln,“ sagt Professor Roth. Und daran arbeiten wir mit der Einführung unseres Scrum-Flows: eine neue Sicherheit und Routine herzustellen. Ja, ich weiß, das dauert ein paar Sprints, aber es funktioniert! Dazu müssen Mitarbeiter und Consultants großes Durchhaltevermögen beweisen und konsequent zusammenarbeiten.
 
Viele Teilnehmer in Trainings fragen mich: „Was ist der größte Fehler, den man bei der Einführung von Scrum machen kann?“ Und meine Antwort darauf ist: „Das zu frühe Abweichen vom Scrum-Flow und den Scrum-Grundlagen. Oder den vermeintlich nervenden Consultant zu früh nach Hause zu schicken.“ Mindestens die ersten drei Sprints sollten wirklich nach Lehrbuch umgesetzt werden. Da muss man sich durchbeißen, und konsequent sein. Das ist hart, aber danach wird der Scrum-Flow zur Routine und wir können uns stärker auf andere Dinge konzentrieren, wie z.B. Teamentwicklung oder Steigerung des Levels of Done. Jetzt beginnt also die Kür der Veränderung und damit der eigentlich spannende Teil. Daher lautet mein Rat zu Anfang: „Haltet durch! Land ist in Sicht“
 
Angelehnt an den Artikel “So besiegen Sie schlechte Gewohnheiten!” (Elke Hartmann-Wolff) im  Focus 02/13 vom 07.01.2013

Should internationally distributed Teams be avoided?

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 2)

 
The sequel to Does distance cancel out the efficiency of internationally distributed Teams?
Stephanie G.: Internationally dispersed Teams sound pretty exhausting. Are you telling me that you‘re no fans?
Hélène V.: I think that I can speak for everyone present that putting together internationally distributed or dispersed Teams – although dispersed is even worse – are not what we would advise managers to do. Yes, Scrum can be applied in such situations – but a lot of the fun and simplicity are taken out of the process. It is a challenge, which – of course – we are all willing to take on, but if a manager would ask me for my opinion, I would certainly advise the setting up of co-located Scrum Teams. (nodding all around)
Bernd K.: If I were a manager and I had to choose between training people on-site or investing in skilled staff abroad, I would certainly take the ones that are on-site.
Deborah W.: I second Bernd. But one has to admit that the wonderful thing about agile methods and Scrum is that they offer great practices, such as Pair Programming, for transferring and building up the skills of one‘s employees. However, this really depends on the product, the people, the necessary skills, as well as the available time and budget.
Kristina K.: Time‘s the word. If we‘re talking about a project where certain skills will only be necessary for a few months, it would probably be smarter to buy this kind of know-how. If we‘re talking about three years, then I would go for the more sustainable option of ensuring that the skills are available on-site.
Ina K.: In the case of three months, I would also aim at having the people with the necessary qualifications and competence flown in and sit together with the rest of the Team. After all, there will always be a small percentage of Team achievement that cannot be reached due to it being distributed.
Hélène V.: I second that. As a manager, it is important to figure out how to motivate the naturally distributed Team members to spend the necessary time together in one location. If one takes your case for example, Stephanie, one could have offered the German and Indian Team members a salary for 12 months and the challenge for the entire Team to complete the product within one year. The Team spends that time together in the third location Vietnam and if they finish the product earlier, then the 12-month salary is still paid, but the Team members can return home early. This is just an example – it’s up to the managers to think about ways to motivate their Team members to get together in one location and maximise their productivity.
Stephanie G.: I like that idea. But it again points to the general opinion that you would all strongly recommend to avoid creating distributed Teams?!
Christof B.: As Hélène has already said,  if we were given the choice as managers, we would try to keep the Team in one place. There are, however, a few scenarios that I could live with. Firstly, the ScrumMaster would have to sit with the Dev.Team. If the Product Owner is not able to do so, he will simply have to start travelling more frequently in order to build up a good relationship. He would furthermore have to offer a dedicated hour per day (at least), where he is strictly available to the Team for answering any questions and give information or feedback. The other important thing to watch out for when splitting a Team is that it should be equally divided. It is super difficult when there are six persons sitting on one end of the telephone receiver, and only one or two on the other.
 
Stephanie G.: Thank you. So to sum up your statements, we may advise managers to