Agiles Manifest: 12 Prinzipien für eine agile Verwaltung

Die vier Grundsätze des agilen Manifests lassen sich problemlos auch auf die öffentliche Verwaltung übertragen. Hinter diesen Grundsätzen stehen 12 Prinzipien, die diese Wertehaltung dezidiert ausformulieren (zum besseren Verständnis habe ich die Softwarebegrifflichkeiten entsprechend ersetzt):

  1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung unseres Produkts/unserer Dienstleistung zufrieden zu stellen.
    Im klassischen Projektmanagement bekommt der Kunde das fertige Produkt erst am Ende des Projekts präsentiert. Agile Methoden folgen einem anderen Ansatz: Hier werden kontinuierlich, d. h. in regelmäßigen Abständen, fertige Teilentwicklungen präsentiert. Bereits in der Entwicklungsphase werden so Rückmeldungen des Auftraggebers oder der Zielgruppe gewonnen, die wiederum in die Entwicklung einfließen. So sollen Missverständnisse minimiert, neue Erkenntnisse berücksichtigt und veränderte Rahmenbedingungen bereits im Entwicklungsprozess antizipiert werden. Der Entwicklungsprozess beginnt also ergebnisoffen. Stellen wir uns einen Stadtplanungsprozess vor, bei dem das jeweilige Zwischenergebnis in regelmäßigen Abständen in einem öffentlichen Rahmen vorgestellt wird. Die Projektentwickler holen sich in diesem Rahmen immer wieder die Rückmeldung des Gemeinderats und interessierter Bürger, die ihnen zurückspiegeln, ob sie – als Betroffene – Verbesserungsbedarf sehen. Auf diese Weise lassen sich frühzeitig konfliktträchtige Themenfelder identifizieren.
  2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
    Folglich sind Änderungen der Anforderungen jederzeit willkommen, sie werden nicht als lästig empfunden. Ganz im Gegenteil: Das Ziel ist es, unter den gegebenen Rahmenbedingungen möglichst das Beste zu schaffen, das zum aktuellen Zeitpunkt für den Kunden/Auftraggeber den maximalen Nutzen stiftet. Ein agiler Grundsatz lautet: Scheitere früh, scheitere schnell. Je früher wir erkennen, dass etwas nicht zielführend ist, desto früher können wir den Kurs neu bestimmen.
  3. Liefere funktionierende Produkte/Dienstleistungen regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
    Die Punkte 1. und 2. können nur funktionieren, wenn die Ergebnisse in regelmäßigen und möglichst kurzen Abständen präsentiert werden. Scrum sieht einen solchen Zyklus mit einer Gesamtlänge von maximal vier Wochen vor. Je kürzer desto besser. In jedem dieser Abschnitte wird ein voll „funktionsfähiger“ Teilaspekt präsentiert, getestet und begutachtet, der einen echten Nutzwert stiftet. Daraus lässt sich für die folgenden Schritte ableiten, ob und inwieweit Anpassungsbedarf besteht, um am Ende eine bessere Leistung zu liefern. Das Risiko, das „Falsche“ zu entwickeln, wird minimiert. Sie erinnern sich vielleicht an das Beispiel aus Punkt 1?
  4. Fachleute aus verschiedenen Bereichen müssen während des Projekts täglich zusammenarbeiten.
    Agile Teams sind interdisziplinäre Teams. Alle erforderlichen Funktionen, die zur Erstellung eines Produkts oder einer Dienstleistung erforderlich sind, sind Teil des Projektteams. Damit die Abstimmung im Team funktioniert, treffen sich die Teammitglieder täglich zu einer kurzen Abstimmungsrunde. Auf diese Weise wird sichergestellt, dass jeder vom jedem weiß, was dieser gerade macht und wo es eventuell Überschneidungen, Probleme oder Unterstützungsbedarf gibt. Das Team „synchronisiert“ sich selbst. In aller Regel reicht dafür eine Timebox von ca. 15 Minuten. Gerade bei den Problemstellungen, denen sich die öffentliche Verwaltung zu stellen hat, ist Interdisziplinarität extrem wichtig geworden. Statt Fachbereiche wie bisher in Silos abgekapselt Teilbereiche abarbeiten zu lassen, geht es darum, gemeinsam das große Ganze im Auge zu behalten. Mögliche Probleme werden in einer frühen Phase erkannt und können bearbeitet werden.
  5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
    Agile Methoden gehen davon aus, dass jeder von sich aus motiviert und deshalb in der Lage ist, nach bestem Wissen seine Fähigkeiten in das Team einzubringen. Alles, was es hierfür braucht, ist ein Umfeld, das den Rahmen bietet. Ein solches Team muss nicht an die Hand genommen werden. Es braucht nur eine klare „Produktvision“, einen klar umrissenen Auftrag. Das Team spricht von sich aus Probleme an und wird entsprechend an die Verwaltungsführung (Management) herantreten, das die Rahmenbedingungen schafft, die das Team zur Erfüllung seines Auftrags braucht. Im Gegenzug kann die Verwaltungsführung darauf vertrauen, dass das Team die Aufgaben meistert. Das Management wird entlastet und kann sich auf das konzentrieren, was seine eigentliche Aufgabe ist. An dieser Stelle noch der Verweis, dass die Verwaltung eben jene vertrauensvolle Zusammenarbeit im Bereich der Bürgerbeteiligung anstrebt. Werden entsprechende Werte nach innen gelebt, werden sie auch in der Außenwirkung selbstverständlich.
  6. Die effizienteste und effektivste Methode, Informationen an ein und innerhalb eines Teams zu übermitteln, ist das Gespräch von Angesicht zu Angesicht.
    Auch wenn es banal klingen mag: Die Kommunikation von Angesicht zu Angesicht ist nach wie vor der effektivste und effizienteste Weg. Agile Methoden legen daher einen besonders hohen Wert auf Kommunikation. Statt über Aktenvermerke im Umlauf und E-Mails langwierig zu kommunizieren, treffen sich agile Teams täglich. 15 Minuten reichen aus. Was ist seit gestern passiert, was ist für heute geplant und wo gibt es Herausforderungen sowie Bedarf für vertiefenden Informationsaustausch? So ist jeder im Team im Bilde. Gemeinsam wird am Ende der Woche geplant und eine in einer gemeinsamen Rückschau überlegt, was künftig verbessert werden kann. Informationen fließen schneller, das gemeinsame Verständnis wird verbessert.Durch die enge Kommunikation mit den Betroffenen – also auch mit dem Auftraggeber, Kunden, Beteiligten aus anderen Abteilungen – und durch regelmäßige Rückblicke auf einen bestimmten Zeitraum erschließen sich Informationsquellen, die Rückschlüsse über Verbesserungspotenziale, Anpassungsbedarfe und mögliche Herausforderungen liefern. Aber auch das gemeinsame Verständnis aller Beteiligten verbessert sich, weil alle Beteiligten die Hintergründe besser verstehen. Das Verhältnis Bürger zu Verwaltung oder Verwaltung zu Gemeinderat verbessert sich eklatant. Vergessen wir nicht, dass Verwaltung oft mit komplexer Rechtsmaterie befasst ist, die für Laien schwer verständlich ist.
  7. Funktionierende Dienstleistungen/Produkte sind das wichtigste Fortschrittsmaß.
    Hier geht es darum, möglichst einen Nutzen für den Auftraggeber bzw. für den Kunden zu schaffen. Dieser ist das Maß aller Dinge. Nicht die überkorrekt ausgefüllte Dokumentation, das exakte Reporting, der sauber dokumentierte Vorgang ist das Maß guter Projektarbeit, sondern einzig und allein das Ergebnis. Was haben wir von dem erreicht, was wir in diesem Planungszeitraum erreichen wollten? Wie oft wird gemessen, wie lange wer wofür braucht und wie oft etwas von a nach b geschafft wird – ohne jedoch drauf zu achten, was am Ende dabei herauskommt? Das Dokumentieren von Arbeitsschritten erscheint oft wichtiger als das erzielte Ergebnis. Diesem Ungleichgewicht stellt sich das 7. Prinzip entgegen. Dabei darf natürlich das Prinzip der Rechtmäßigkeit des Verwaltungshandelns nicht leiden. Aber die Erfüllung von Verwaltungsvorschriften als alleiniges Fortschrittsmaß allein wird dem öffentlichen Auftrag, den Verwaltung hat, nicht gerecht. Sie ist Dienstleisterin des Bürgers, autorisiert und finanziert vom Bürger.
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, das Team und die Nutzer der Dienstleistung sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
    Agilität vermeidet falsches Heldentum, im Sinne von „Verausgaben“ (Überstunden, 12-Stunden-Arbeitstage oder gar nachts durcharbeiten sind tabu). Sämtliche agile Methoden und Ansätze gehen davon aus, dass ein kontinuierlicher, gleichbleibender Rhythmus gesünder und produktiver ist und bessere Ergebnisse zeitigt als „Hauruckverfahren“, die dazu führen, dass die Beteiligten ausbrennen. Der regelmäßige Rhythmus gibt darüber hinaus die Möglichkeit, ein gewisses Maß an Verlässlichkeit zu schaffen und unnötigen Arbeitsdruck zu vermeiden. In diesem Sinne werden Arbeitsspitzen als Warnsignale verstanden, die darauf hindeuten, dass etwas nicht funktioniert. Einer der Vorteile gleichbleibender Arbeitsrhythmen ist die Erhöhung des Durchflusses: die Bearbeitungszeiten verkürzen sich. Ein echter Mehrwert für den Bürger, aber auch für den einzelnen Mitarbeiter, der Erfolg in Form abgeschlossener Vorgänge erleben darf, statt wachsender Aktenberge.
  9. Ständiges Augenmerk auf fachliche Exzellenz und gute Gestaltung der Arbeitsabläufe fördert Agilität.
    Damit das alles funktionieren kann, muss jedes Teammitglied über einen hohen Grad an sozialem und organisatorischem Können verfügen. Nur so erkennt das Team Handlungsmöglichkeiten sowie Herausforderungen und kann adäquate Lösungen erarbeiten. Die kontinuierliche Weiterentwicklung der Teamfähigkeiten, der internen Arbeitsabläufe und die permanente Weiterentwicklung der „Werkzeugkiste“ ist Voraussetzung für Agilität, da nur so auf Veränderungen reagiert werden kann. Fachliche Exzellenz ist für das Selbstverständnis einer öffentlichen Verwaltung Teil des Anspruchs. In der Realität zeigt sich, dass diese jedoch allzu oft durch die Fokussierung auf die Einhaltung von Formvorschriften zu wenig Beachtung erfährt. Wie oft bekommen junge, enthusiastische Mitarbeiter von den älteren Kollegen zu hören: „Haben wir schon immer so gemacht und es hat funktioniert. Es gibt also keinen Grund etwas zu ändern.“ Und dies, obwohl alle spüren, dass Veränderungen längst überfällig sind und sie Ballast, der irgendwann seine Daseinsberechtigung hatte, am effizienten und effektiven Arbeiten hindert.
  10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
    Es mag im ersten Moment kurios klingen, dass die Kunst darin besteht, die Menge nicht getaner Arbeit zu maximieren. Aber beim genaueren Überlegen wird klar, was damit gemeint ist: Es geht darum, Nutzen zu stiften und unnötige Arbeiten zu vermeiden, die keinen Nutzwert schaffen. Statt vieler unnötiger Zwischenschritte sollen Dinge möglichst einfach gemacht und „verschlankt“ werden, wenn es möglich ist. Sprich: Alles „über Bord“ werfen, was nicht zum gewünschten Ergebnis beiträgt. D. h. auch zu hinterfragen, ob das, was Verwaltung tut, tatsächlich zum Ergebnis beiträgt oder nur aus Tradition gemacht wird. In eine ähnliche Richtung geht auch das 12. Prinzip, auf das wir noch eingehen werden.
  11. Die besten Arbeitsrahmen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
    Agile Teams sind selbstorganisiert. Da sich das Team täglich mit dem gemeinsamen Thema auseinandersetzt, hat es auch die nötige Expertise, um Anforderungen, Entwürfe und Arbeitsrahmen so zu gestalten, dass am Ende ein für alle befriedigendes Ergebnis herauskommt. Das Team fixiert sich nicht auf Stellenbeschreibungen, sondern definiert sich über Rollen. Nehmen wir Scrum, eine der bekanntesten Methoden der agilen Produktentwicklung. Dort wird zwischen drei Rollen unterschieden. Mehr nicht. Es gibt einen sogenannten Scrum Master, der das Team begleitet, unterstützt und berät. Es gibt den Produkteigentümer, der innerhalb des Teams die Interessen des Auftraggebers vertritt und den Kontakt zum Auftraggeber sicherstellt, und es gibt das Entwicklerteam.Das Entwicklerteam setzt sich aus allen Funktionen zusammen, die zu Erfüllung der Aufgaben erforderlich sind. Alle verfügen im Idealfall über eine breite Grundkenntnis und jeweils Spezialkenntnisse, sodass jeder im Team andere Teammitglieder unterstützen kann. Gemeinsam mit dem ScrumMaster und dem Produkteigentümer bildet das Entwicklerteam ein Scrum-Team. Ein Beispiel: Bei einem Projekt zur Einführung der eAkte übernimmt der Sachgebietsleiter des Fachbereichs zentrale Dienste die Rolle des Produkteigentümers. Der Produkteigentümer ist nicht disziplinarischer Vorgesetzter des Teams. Dem Team gehören Vertreter der verschiedenen Fachbereiche an, die als Kommunikatoren in ihre Fachbereiche wirken sowie ein Vertreter des Personalrates. Die Rolle des Scrum Masters wird von einem erfahrenen Kollegen der EDV-Abteilung ausgefüllt, der bereits in scrumgeführten Projekten gearbeitet wird. Da die Stadt vier Fachebereiche hat, gehören damit sieben Personen dem Team an. Der Bürgermeister und die Fachbereichsleiter stehen in der Rolle des Managements. Die jeweiligen Kollegen, die später mit dem System der eAkte arbeiten, sind als Anwender die wichtigsten Feedbackgeber für das Team.
  12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und es passt sein Verhalten entsprechend an.
    Die kontinuierliche Verbesserung des Teams und seiner Zusammenarbeit ist von zentraler Bedeutung. Ein neues Team funktioniert nicht von Anfang an perfekt. Es muss sich finden. Es muss sich mit den sich verändernden Rahmenbedingungen entwickeln, wenn es sich einmal gefunden hat. Im Lean Management wurde der Begriff Kaizen, der ständigen Verbesserung, geprägt. Die Idee des Kaizen spiegelt sich im agilen Manifest wieder: Es gibt keine perfekte, sondern immer nur die im Augenblick beste Lösung. Zusammengefasst: Verbesserung heißt hier nicht, einfach nur Prozesse und Strukturen fortzuentwickeln, sondern im ganzheitlichen Sinne voranzuschreiten. Die Zusammenarbeit zwischen allen Beteiligten, die soziale Ebene miteinzubeziehen und als eine der wichtigsten Stellschrauben zu sehen.

Agilität und öffentliche Verwaltung schließen sich nicht aus, wie so mancher „Meinungsmacher“ postuliert. Im Gegenteil. Die agile Verwaltung, die sich an den agilen Werten und Grundsätzen ausrichtet, ist als öffentlicher Dienstleister nicht nur effektiv, sondern auch effizient im Meistern von Herausforderungen. Es mag gewagt klingen, aber für mich ist die agile Verwaltung eine Rückbesinnung, die Renaissance der Ursprungsidee, die ihren Ausdruck in der kommunalen Selbstverwaltung gefunden hat. Mithilfe der agilen Prinzipien, Werte und Vorgehensweisen können wir der Idee der bürgerorientierten Selbstverwaltung wieder mehr Lebendigkeit einhauchen.

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Als ScrumMaster werde ich in Unternehmen geholt, um zur Produktivitätssteigerung Scrum „einzuführen“. Relativ schnell begegne ich dabei folgendem Umstand: Viele Product Owner haben nicht im Blick, was ihr Team eigentlich genau liefern soll. Jedenfalls beantworten sie diese Frage selten aus Kundensicht. Meistens treffe ich auf Product Owner, die durch ihre lange Erfahrung und ihr umfangreiches Wissen zwar Experten für ihre Produktsparte geworden sind, aber ihr Blick hängt am eigenen Tun und Denken fest. Letzteres ist folglich zu wenig nach draußen gerichtet, in die Erlebniswelt des Kunden und des Nutzers. Für mich als ScrumMaster bedeutet das, den Product Owner und das Entwicklungsteam zu dieser Sicht- und Denkweise hinzuführen, was viel umfassendere Implikationen hat, als einfach mal eine neue Methode „einzuführen“. Genau genommen sprechen wir von der Entwicklung hin zu einer kundenorientierten Organisation, und das wirkt sich gleich auf mehreren Ebenen aus:
Ein wichtiger erster Schritt ist, eine agile Produktentwicklung zu etablieren. Das heißt im Idealfall, dem Scrum-Team beizubringen, wie man iterativ ein MVP (Minimum Viable Product) entwickelt und es dem Markt bzw. den Usern aussetzt – bis ein Produkt gefunden wird, das es sich in allen Details fertig zu bauen lohnt.
In diesem Prozess stellt man wiederum fest, wo es im Team an Skills mangelt, und in der Regel tut es das. Die nächste Aufgabe wäre also, diese Skills zu entwickeln. In der Softwareentwicklung hat sich für den Aufbau und den Austausch von Wissen das Mob bzw. Pair Programming etabliert, das Prinzip lässt sich aber auf andere Arbeitsbereiche anwenden. Fehlen bestimmte Skills zur Gänze, muss man sich diese zusätzliche Kompetenz ins Team holen.
Auf der Ebene der Infrastruktur stößt man schnell an Grenzen, die aufgelöst werden wollen: Hat das Team überhaupt geeignete Räume, in denen die Zusammenarbeit möglich ist? Sind Kommunikationsmittel im Einsatz, mit denen die Teamarbeit strukturell überhaupt abgebildet werden kann („Pull“-basierte Tools wie Slack oder Microsoft Teams können das), oder läuft die schriftliche Kommunikation des Teams hauptsächlich über E-Mail? Gibt es Arbeitsmaterialien wie Flipcharts, Whiteboards etc. erstens in ausreichender Menge und zweitens in guter Qualität?
Bleibt noch die Ebene der Architektur, auf die man einen Blick werfen sollte. Wie ist das Unternehmen organisiert und passt diese Organisationsstruktur überhaupt zu dem Produkt, das sich die Kunden und Anwender wünschen? Eng verbunden damit ist die Frage der Führungskultur in der Organisation: Sind Selbstorganisation, Freiwilligkeit und Commitment erlaubt und werden sie belohnt?
Was bedeutet das für die Arbeit als ScrumMaster oder Agile Coach? Ich muss einerseits die genannten Ebenen im Blick behalten und gleichzeitig meine Rolle mit Konsequenz leben. Das bedeutet, die agilen Werte und Prinzipien mit Bestimmtheit zu vertreten. Das bedeutet zum Beispiel, den nötigen langen Atem mitzubringen und dem Management so lange auf den Nerv zu gehen, bis die Lizenz für das geeignete Kommunikationstool gekauft wurde. Müsste ich das Handeln des ScrumMasters auf einen Aspekt reduzieren: immer wieder transparent machen, wo es hängt – auf allen Ebenen. Nur so komme ich überhaupt an die entscheidenden Punkte heran, die eine Organisation in ihrer Produktivität behindern.

ScrumMaster in Aktion: Das Feiern von Erfolgen

Es ist 9.00 Uhr. Wir haben uns vor dem Taskboard versammelt. Es ist alles noch ganz frisch, wir lernen noch, ein Hauch Unsicherheit liegt in der Luft. Der erste Kollege beginnt und hängt seine Tasks um. Die Kollegin folgt. Der erste Task wird auf „Done“ gesetzt. Die erste Aufgabe ist geschafft. Ich lade zum Feiern ein, strahle die Kollegin an. Ich empfinde die erste erledigte Aufgabe als große Genugtuung. Grund genug, um kurz innezuhalten und den Moment wirken zu lassen. Einziger Haken daran: um mich herum nur verdutzte Gesichter, die Kollegin ist verunsichert. Lob für eine solche „Kleinigkeit“ ist sie nicht gewohnt. Sie mache doch nur ihren Job. Auch der Product Owner ist verwirrt: Sollte das hier nicht selbstverständlich sein? Warum also ist der ScrumMaster so begeistert?
Ich merke schnell: Das Problem liegt tiefer. Lob und positive Rückmeldungen gehen hier allen schwer von den Lippen. Aus der Psychologie ist bekannt, dass Belohnung der positiven Verstärkung dient. Damit soll die Wahrscheinlichkeit erhöht werden, dass sich ein gewünschtes Verhalten wiederholt. Situationsgebundene Belohnung kann also durch Loben erfolgen. Dies sollte allerdings nicht zu freigiebig eingesetzt werden, da es sonst unverdient erscheint. Bewiesenermaßen wird das Belohnungssystem jedoch gezielt durch die Wertschätzung unserer Mitmenschen angesprochen – das steigert die Ausschüttung des Glückshormons Dopamin.

Den kleinen Dingen Aufmerksamkeit schenken

Meistens sind es ja die kleinen Dinge, die als selbstverständlich hingenommen werden, und es erscheint uns deshalb nicht nötig, diese wertzuschätzen. Es liegt uns fern, die kleinen Dinge zu sehen, die in Summe zum Gesamterfolg beitragen. Gerade im Prozess der Veränderung ist es jedoch sehr wichtig, diese kleinen positiven Fortschritte zu erkennen und hervorzuheben. Dopamin ist dafür verantwortlich, dass wir Erfahrungen als wohltuend empfinden, in Zukunft werden wir uns an dieses Gefühl erinnern können. So werden diese aktiv unterstützt und in Zukunft höchstwahrscheinlich wiederholt werden. Noch wichtiger als das Lob durch den ScrumMaster und den Product Owner ist das Lob untereinander. Kollegen, die sich gegenseitig zu ihren einzelnen Leistungen wertschätzend äußern, steigern die produktive Zusammenarbeit und den Zusammenhalt im Team.

Das Team mit Freiheiten belohnen

Das Team kann neben diesen kleinen Wertschätzungen auch durch Freiheiten belohnt werden. Vertrauen, das dem Team beispielsweise vom Product Owner entgegengebracht wird, ist eine wertschätzende Handlung, die dazu führen kann, dass das Team bemüht ist, beim nächsten Mal die Erwartungen des Product Owners zu übertreffen. Es wird dadurch selbstbewusster und beginnt, sich selbst mehr zuzutrauen. Damit ist die Grundlage für innovativere und kreativere Lösungen gelegt und das Team wächst noch mehr zusammen. Zugestandene Freiheit wirkt durch ihren wertschätzenden Charakter also ebenfalls als positive Verstärkung und steigert die Produktivität im Scrum-Team.

Gold Cards

Die gleiche Wirkung haben sogenannte Gold Cards, die der Product Owner an die Teammitglieder vergibt. Mit diesen Cards können Mitarbeiter innerhalb eines gewissen Zeitraums einen Teil ihrer Arbeitszeit in etwas investieren, das sie interessiert. Dies kann eine Fortbildung, persönliche Weiterbildung oder Zeit sein, um an eigenen Ideen zu arbeiten. Der Vorteil an dieser Variante ist, dass dem einzelnen Mitarbeiter gegenüber Interesse ausgedrückt wird, nicht nur an der Leistung des Teams.

Eine Release-Party schmeißen

Im skalierten Umfeld gibt es eine weitere mächtige Möglichkeit, das gesamte Team oder sogar mehrere Teams für ihre erbrachten Leistungen zu belohnen. Wie wäre es beispielsweise mit einer Release-Party? Die Teams haben durchgehalten, gekämpft und geliefert. Warum also nicht den Release gebührend mit allen Beteiligten feiern? So kann sogar das Angenehme mit dem Nützlichen verbunden werden: Die Teams können ihre Leistungen bei einer Präsentation von den Stakeholdern und dem gesamten Umfeld anerkennen lassen und anschließend kann sich das Team gebührend selbst feiern.
Zurück zum Geschehen: Ich wiederhole meine Aufforderung, den ersten Task auf „Done“ zu feiern. Peinlich berührt versucht sich die Kollegin aus dem Mittelpunkt zu stehlen. Wir haben noch einen langen Weg vor uns, aber ich werde nicht aufgeben, denn: Gerade am Anfang sind es die kleinen Erfolge, die aus einer Gruppe von Menschen ein Team machen.

Foto: CC0 Creative Commons – pixabay, pexels

Story Mapping – die Geschichte aus Sicht des Kunden

Es ist doch so: Eine Produktvision oder Produktidee zu konkretisieren und daraus User Storys zu entwickeln, ist nicht immer einfach. Ganz im Gegenteil: Es ist meistens sehr kompliziert. Allein schon die Frage nach dem Anfang und dem Ende ist schwierig. Man fängt an, seine eigenen Ideen und die des Teams zu sammeln und zu dokumentieren. Am Ende steht man mit einer langen Liste an Ideen da und schnell stellen sich ein paar Fragen:

Wenn man in dieser Situation steckt, hilft es, sich mit einer Story Map in den Kunden hineinzuversetzen und dessen Geschichte zu erzählen. Wie macht man das? Nun, wie bei jeder guten Story braucht es eine gewisse Struktur, die sich in Aktivitäten, Steps und Details unterteilen lässt. Ach ja, eine große leere Wand, Post-its und Stifte sind auch von Vorteil.
Zunächst werden die Aktivitäten auf einzelnen Post-its festgehalten. Aktivitäten sind große, meist in sich abgeschlossene Schritte, die der Kunde macht. Zum Beispiel: Informationen über ein Produkt einholen, Produkt auswählen, Warenkorb einsehen, Zahlungsoptionen auswählen oder Lieferoptionen auswählen.
Eine Stufe tiefer kommen die Steps. Diese helfen, die großen, groben Aktivitäten spezifischer zu machen. Hier wird aufgezählt, was der Kunde innerhalb einer Aktivität alles macht, um sie letztlich abzuschließen. Beispiele für die Steps innerhalb der Aktivität „Produkt auswählen“ können sein: einzelne Produkte ansehen, favorisiertes Produkt auswählen, Produktdetails ansehen, Produktdetails anpassen, Produkt in Warenkorb legen.
Die Details füllen die Steps mit Leben und werden am Schluss aufgeschrieben. Hier werden alle wilden, coolen aber auch essentiellen Ideen, die die Steps zu einem Erlebnis machen sollen, an die Wand geheftet. Diese Details können sowohl ganz spezifisch als auch grob und allgemein formuliert sein. Zum Beispiel: Warenkorb-Button, die Farbe anhand eines Tuschkastens auswählen, Anwendungsgebiete des Produkts anzeigen oder ein Produktteaser.

Story Map

Beispielaufbau einer Story Map
angelehnt an: Patton, Jeff und Economy, Peter (2015, 1. Aufl.): User Story Mapping – Die Technik für besseres Nutzerverständnis in der agilen Produktentwicklung)

Innerhalb der Schritte kann man ganz schnell feststellen, ob etwas vergessen wurde oder nicht. Wenn ja, dann werden die Post-its einfach umsortiert und neu angeordnet. Das Schöne ist: Es wird dabei jede Menge miteinander gesprochen und jeder erzählt seine Vorstellung der Kunden-Story. Ganz nebenbei wird so ein einheitliches Verständnis geschaffen. Das Tolle an Story Mapping ist, dass es entweder als einzelne Methodik innerhalb eines Prozesses zum Aufbau eines initialen Produkt Backlogs verwendet werden kann oder nachgelagert, als Resultat eines Design Thinking Workshops. In Kombination mit Design Thinking entsteht so gleichzeitig die Story inklusive Feedback des Kunden. Einen guten Einblick, wie ein Design-Thinking-Prozess aussieht gibt es hier.
Doch wie komme ich nun von der Story Map zu einem initialen Produkt Backlog mit Epics und User Storys? Das erzähle ich beim nächsten Mal.

Visualisierung: Behübschung oder Mehrwert für den Scrum Flow?

Überall dort, wo Menschen aufeinandertreffen, um miteinander Dinge zu erarbeiten, zu besprechen und zu planen, ist Visualisierung sinnvoll – zum Beispiel bei Meetings, Tagungen, Konferenzen, Seminaren, Trainings und Workshops. Obwohl es unzählige Möglichkeiten gibt, verstehen viele unter „Visualisierung“ noch immer nur PowerPoint-Präsentationen und vergeben sich damit die Chance auf einen nachhaltigen Eindruck. Was bleibt nach der x-ten PowerPoint-Präsentation in Erinnerung? Endlose Folienschlangen, dicht bepackt mit Zahlen, Daten und Fakten – kaum etwas davon bleibt erwiesenermaßen im Gedächtnis der Zuhörerschaft hängen.
Auch die Wissenschaft zeigt: Visuals schaffen es deutlich besser, die Zuhörer und Zuschauer zu binden. Laut einer Studie der Universität von Minnesota gemeinsam mit der 3M Corporation, die den Einfluss visueller Hilfen im Präsentationssetting untersuchte, kann das menschliche Gehirn Visualisierungen bis zu 60.000 mal schneller verarbeiten als reine Textinhalte. Da 90 Prozent der vom Gehirn absorbierten Informationen visueller Natur sind, können im Anschluss visualisierte Inhalte wesentlich besser abrufen werden.

Visualisierung

Beispiel einer unterstützenden Visualisierung zum Thema “Methodenevolution” während einer interaktiven Meetingform

Das ist ideal für den agilen Kontext, der von der Interaktion, der Freiwilligkeit und Bereitschaft im Team lebt, gemeinsam an Produktlieferungen zu arbeiten. Visualisierungstechniken schaffen es, die Menschen in Arbeitssitzungen und Lernumgebung stärker zu aktivieren. Als Visual Facilitator kann ich hier komplexe Inhalte und unterschiedliche Perspektiven sichtbar machen, dem Team Impulse für den Dialog geben, Gedanken strukturieren und schließlich wichtige Ergebnisse sichern. Neben den zahlreichen Vorzügen zeigen sich in der Unternehmenspraxis allerdings auch einige Herausforderungen, die man beachten sollte, wenn man die Vorzüge der Visualisierung im agilen Kontext nutzen will:

  1. Halten Sie eine lebendige Präsentation. Gehen Sie nicht mit vorgefertigten Flipcharts in eine Präsentation. Als Live-Zeichner sollten Sie die Darstellung im Laufe der Präsentation entwickeln, um die Zuhörer abzuholen, den Erinnerungswert zu steigern und Publikumsfeedback direkt einfließen lassen zu können. Der Zuhörer und Betrachter wird dadurch zweifach kognitiv stimuliert – der Erinnerungswert steigt.
  2. Vermeiden Sie die Ornamentierung von Scrum. Auch wenn Prozess, Inhalte und Ergebnisse in visueller Sprache, d.h. in Kombinationen von Text, Bild und Containern gut sichtbar gemacht werden können, schlägt im Zweifel der Inhalt die Form. Konzentrieren Sie sich auf die Präsentation und nutzen Sie Visualisierungshilfen nur zur Unterstützung Ihrer Kernaussagen.
  3. Lassen Sie sich als ScrumMaster nicht auf die Rolle des Facilitators reduzieren – ein mit bunten Visuals geschmückter Scrum-Meeting-Raum ist keine Garantie für einen funktionierenden Change Prozess. Dem Team und den Stakeholdern hilft die Transparenz, die durch Visualisierungen in Meetings, von Artefakten und auf Boards entsteht. Übernehmen Sie aber nicht alle zeichnerischen Leistungen, sonst werden Sie schnell auf die Rolle des Visual Facilitators reduziert – als ScrumMaster haben Sie noch wesentlich wichtigere Aufgaben!

Nicht nur, aber besonders im agilen Umfeld bieten ausdrucksstarke Visualisierungen die Möglichkeit, den Wert und die Wichtigkeit von Aussagen zu unterstreichen und klarer zu machen. Vom Teammeeting bis zur Großgruppenveranstaltung mit mehreren Hundert Teilnehmern haben Sie ein kraftvolles Tool in der Hand, wenn Sie die damit verbundenen Herausforderungen ernst nehmen.

Foto: CC0 Creative Commons – pixabay, AlexanderStein

Agiles Demand Management im skalierten Umfeld

Klassische Unternehmensbereiche und Scrum treffen oft aufeinander. Fast immer stellt sich dabei auch folgende Frage: Wie kann beides auf einen Nenner gebracht werden? Diese Frage stellt sich auch beim Anforderungsmanagement. Denn im grundlegenden Konzept von Scrum gibt es lediglich die Rollen Product Owner, ScrumMaster und Entwicklungsteam – Boris Gloger hat das Konzept um die Rollen Kunde, Management und Nutzer erweitert. Das klassische Demand Management wie in Großkonzernen, bei dem interne Anforderungen bewertet und gesteuert werden, findet sich in keiner der Rollen direkt wieder.
Der täglichen Arbeit des Anforderungsmanagements kommt die Rolle des Kunden noch am nächsten. Er liefert dem Product Owner jene Impulse, die er in eine Vision bündelt, um dem Entwicklungsteam die richtige Orientierung zu geben. Nun werden in einem Großkonzern auf eine entwickelnde Abteilung jedes Jahr hunderte Anforderungen aus allen Teilen des Unternehmens eingesteuert. Hier reicht die Rolle des methodisch sauber aufgesetzten Kunden nicht mehr aus, um die Anforderung zu handhaben.

Eine Lösung: das Demand Management Team

Doch für diese Problematik im skalierten Umfeld ist die Lösung leichter als gedacht. Bei einer größeren Anzahl von Scrum-Teams wird zwischen Kunde und Chief Product Owner (CPO) ein vorgelagertes Scrum-Team aufgesetzt: das Demand Management Team. Es arbeitet in regulären Sprints und übergibt im Refinement dem CPO die evaluierten und spezifizierten Anforderungen. Bei diesem Refinement können bzw. sollten neben dem CPO und dem Demand Management durchaus auch andere Experten anwesend sein. Schließlich kann ab einem bestimmten Komplexitätsgrad eine einzelne Person nicht die fachliche Tiefe mitbringen, um für Großprojekte alle Anforderungen adäquat zu priorisieren und den Return on Investment bewerten zu können.
Nach dem Overall Refinement werden die Anforderungen in den Sprintzyklen der skaliert zusammenarbeitenden Scrum-Teams bearbeitet. Am Ende des Sprints tritt das Demand Management wieder auf den Plan, um den Kunden und seine zu Beginn des Sprints eingesteuerten Anforderungen im “Overall Review” zu vertreten. Hier hat das Demand Management auch die Möglichkeit, Änderungen des Kunden zu kommunizieren. Sollte es der Kunde einfordern, ist das Demand Management in der Rolle des Transmitters nach diesem Termin auch aussagekräftig zu Zwischenständen und Teillieferungen. In der darauf folgenden “Overall Retro“ wird neben den projektübergreifenden Learnings auch der Rahmen aufgespannt, um die Zusammenarbeit zwischen Demand Management und CPO zu evaluieren und langfristig zu verbessern.
In der Praxis funktioniert diese Lösung sehr gut, dennoch sollten einige Voraussetzungen erfüllt sein, um den Übergang in die Agilität zu vereinfachen. Im ersten Schritt sollten die betroffenen Personen zu einem frühzeitigen Zeitpunkt inhaltlich und methodisch auf den gleichen Wissensstand gesetzt werden, sodass alle Beteiligten die gleiche Vorstellung von Begrifflichkeiten oder Artefakten haben. Sind Methode und Inhalte, sowie deren Anwendung klar, kann im finalen Schritt die Integration eines eigenen Scrum-Teams “Demand Management” angestrebt werden.

Foto: CC0 Creative Commons, pixabay – ulrichw

Social Impact Lab 2.0 – Lean im Startup

Das Social Impact Lab in Stuttgart ermöglicht sozialen Startups im Gründungsprozess, über mehrere Monate hinweg aus ihren Ideen ein tragfähiges Geschäftsmodell zu entwickeln. Ganz unter dem Motto “have a social impact” konnten wir – Michael Friedmann und Marcel Rößner – den Gründerinnen und Gründern im Rahmen eines Workshops einen Einblick in agile Arbeitstechniken geben. Im Speziellen zum Thema “Lean Startup”.
Die teilnehmenden Startups des Social Impact Labs durchlaufen das achtmonatige Stipendium #Wirkungsschaffer, das Workshops und Coachings in den verschiedensten Bereichen beinhaltet. Als Berater für agile Produktentwicklung hatten wir daher die Zielsetzung, den Teilnehmerinnen und Teilnehmern in einem eintägigen Workshop einen guten Überblick über agile Methoden zu geben und ihnen möglichst leicht anwendbare Konzepte mitzugeben, die sie einfach umsetzen können. Denn auch soziale Startups brauchen ein hieb- und stichfestes Geschäftsmodell, um langfristig nicht von Spenden und Fördergeldern abhängig zu sein. Da sich die Startups im Social Impact Lab teilweise in einer frühen Gründungsphase befinden, konnten wir ihnen vor allem mit dem Thema Lean Startup einen neuen Denkrahmen mit auf den Weg geben.

Was ist (ein) Lean Startup?

Lean Startup ist eine Methode, bei der schnell und mit möglichst wenig Aufwand geprüft wird, ob für eine Idee ein Markt existiert oder nicht. Um eine Idee testen zu können, muss erst ein Produkt gebaut werden, das diese Idee verkörpert. Mit herkömmlichen Methoden und Vorgehensweisen kann dieser Prozess auch ein paar Jahre dauern. Der Trick bei Lean Startup: Es kommt nicht darauf an, dass das Produkt in allen Einzelheiten funktionsfähig auf dem Markt erscheint. Wichtig ist zunächst die Funktionalität, von der vermutet wird, dass sie dem Kunden Nutzen bringen wird und damit sein Problem löst. Dabei sprechen wir vom Minimum Viable Product (MVP). Es ist das Mindeste, was benötigt wird, um prüfen zu können, ob das Produkt gekauft wird oder nicht. Welche verschiedenen Strategien und Typen eines MVPs existieren, könnt ihr in diesem Blogbeitrag nachlesen:

Am Anfang steht die Hypothese

Ein Startup beginnt immer mit einer Hypothese, die es zu überprüfen gilt. Der Zyklus, in dem eine solche Hypothese überprüft wird, nennt sich „Build-Measure-Learn-Zyklus“. Zunächst wird auf Basis der Hypothese ein MVP gebaut, mit dem die aufgestellte Hypothese überprüft und gemessen werden kann. Basierend auf diesem Feedback und den gemessenen Daten gilt es nun zu lernen: Das Produkt bzw. die Idee wird anhand der Ergebnisse gepasst und eine neue Iteration des Prozesses wird durchlaufen. Die reale Hypothese eines früheren Startups lautete beispielsweise:

Menschen kaufen Schuhe online = Profit

Mit dieser Hypothese ist der heutige Schuhgigant Zappos, damals noch als kleines Startup, 1999 in den Onlinehandel eingestiegen. Was Zappos anfangs benötigte, war keine ausgefeilte Online-Plattform, sondern eine rudimentäre Website mit Bildern von Schuhen und einer einfachen Kauffunktion. Über diese Website konnten Schuhe ausgewählt und schließlich gekauft werden. Die Fotos der Schuhe hatten die Gründer einfach in einem nahegelegenen Schuhladen aufgenommen. Wurde nun ein Schuh online von einem Kunden bestellt, mussten die Zappos-Gründer wieder in das Schuhgeschäft laufen, die Schuhe dort kaufen, anschließend händisch verpacken und an den Käufer versenden. Ziemlich umständlich, oder? Als langfristiges Geschäftsmodell wäre das sicher nicht tragbar. Aber was Zappos mit dem MVP bewiesen hatte, war, dass Menschen – genauer gesagt potentielle Schuhkäufer*innen – tatsächlich bereit waren, online Schuhe zu kaufen. 
Da die anfängliche Hypothese damit bestätigt worden war, war es erst jetzt sinnvoll, eine echte Onlinehandelsplattform mit einfacheren, digitalen Prozessen nach und nach zu entwickeln.
Mit simplen Mitteln wie Google Adwords konnte zusätzlich gemessen werden, wer die wirkliche Käufergruppe war, um das Sortiment von Zappos stetig darauf auszurichten und das richtige Kundensegment anzusprechen. Wurde ein Schuh nie angeklickt, konnte er schnell wieder aus dem Sortiment genommen werden. Produkte, die bei den Kunden Anklang fanden, konnten identifiziert und das Sortiment in diesem Bereich ausgebaut werden.

Und wenn sich die Hypothese nicht bestätigt?

Doch was wäre gewesen, wenn sich die Hypothese nicht bestätigt hätte? Auch für diesen Fall liefert das Lean-Startup-Konzept eine Antwort: den sogenannten Pivot, zu deutsch Richtungswechsel. Wird eine fundamentale Hypothese der Idee oder des Geschäftsmodells widerlegt, so MUSS ein Richtungswechsel erfolgen, da das Startup sonst am Nutzer vorbeientwickelt und keinen Wert liefert. Das Startup ist somit nicht gescheitert, sondern führt rechtzeitig einen Richtungswechsel hin zu einer neuen Hypothese durch.
Im Social Impact Lab konnten wir mit den Teilnehmern im Rahmen unseres Workshops einen fundamentalen ersten Schritt im Sinne des Lean Startups gehen. Nachdem wird das theoretische Konzept vorgestellt hatten, baten wir die Teilnehmer, die Hypothese ihrer Geschäftsidee zu formulieren, um sie im Nachhinein im Plenum zu diskutieren.
Nach der Vorstellung konnten wir genauer auf die Besonderheiten der Hypothesen eingehen und prüfen, was getan werden könnte, um diese möglichst schnell auf dem Markt zu validieren. Das konstruktive Feedback und gemeinsame Hinterfragen unter den Teilnehmern brachte weitere Ideen hervor.
Übrigens: Der Lean-Startup-Ansatz ist nicht nur für Startups geeignet, sondern grundsätzlich für jede Produktentwicklung. Auch in bereits etablierten Unternehmen sollten Ideen bzw. Hypothesen möglichst schnell geprüft werden, um radikal nutzerzentriert zu entwickeln und Wert zu generieren. Probieren wir es doch gemeinsam aus!

Foto: Copyright Marcel Rößner

3 Argumente gegen User Stories und wie ihr ihnen begegnen könnt

In unseren Trainings oder in der Arbeit mit Teams begegnen wir einer Vielfalt von Gründen, warum eine bestimmte agile Praktik in diesem Team nicht angewendet werden kann. Dabei sind die Begründungen nur auf den ersten Blick spezifisch für das jeweilige Team und vor allem sind es in den seltensten Fällen tatsächlich sachliche Gründe, warum etwas nicht geht. Menschen stehen Veränderungen prinzipiell erst einmal kritisch gegenüber. Deshalb werden neue agile Praktiken nicht einfach ausprobiert, sondern meist erst einmal gründlich geprüft.
Daran ist prinzipiell nichts Falsches – unser Gehirn spart viel Energie, wenn es gelernte Praktiken abspielt und nicht immer Neues ausprobiert. Gleichzeitig kann es ganz schön frustrierend sein, wenn man einem Team etwas zeigen möchte und nur Widerstand erntet. Manchmal verbirgt sich hinter der vorgeschobenen rationalen Begründung auch ein Gefühl der Unsicherheit. Ehrlich wäre es, einfach zu sagen: „Ich will es nicht machen! Den alten Prozess kenne ich, der neue macht mir Angst, weil ich noch nicht weiß, was genau passiert.“ Im beruflichen Kontext sind aber wenige so reflektiert und ehrlich und deshalb lohnt es sich, sich als Scrum Master oder Agile Coach schon einmal auf die typischen Widerstände einzustellen, die einem bei der Einführung eines neuen Meetings, Artefakts oder einfach nur einer kleinen Prozessänderung begegnen werden.
In den nächsten Wochen wollen wir euch einige jener Argumente nennen, die uns immer wieder begegnen, damit ihr dagegen gewappnet seid und euren Teams helfen könnt, sich auf das Abenteuer des Ausprobierens einzulassen. Im ersten Teil widmen wir uns dem Thema User Stories.

„So ein simpler Satz ist mir viel zu wenig!“

Ganz klar, die User Story in ihrer klassischen Syntax ist einfach – und das soll sie auch sein! Eine gute User Story ist nämlich nichts anderes als eine „Einladung zur nachgelagerten Konversation“. Das bedeutet: In ihrer offenen Formulierung ist sie dazu gedacht, dass der Product Owner mit dem Team über die User Story spricht, sie auf den Prüfstand stellt und dadurch die Details immer klarer werden – bis die Story „ready for sprint“ ist.

„Aber eine User Story kann doch nicht mindestens zwei Mal im Refinement gewesen sein!“

Gerade weil User Stories anhand der INVEST-Kriterien formuliert werden, sollen sie unter anderem verhandelbar und klein sein. Das bedeutet, dass es viele Gespräche und einige Durchläufe braucht, um mehr Klarheit über die Anforderung zu bekommen, die sich in der User Story versteckt. Je vager die Formulierung und je näher die User Story noch an ihrer Ideenphase ist, desto klarer wird, dass es mehr Details braucht, bis alle Teammitglieder das gleiche Verständnis über den Inhalt der User Story haben. Das Backlog Refinement ist dafür der geeignete Termin. Sprecht als Team über den Inhalt, verschafft euch Klarheit und ergänzt, was das Zeug hält: Akzeptanzkriterien, Testfälle, Abhängigkeiten, Risiken und alle Details, die euch einfallen. User Stories werden dann auch oft kleiner geschnitten, wenn sie sich für einen Sprint als zu groß herausstellen.

„User Stories, okay, aber Personas? Brauch ich wirklich nicht!“

Simon Sinek sagt immer wieder, dass das „Why“, also das Warum, das einen antreibt, klar sein muss. Daher sollte die dahinterliegende Antwort etwas elaborierter sein als ein lapidares „Isso“. Auch wenn dem Team der Mehrwert klar ist, ist es unglaublich hilfreich, sich die Anforderungen mit der Brille bestimmter Zielgruppen anzusehen: Warum tickt meine Zielgruppe so wie sie tickt? Und was bedeutet das für mein Produkt? Gibt es widersprüchliche Anforderungen meiner User-Gruppen? Worauf will ich als Product Owner mein Augenmerk legen und für wen priorisiere ich? Personas helfen dabei, sich als Team in die jeweilige Zielgruppe hineinzuversetzen. Je mehr Daten und Fakten in die Persona fließen, desto besser – und dennoch: Entwerft eure Personas so, als wären sie reale Wesen mit Charakter, Lebenslauf, Vorlieben und gebt eurem Produkt damit so viel Kontext, dass ihr euch der Frage nach dem „Why“ leichter nähern könnt.
Sind euch in eurer Arbeit noch andere Argumente gegen User Stories begegnet? Lasst uns wissen, wie ihr darauf reagiert.

Dieser Beitrag ist im Pair Writing mit Sandra Wittmann entstanden.
Foto: CC0 Creative Commons, pixabay – aitoff

Scrum Meetings – Retrospective

The final meeting within the Scrum framework is called the Retrospective. The key is to review the last iteration and determine how we can improve during the next one as a team.  
Are you curious to find out how to do a Retrospective efficiently? Watch my how-to video to find out! 

7 Erfolgsfaktoren der Digitalisierung- Rahmenbedingungen

Ob eine Digitalisierungsinitiative erfolgreich verläuft oder nicht, hängt zunächst von den Rahmenbedingungen ab: von den organisatorischen und und von jenen der Infrastruktur. Dabei geht es gar nicht darum, am Arbeitsplatz eine Fun-Park-Atmosphäre zu schaffen. In erster Linie ist es wichtig, dass sich Mitarbeiter auf ihre Arbeit fokussieren können und alle Mittel zur für die Zusammenarbeit zur Verfügung haben. Mehr dazu in diesem Video.