Warum E-Government in Deutschland nicht vom Fleck kommt

Bund, Länder und Kommunen haben sich bereits an einigen Aspekten des E-Governments versucht. Und doch wird Deutschland in allen einschlägigen internationalen Rankings im regelmäßig auf die hintersten Ränge verwiesen. Was passiert da?

Selbst Nicht-Experten fallen wahrscheinlich die folgenden Projekte ein: DeMail, eAusweis mit elektronischer Signatur oder die beliebten Behördenportale wie ServiceBW in Baden-Württemberg. Auch verwaltungsinterne Projekte wie die eAkten-Einführung kommen nicht wirklich voran, obwohl sie seit Jahren auf der Agenda stehen. Sie alle sind als Ankündigungstiger gestartet und drohen als Bettvorleger zu enden. Aus meiner Sicht kranken diese Projekte daran, dass sie eines nicht sind: anwenderorientiert und kundenfokussiert.

Im ganzen Entwicklungsprozess beziehen sie selten bis gar nicht die Sicht der Anwender mit ein. Sie bleiben außen vor und spielen keine Rolle. Und daher werden Schwachstellen und Denkfehler auch erst dann sichtbar, wenn die Umsetzung abgeschlossen ist und das Angebot nicht angenommen wird.

Wenn Bürger lieber Schlange stehen

Zwei Beispiele aus der Praxis zeigen das Dilemma treffend auf: Ein bayrischer Landkreis hat sich auf die Fahnen geschrieben, die Kfz-Abmeldung online abzuwickeln. Sehr gute Idee, denn die Warteschlangen in den Kfz-Zulassungsstellen sind immer recht lang, auch wenn man einen Termin vereinbart hat. Mit Engagement und viel Einsatz wurde der Prozess digitalisiert. Doch am Ende wunderte man sich im Landratsamt, warum gerade mal ein Prozent der Bürger die Möglichkeit nutzt und die restlichen 99 Prozent lieber weiterhin in der Warteschlange am Schalter stehen.

Die Antwort ist einfach: Bei der Umsetzung hatten die Projektentwickler zwar – vorbildlicherweise – immer die Rechtssicherheit und den Datenschutz im Fokus, aber nie die Anwender mit ihren Bedürfnissen. Sie saßen nicht mit am Tisch, sie konnten kein Feedback geben. Heraus kam ein rechtssicherer, wasserdichter digitalisierter Verwaltungsprozess, der vom Anwender verlangte, zig Zahlencodes auf seinen Fahrzeugpapieren freizurubbeln und mehrfach in den PC zu tippen. Statt den Weg zu vereinfachen, wurden zusätzliche Hürden geschaffen. Das wäre vermeidbar gewesen, hätte man die Anwender frühzeitig eingebunden.

Verwaltung retro-digital

Ein weiteres Beispiel erreichte mich dieser Tage auf Twitter. Da erzählte mir ein Twitterati, dass er – nur um eine Adressänderung zu übermitteln – telefonisch einen Zahlencode beim Bezirksamt anfordern musste, der ihm per Post zugeschickt wurde. Erst danach konnte er die Adresse über das Internet übermitteln und bestätigen. Ja, richtig gelesen. Er musste allen Ernstes telefonisch einen Code anfordern, der ihm in Papierform zugeschickt wurde, damit er die Adresse über ein Internetportal weiterleiten konnte. Ähnlich verhält es sich oft mit Digitalisierungsprojekten, die verwaltungsintern ausgerichtet sind. Die berühmte eAkte ist so ein Beispiel. Die potenziellen Fachanwender werden im Entwicklungsprozess selten gefragt, was sinnvoll ist und was nicht, wie er oder sie arbeitet, welche Arbeitsschritte stattfinden. Die Entscheidungen werden in Gremien getroffen, in denen kaum tatsächliche Endanwender sitzen, sondern Fachvorgesetzte, deren Aufgaben wenig Berührungspunkte mit der alltäglichen Arbeit aufweisen.

7 Thesen zum E-Government in Deutschland

Diese Beobachtung verleitet mich dazu, folgende Thesen in Bezug auf das Thema Digitalisierung und E-Government in Deutschland aufzustellen:

  1. Die Digitalisierung der öffentlichen Verwaltung kann nur gelingen, wenn sie anwenderorientiert und kundenfokussiert ist.
  2. Voraussetzung ist eine ganzheitliche Betrachtung der bestehenden Prozesse, der Infrastruktur und Architektur.
  3. Damit die Digitalisierung im Verhältnis „Bürger – Verwaltung“ gelingen kann, muss die Digitalisierung im Inneren der Verwaltung zuerst umgesetzt werden. Was bringt das schönste Bürgerportal, wenn im Hintergrund die Prozesse analog und Medienbrüche der Normalzustand sind.
  4. Iteratives und inkrementelles Vorgehen verringert die Wahrscheinlichkeit eines Scheiterns der Digitalisierungsprojekte der öffentlichen Hand. Fehler werden früh entdeckt und es kann frühzeitig gegengesteuert werden.
  5. Die klassische funktionale Arbeitsteilung der Behörden funktioniert in solchen Projekten nicht. Digitalisierungsprojekte müssen crossfunktional, über Zuständigkeitsgrenzen hinweg gedacht und umgesetzt werden.
  6. Die klassische, hierarchische Denkweise schadet diesen Projekten. Sie blockiert die Anwenderorientierung, indem sie Sachbearbeiter als eigentliche Anwender aus dem Entscheidungsprozess ausklammert. Die Expertise der Fachleute an der Basis bleibt ungenutzt.
  7. Digitalisierung ist nicht die Fortführung der Papierakte auf elektronischem Wege, sondern eröffnet neue Möglichkeiten und Sichtweisen. Erst wenn die Entscheider „out-of-the-box“ denken, wird sie gelingen.

Die Geisteshaltung des agilen Manifests und die Anwendung der entsprechenden Methoden können zwar keine Wunder bewirken, aber sie können dazu beitragen, dass E-Government-Projekte erfolgreicher werden.

Foto: CC0 Creative Commons – pixabay, Alexas_Fotos

Scrum vs. Wasserfall: Auch Agilität braucht Planung

Nach wie vor passiert es, dass wir im Projektalltag den Unterschied zwischen Wasserfall und Agilität erklären müssen. Viele Mythen ranken sich vor allem um die Frage: „Wird denn in Scrum überhaupt geplant, und wenn ja, für welchen Zeitraum?“ Bei den Erklärungsversuchen wird schnell klar: Die Unterschiede zum agilen Projektmanagement werden viel einfacher ersichtlich, wenn es ein Verständnis für das gibt, was Scrum nicht ist. Machen wir also einen kleinen Exkurs in die Welt des klassischen Projektmanagements, um diesem Unterschied auf den Grund zu gehen.

Wasserfall: Genaue Spezifikation vorab

Das Wasserfallmodell gilt als charakteristisch für das klassische Projektmanagement der vergangenen Jahre. Dabei werden sequentielle Projektphasen gebildet, die in einer klar definierten Reihenfolge verlaufen. Umgangssprachlich wird das Wasserfallmodell auch “Over-The-Wall-Ansatz” genannt: Es werden aufeinander aufbauende Teilergebnisse geliefert, die auf ein vorab vollständig spezifiziertes Projektziel einzahlen. Diese Teilergebnisse sind klar voneinander abgegrenzt und werden meist wie über eine Mauer in den nächsten Bearbeitungsschritt „geworfen“. Die Mitarbeiter sind bei dieser Vorgehensweise ausschließlich für einen kleinen Bereich des Gesamtprodukts verantwortlich – den Gesamtzusammenhang müssen sie nicht zwingend verstehen.

Scrum: Mit kontinuierlichem Feedback zum passgenauen Ergebnis

Agile Vorgehensweisen basieren auf einem iterativen und inkrementellen Ansatz, es wird mit Feedbackschleifen und Teilprodukten als Lieferungen gearbeitet. Schnelles Kunden- und Nutzerfeedback, kontinuierliche Verbesserung und das Liefern vollständig abgeschlossener Produktfunktionalitäten stehen dabei im Fokus der Entwicklung. Im Gegensatz zum Wasserfallmodell ist es eine Aneinanderreihung vieler PDCA-Zyklen, es gibt also ein kontinuierliches „Plan – Do – Check – Act“ entlang der gestellten Anforderungen. Das ständige Abgleichen des erreichten Status Quo spitzt das Ergebnis besser auf das zu, wofür der Kunde letztendlich wirklich bezahlen möchte. Somit kann es nicht vorkommen, dass lange Zeit in eine falsche Richtung gearbeitet wird, denn Änderungen in den Anforderungen und in der strategischen Stoßrichtung können kurzfristig berücksichtigt und umgesetzt werden. Sinnvoll wird diese Vorgehensweise gerade dann, wenn man sich in einem sehr dynamischen Umfeld befindet, in dem Anforderungen und Technologie noch unbekannt sind oder sich häufig ändern.

Wie plant man eigentlich agil?

Wenn wir nun also die Kollegen fragen, was sie am Wasserfall so sehr schätzen, berufen sich viele auf die Möglichkeit der langfristigen Planung. Das sei mit Scrum schließlich nicht möglich, dort würde nur in Sprints mit einem Horizont von zwei Wochen gedacht. Weit gefehlt. Natürlich wird auch in Scrum in Form eines Releaseplans ein Planungsausblick über eine längere zeitliche Einheit hinweg gewährleistet. Trotzdem wird in Sprints gedacht und der Releaseplan ist in Zwei-Wochen-Abschnitten getaktet. Ein massiver Unterschied zur Wasserfallplanung ist aber die Tatsache, dass es sich stets um eine lebendige Planung handelt und diese, je nach Umständen und Rahmenbedingungen, zu gegebener Zeit angepasst werden sollte. Gerade in dynamisch hochkomplexen Märkten können sich die Anforderungen innerhalb kurzer Zeit ändern, sodass eine agile Anpassung der Planung überlebenswichtig wird.
Denn im Vordergrund steht das Produkt, mit dem man einen möglichst hohen Geschäftswert erzeugen möchte. Die Frage lautet also: Welche Funktionalitäten müssen wir in den nächsten Sprints in jedem Fall entwickeln, sodass wir die richtigen Funktionalitäten und damit den maximalen Mehrwert bieten, mit dem wir Käufer gewinnen können?
Viel Erfolg in euren Projekten wünschen euch Jessica und Marcel!

Foto: CC0 Creative Commons – Pixabay, Pexels

Wohnung putzen mit dem Minimum Viable Product

„MVP“ – Minimum Viable Product – ist ein verbrannter Begriff. Er wurde missbraucht, um eine Brücke zwischen dem klassischen und dem agilen Projektmanagement zu schlagen. Arbeitspakete des Projektablaufplans werden kurzerhand zu MVPs umgetauft – so wirkt alles schon viel agiler. Dabei wird jedoch eines vergessen: Ein MVP ist ein Produkt, das mit seinen Eigenschaften bereits die minimalen Anforderungen des Kunden abdeckt. Ein Produkt, das in sich geschlossen ist und einen Mehrwert bietet. Etwas, das schon verkauft werden könnte und wofür der Kunde bezahlen würde. Wenn der Kunde beispielsweise sagt, er möchte von Punkt A zu Punkt B gelangen, dann ist ihm mit einem Reifen nicht geholfen. Dazu benötigt er schon ein Fortbewegungsmittel, das seiner wichtigsten Anforderung – der Fortbewegung – genügt. Aufbauend auf diesem MVP können anschließend weitere Anforderungen hinzugefügt werden – der Kundennutzen wächst und ein neues MVP entsteht. Trotzdem fällt es vielen schwer, die Übertragung aus der klassischen Welt mit ihrer Meilensteinplanung hin zur Customer Journey mit MVPs und einem Releaseplan nachzuvollziehen. Für den Ausbruch aus diesen eingefahrenen Denkmustern braucht man manchmal aber nur einen kreativen Ansatz, um den Zusammenhang klarer zu machen. Was eignet sich dafür besser als eine alltägliche Situation?

Putzen Sie Ihre Wohnung – MVP 1

Angenommen, der Wohnungsputz wird hauptsächlich von Ihrer Partnerin oder Ihrem Partner durchgeführt. Stellen Sie sich vor, sie wollen ihr oder ihm diese Aufgabe nun einmal komplett abnehmen. Wo fangen Sie an zu putzen? Welche Räume nehmen Sie sich vor? Und die wichtigste Frage: Wie viel müssen Sie putzen, damit sie oder er zufrieden ist, Sie aber nicht mehr als nötig gemacht haben? Dafür ist für Sie wichtig zu wissen, was der „Putz-Standard“ bei Ihnen zuhause ist. Die Mindestanforderungen Ihrer Partnerin oder Ihres Partners an den Wohnungsputz sind ein wichtiger Teil der Vorbereitung. Sinnvoll ist es außerdem, die Aufgaben zu sammeln, die in der gesamten Wohnung regelmäßig anfallen. Diese Aufgaben können gut den jeweiligen Räumen zugeordnet werden. So entsteht eine in Rubriken strukturierte Sammlung wie „Wohnzimmer“, „Küche“, „Bad“ und „Schlafzimmer“. Diese Rubriken können Sie mit Themenklammern gleichsetzen, also sogenannten Epics.
Wenn Sie nun also wissen, dass Ihre Partnerin oder Ihr Partner glücklich ist, wenn in jedem Raum gewisse Aufgaben erledigt sind, so ergibt sich für Sie eine Anzahl an Aufgaben, die in Summe das MVP ergeben. Nach der Erledigung sämtlicher Aufgaben, die zur Erfüllung des MVPs beitragen, kann das Ergebnis vorgeführt werden. Sie werden recht schnell merken, ob Ihre Überraschung geglückt ist und Sie alle Anforderungen erfüllt haben!

Stellen Sie sich vor, die Schwiegermutter kommt zu Besuch – MVP 2

Nun ist also Ihre Partnerin oder Ihr Partner durch dieses MVP zufrieden gestellt. Was passiert allerdings, wenn sich spontan die Schwiegermutter mit einem Besuch ankündigt? Dann muss das ursprüngliche MVP ein bisschen erweitert werden. Und zwar um genau die Aufgaben, die dabei helfen, auch die Schwiegermutter zufrieden zu stellen. Die Anforderungen aus dem ersten MVP bestehen weiterhin, es gibt jedoch Aufgaben, die es ergänzen. Das Gesamtpaket ergibt dann ein neues MVP.
Die gleiche Vorgehensweise kann auch in der Produktentwicklung angewendet werden. Auch dort sollte angestrebt werden, mit einem ersten Produkt, das dem Kunden einen Mehrwert bietet, den Markt bedienen zu können. Somit kann erstes Kundenfeedback frühestmöglich in die nächste Iteration einfließen. Außerdem lassen sich mit diesem Ansatz Fehlinvestitionen vermeiden und somit das Risiko minimieren, indem früh erkannt wird, ob eine Weiterentwicklung des MVP rentabel ist und welche Funktionalitäten vom Kunden überhaupt gewünscht und bezahlt werden.
Allgemein ist, wie auch beim Wohnungsputz, dabei zu berücksichtigen, wer die Zielgruppe des Produkts ist. So können Unternehmen entlang der Customer Journey ein Produkt entwickeln, das die rentabelsten Funktionalitäten enthält und die Kundenbedürfnisse befriedigt. Im Gegensatz zur klassischen Produktentwicklung setzt der Cashflow hierbei wesentlich früher ein, die Reaktions- sowie Entwicklungszeiten sind kürzer und der Kunde steht im Zentrum der Überlegungen. Der Trick ist also eine geänderte Perspektive auf die Produktentstehung.

Viele Produkte, ein Team – Stiefkind der Skalierung

Wenn sich ein Unternehmen mit dem Thema Scrum auseinandersetzt, kommt früher oder später die Frage auf, wie es denn mit der Skalierung aussieht. Häufig wird jedoch recht undifferenziert von Skalierung gesprochen und nur wenige wissen genau, was sie eigentlich meinen. Es gibt aber eine einfache Übersicht, die Christoph auch in einem unserer letzten Meetups zum Thema „SKALIERUNG! SKALIERUNG! SKALIERUNG!“ gezeigt hat. Diese macht klar, in welchem Kontext man sich bewegt und was sinnvollerweise zu tun ist.

Skalierung

(c) Christoph Schmiedinger, Matthias Wolf-Dietrich

Für die Übersicht ziehe ich einen Graphen mit zwei Achsen auf. Die vertikale Achse zeigt die Anzahl der Produkte in einem Unternehmen oder einer Abteilung, auf die horizontale Achse trage ich Anzahl der Teams auf, die zur Verfügung stehen bzw. welche die Arbeit erledigen. Für den 1. Quadranten gilt es, ein Hochleistungsteam zu formen, dass liefert und regelmäßig reflektiert – zum Beispiel mit Scrum. In den Quadranten 2 und 4 müssen sich viele Teams um ein oder mehrere Produkte kümmern. Diese Situationen haben die meisten Menschen im Kopf, wenn sie über Skalierung sprechen. Ich konzentriere mich hier nun auf den linken oberen Quadraten 3: viele Produkte – ein Team. Das ist eine Situation, die bei der Skalierung gerne vergessen wird und dementsprechend bekommen solche Teams wenig Aufmerksamkeit von Führungskräften und/oder Coaches.

Das Problem des fehlenden Fokus

Eine typische Ausprägung davon sind Entwicklungsteams, die neue Varianten bestehender Produkte entwickeln. Auch in etablierten Produktbereichen mit relativ langlebigen Produkten, die sich um Seriensupport kümmern oder Verantwortung für das Lifecycle Management haben, ist diese Situation ganz alltäglich. Meist sind auch die berüchtigten „Cash Cows“ betroffen. Aber mit welchen Schwierigkeiten muss ein Team in dieser Konstellation kämpfen? Das größte Problem ist der fehlende Fokus und die damit verbundenen langen Bearbeitungszeiten. Ein großer Effizienzkiller ist, dass die Aufmerksamkeit häufig von einem Produkt zum anderen wechselt und die Wahrscheinlichkeit höher ist, unterbrochen oder gestört zu werden. Das zwingt die Teammitglieder dazu, sich immer und immer wieder neu in die unterschiedlichen Themen reinzudenken. Kaum hat es sich in eine Aufgabe eingefunden, muss sich das Teammitglied aus verschiedenen Gründen auf das nächste Thema stürzen.
Sicher kennen Sie auch die schier erdrückende Last einer langen und stetig wachsenden To-Do-Liste. Wie gelähmt sitzt man vor der Menge an Aufgaben und weiß gar nicht, wo man anfangen soll. Das Resultat: Das Team ist überlastet, die Wahrscheinlichkeit von Fehlern steigt und die Bearbeitungszeiten steigen noch weiter an. Ein häufiges Symptom ist das ständige Arbeiten im Feuerwehrmodus. Kaum hat das Team ein Feuer gelöscht, flammt gleich das nächste Glutnest auf. Was soll man hier tun? Die folgenden fünf Schritte verhelfen zu mehr Klarheit.

  1. Priorisierung nach der Cost of Delay. Der mögliche Durchsatz des Teams, also die Menge der möglichen Lieferungen, ist die einschränkende Größe. Da es üblicherweise deutlich mehr Opportunitäten als vorhandene freie Zeit gibt, gilt es hier mehr noch als sonst, nur an den wichtigsten, sprich wirtschaftlich wertvollsten Themen zu arbeiten. Die Bewertung kann nach den Verzögerungskosten oder „Cost of Delay“ erfolgen: Wie hoch sind die Kosten bzw. der entgangene Gewinn, wenn ein Thema später – oder gar nicht – durchgeführt wird. Je höher diese Verzögerungskosten sind, desto eher sollte das Team an diesem Produkt arbeiten. Eine weitere Bewertungsmöglichkeit ist der Return on Investment, bei dem aber häufig die zeitliche Komponente ignoriert wird.
  2. Nein sagen. Da der Durchsatz des Teams durch den Engpass im Team bestimmt wird, muss dieser identifiziert und möglichst gut ausgenutzt werden, gleichzeitig aber auch möglichst gut beschützt werden. Er soll also nicht von anderen Teammitgliedern, anderen Teams oder Abteilungen mit neuen Aufgaben verstopft werden (https://blog.borisgloger.com/2017/01/19/the-malicious-behavior-of-non-constraints/). Um sicherzustellen, dass das Team möglichst zielgerichtet am wertvollsten arbeiten kann, müssen Kontextwechsel so gut es geht vermieden werden. Für den Product Owner heißt das: Nein sagen. Konsequent und immer wieder. Ideen für neue tolle Produkte, die unbedingt JETZT umgesetzt werden müssen, gibt es wie Sand am Meer. Die Herausforderung ist, keine Produkte oder Aufgaben mit geringerem Wert zuzulassen.
  3. Fehler sofort beheben. Es ist extrem wichtig, keine halbfertigen Produkte oder Aufgaben zuzulassen. Der fast schon fanatische Fokus auf Qualität stellt sicher, dass einen die Fehler später nicht einholen. Das erschwert das Jonglieren mit vielen Themen oder macht es sogar unmöglich. Das Schlimmste was passieren kann: Ein Thema, das eigentlich schon erledigt war, kommt wieder und muss gelöst werden. Schnell ertrinkt man in Nacharbeit und Fehlerbehebungen. Wenn man ohnehin schon Dutzende Themen in der Luft halten muss, ist das nicht angenehm und bricht einem Team schnell das Genick.
  4. Definition of Done. In diesem Umfeld bietet es sich an, mit sehr kurzen Sprints oder flussbasierten Systemen wie Kanban zu arbeiten. Um die Qualität möglichst hoch zu halten, braucht es eine gemeinsame Definition of Done (DoD), die auch durch das gesamte Team eingehalten und eingefordert wird. Das beinhaltet auch den ScrumMaster und den Product Owner. Regelmäßige Refinements und grundsätzlich moderne Arbeitspraktiken wie Mob Working unterstützen hier noch weiter.
  5. Portfoliomanagement. Um sicherzustellen, dass die zahlreichen Themen nicht das Team überschwemmen, ist eine Form von Portfoliomanagement sinnvoll. Der einfachste Weg ist es, das Portfolio zu visualisieren und damit zum regelmäßigen Gegenstand der Gespräche von Product Owner, Entwicklungsteam und der anderen Stakeholder zu machen. Wichtig ist weiter, dass regelmäßig und zeitnah Entscheidungen getroffen werden.

In den nächsten Artikeln dieser kurzen Serie werde ich die restlichen Quadranten und das empfohlene Vorgehen beschreiben.

Foto: CC0 Creative Commons – pixabay, pexels

Magic System Mapping oder "How to make toast"

Ein und dasselbe Thema – viele Sichtweisen und Wissensstände. So sieht es oft in einem Team aus, bevor es an die Entwicklung eines Produkts geht oder ein bestimmtes Problem gelöst werden soll. Mit „Magic System Mapping“ lassen sich individuelle Sichtweisen und Standpunkte, die es innerhalb einer Gruppe zu einem Thema oder Problem gibt, zu einem Gesamtbild zusammenführen.
Magic System Mapping beruht auf ähnlichen Prinzipien wie Magic Estimation: non-verbale Kommunikation wird visualisiert. Ich habe diese Methode schon für unterschiedliche Zwecke verwendet:

Wie funktioniert Magic System Mapping?

Um die Methode zu erklären, beginnt man mit einer einfachen Design-Übung, die je nach Gruppengröße 10 bis 15 Minuten dauert. Ausgedacht hat sich das ganze Tom Wujec, Businesss-Visualisierungs-Pionier und Mitgründer der Singularity University, der die Hintergründe fabelhaft in einem TED-Talk vorstellt.

Was man dafür braucht
Anmoderation der Aufgabe

Die Teilnehmer werden begrüßt, anschließend kündigt ihr an, dass ihr mit ihnen jetzt eine viertelstündige Design-Aufgabe mit anschließender Reflexion durchführt. Dazu bittet ihr die Anwesenden, in den nächsten fünf Minuten auf Post-its aufzuzeichnen, wie sie Toast machen. Dazu gibt es drei Regeln:

  1. Jeder macht die Aufgabe im ersten Schritt für sich.
  2. Nur ein „Toastmachschritt“ auf je einem Post-it.
  3. Das Ganze ist kein Kunstwettbewerb.

Optional könnt ihr noch erwähnen, dass zehn Post-its pro Person ein guter Anhaltspunkt für die Granularität der einzelnen Schritte sind. Falls noch nicht geschehen, könnt ihr jetzt die Post-its austeilen.

Review der Toast-Modelle

Nach Ablauf der drei Minuten bittet ihr einen Kollegen damit anzufangen, seine Toastmachschritte auf der freien Wandfläche von links nach rechts aufzuhängen. Dann geht es weiter mit der nächsten Person, er oder sie hängt sein Toastmodell darüber oder darunter. Falls er oder sie ähnliche Schritte hat, können sie unter bzw. übereinander angeordnet werden. Das Ganze wiederholt ihr, bis jeder sein Toastmodell geteilt hat.
Nachdem alle ihre Modelle aufgehängt haben, könnt ihr die Teilnehmenden fragen, was ihnen an den unterschiedlichen Modellen auffällt. Zum Beispiel: Wie komplex oder simpel sind die jeweiligen Modelle, werden dabei Personen oder keine Personen gezeigt? Diese Phase könnt ihr kurz halten. Zwei bis drei Wortmeldungen aus der Gruppe genügen.

Magic System Mapping

6 verschiedene Toast-Modelle im Vergleich

Zusammenführen der Toast-Modelle

Im letzten Schritt geht es darum, eine Synthese zwischen allen Toastmodellen herzustellen. Hier ist als Anforderung: Im finalen Bild darf es keine Duplikate mehr geben und es muss eine Reihenfolge erkennbar sein – und das Ganze soll ohne verbale Kommunikation gelöst werden. Im normalen Arbeitskontext kommt Letzteres auch häufig vor: Beispielsweise bei der Priorisierung von Anforderungen oder dem Treffen von Entscheidungen, ohne dass das Team mit den Stakeholdern sprechen kann.
In diesem Prozess werden sehr schnell unterschiedliche Sichtweisen und auch Konflikte in der Gruppe deutlich. Ziel ist es, eine Einigung zu finden und das im Gesamtmodell abzubilden. Schweigen ist hierbei Gold Wert. Interessanterweise funktioniert das ohne verbale Kommunikation deutlich schneller als mit.
Als Zeitvorgabe bieten sich für diesen Schritt fünf Minuten an.

Magic System Mapping

Das zusammengeführte Toastmodell ohne Duplikate in einer Reihenfolge

 

Reflexion

Nachdem die Gruppe ein Gesamtbild erarbeitet hat, gibt es erst einmal eine Runde Applaus. Den Reflexionsprozess kann man mit den folgenden zwei Fragen an die Gruppe starten:

Häufig berichten die Teilnehmenden, dass ihnen die Übung gezeigt hat, wie eingeschränkt ihre eigene Sichtweise auf ein Problem ist und wie unterschiedlich die Denkweisen von verschiedenen Personen sein können. Dieser Punkt wird häufig mit unterschiedlichen Expertisen und Spezialisierung in Verbindung gebracht. Einige Personen sind Spezialisten für einzelne Teilbereiche des Prozesses, die sie besonders stark ausdetaillieren – beispielsweise wie ein Toaster funktioniert – und andere beginnen den Toastprozess beim Weizenkorn, das gesät und bewässert wird. Nur durch die Synthese entsteht ein gesamtes System.
Als weiterer Punkt kommt in der Reflexion oft auf, dass unterschiedliche Perspektiven im System sichtbar gemacht und berücksichtigt werden können. Etwa die Tatsache, dass manche Menschen ihren Toast mit Butter essen und andere das niemals tun würden. Im Toastmodell werden die unterschiedlichen Belegungspräferenzen häufig durch übereinander hängende Post-its dargestellt.
Eine weitere Erkenntnis der Übung ist: Abgebildete Systeme bestehen immer aus Knoten und Verbindungen, die eine Logik herstellen. Die Übersetzung in BPMN-Sprache wäre: flow-basierte Objekte wie Ereignisse oder Aktivitäten und verbindend strukturierende Elemente wie Kanten/Assoziationen oder Gateways.

Anwendung im realen Kontext

Nach der Trockenübung mit dem Toastbeispiel könnt ihr euch eurem tatsächlichen Thema oder Problem zuwenden. Der Ablauf ist am Anfang analog zum Toastbeispiel:

  1. Startet mit eurer Fragestellung – falls sie noch zu grob ist, nehmt euch etwas Zeit, um sie in der Gruppe genauer zu spezifizieren
  2. Sammelt in der Gesamtgruppe die Knotenpunkte
  3. Entwickelt ein Gesamtbild/System in der Gruppe und stellt die Verbindungen her
  4. Verfeinert das System in der Gruppe
  5. Verfeinert das System weiter …
  6. … und weiter

Je mehr Runden ihr in die Verfeinerung des Systems steckt, umso klarer wird das System für die Beteiligten. Im Zuge dessen werdet ihr auf immer feingranularere Probleme oder Abhängigkeiten stoßen, für die es Lösungen zu finden gilt.
Mein Tipp für diese Phase: Teilt euch in Kleingruppen auf und arbeitet einzelne Teile eurer Systems genauer aus. Nehmt euch dafür je nach Größe und Komplexität des Themas 30 bis 60 Minuten Zeit. Danach stellt jede Kleingruppe ihre Ergebnisse vor, sie werden diskutiert und anschließend in das System eingebaut.
Wie viel Zeit ihr für diesen Prozess benötigt, hängt von der Komplexität eurer Fragestellung ab. Ich beginne meistens mit einer dreistündigen Session, in der am Anfang Zeit für die „How to make Toast“ Übung ist. Am Ende wird besprochen, wie an den Ergebnissen weitergearbeitet wird. Ich habe aber auch schon mehrtätige Off-Sites in diesem Stil organisiert.

Eine abschließende Bemerkung

Das Feedback der Teilnehmenden war bisher immer positiv. Die Methode hat nur einen Haken: Das erarbeite System ist eine Momentaufnahme – abhängig von den Beteiligten, und es hat nur Gültigkeit, solange man in der Gruppe zusammenbleibt. Durch den iterativen Ausarbeitungsprozess hat eine Verständigung auf Begrifflichkeiten und Regeln für das System stattgefunden. Ein Außenstehender kann das Abgebildete nur mit Hilfe von guter Dokumentation verstehen.
Das ist aber auch für die Teilnehmenden wichtig: Ab dem Moment, an dem sie den Raum verlassen, machen sie neue Erfahrungen, führen Diskussionen mit Kollegen oder haben Ideen, die Auswirkungen auf das System haben. Was kann man dagegen machen? Man muss den Prozess regelmäßig wiederholen, um ein längerfristiges Alignment herzustellen und das System an die aktuellen Gegebenheiten anzupassen. Am Ende ist es die Auseinandersetzung mit dem richtigen Personenkreis zu einem Thema, was uns am Ende erfolgreich macht. Die Visualisierung ist dabei nur ein Hilfsmittel. In diesem Sinne wünsche ich euch viel Erfolg und Spaß beim kollaborativen Visualisieren.

Ressourcen

Templates zu verschiedenen Themen:
DrawToast
Mural – ein gutes Tool für kollaboratives Visualisieren
Originalartikel erschienen im ProjektMagazin – verwendet mit freundlicher Genehmigung.
Foto: CC0 Creative Commons – pixabay, pexels

Design Thinking aus der Praxis

Die Theorie von  Design Thinking muss ich euch nicht mehr erklären. Ich möchte euch dazu zwei Variationen vorstellen: den Design Sprint, der sich für noch vage Ideen eignet, und freie Varianten des Design Thinkings für schnelles Prototyping. Wichtig ist bei allen Ansätzen die Zusammensetzung des Teams. Mehr dazu in diesem Video.

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.

Fragen und Antworten zum Innovation Lab

Wie könnte die Vision für ein InnoLab lauten?

Eines unserer aktuellen InnoLabs an einem großen Produktionsstandort hat sich die Vision auf die Fahne geschrieben, innovativen Ideen aus dem Kreis der Belegschaft einen Raum zu geben und sie mit agiler Unterstützung schnell in die Umsetzung zu bekommen. Jede Idee ist willkommen, solange es etwas mit dem Arbeiten im Werk zu tun hat. Die Leute kommen beispielsweise in dieses InnoLab, weil sie die Produktion am Band verbessern oder etwas für die Zufriedenheit der Mitarbeiter und Mitarbeiterinnen tun wollen. Dabei begleiten wir die Produktentwicklungen nach Möglichkeit von der ersten Formulierung der Idee bis zum produktiven Status.
Das InnoLab ist also ein interner Inkubator für direkt nutzbare Verbesserungen. Wir entwickeln mit dem Nutzer an der Einsatzstelle und lassen mit den Mitarbeitern damit nicht nur ein völlig neues, anspornendes Selbstbild entstehen, sondern schaffen auch Produkte, die tatsächlich gebraucht werden.

Was genau passiert in einem InnoLab?

In unserem aktuellen InnoLab durchläuft eine Idee die folgenden Schritte:

  1. Formuliere eine Idee und stelle diese im Rahmen einer Pitchveranstaltung vor.
  2. Freiwillige Mitarbeiter des Werkes dürfen zwischen unterschiedlichen Ideen entscheiden. Der Gewinner wird nach dem Mehrheitsprinzip ermittelt.
  3. Werde als Ideengeber oder als ein von der Idee begeisterter Mensch der Product Owner.
  4. Stelle ein interdisziplinäres Team aus internen Experten (aus den Fachabteilungen, aus der IT oder aus den Produktionshallen) zusammen.
  5. Hole dir die Unterstützung durch einen ScrumMaster.
  6. Jetzt hast du mit deinem Scrum-Team sechs Wochen Zeit für die initiale Umsetzung der Vision und für die Erstellung eines Prototyps.
  7. Suche dir interne oder externe IT-Dienstleister für die Umsetzung, wenn du eine digitale Lösung umsetzen möchtest. Suche dir die jeweiligen Experten, wenn deine Lösung außerhalb der IT liegt.
  8. Nutze dein Startkapital von 20.000 Euro (für die IT-Unterstützung und etwaige andere Kostenpunkte bspw. Hardware).
  9. Pitche deinen fertigen Prototypen wie in der „Höhle des Löwen“ (bestehend aus bspw. 4 Führungskräften aus unterschiedlichen Fachrichtungen wie Controlling, Strategie, Produktion, Human Resources etc.).
  10. Überzeuge die Löwen und erhalte ein Go für die von dir beantragten Gelder und die Möglichkeit, weitere drei Monate im InnoLab zu arbeiten.
  11. Die „Höhle der Löwen“ öffnet sich jedoch maximal zwei weitere Male. Somit muss dein Produkt nach rund 1 Jahr das InnoLab verlassen und allein in der Linie laufen können.

Was kann man in einem InnoLab lernen?

Die Produktentwicklungen im InnoLab passieren im Vergleich zum herkömmlichen Konzern-Kontext unvergleichlich schnell, denn die direkte Entwicklung mit dem Anwender ist heutzutage leider immer noch eher selten.
Um beides erfolgreich umzusetzen, haben sich im InnoLab mehrere (agile) Prämissen als hilfreich erwiesen:

Welche Herausforderungen gibt es in einem InnoLab?

Trotz vieler Erfolge und positiver Stimmen stehen wir vor einigen Herausforderungen. Am Ende des einjährigen Entwicklungszyklus sind die Produkte häufig bereits auf die Produktion ausgerollt und werden an verschiedenen Standorten, in verschiedenen Abteilungen und Produktionshallen genutzt. An dieser Stelle müssten die Produkte in die Linie überführt werden, weitergeführt und gewartet werden.
Dabei stoßen wir noch immer häufig an die starren Strukturen, die uns Geschwindigkeit nehmen und den Rollout erschweren. Und noch ein Punkt: Nicht alle Produkte werden wirklich breit produktiv ausgerollt. Viele Unterstützer, die den Weg begleitet haben, erfahren das als Enttäuschung. Wovon wir jedoch überzeugt sind, ist: Wir haben tolle Ideen verfolgt, wir haben Anwender*innen eingebunden, wir haben Produkte verprobt und rechtzeitig festgestellt, dass es (vielleicht noch) nicht an der Zeit ist für diese Produkte. Was jedoch bleibt und über den Product Life Cycle hinaus wirkt: Die Leute gehen in ihre Teams in der Linie zurück, nehmen Impulse zum neuen Arbeiten mit und verändern weitere Bereiche des Unternehmens von dort aus.
Unser Tipp: Bevor ein Innovation Lab so richtig fliegen kann, sollten im Zuge einer Organisationsentwicklung einige Impediments beseitigt werden:

Der Faktor Mensch in der Produktentwicklung

 
Während meiner bisherigen Berufslaufbahn habe ich viele Projekte gesehen und betreut. Dabei wurde mir immer mehr klar, dass Projekte – oder im weiteren Sinne Produkte – nicht scheitern, weil das technische Know-how oder kreative Ideen fehlen. Produktentwicklungen scheitern, weil bei der Zusammenarbeit von Menschen Konflikte, Aversionen und Befindlichkeiten auftreten und dazu führen, dass Teams nicht an einem Strang ziehen. In der Folge werden wichtige Informationen nicht geteilt oder sogar zurückgehalten, im schlimmsten Fall werden Teammitglieder ausgeschlossen. Dabei wäre so viel möglich! Google hat lange untersucht, was funktionierende und produktive Teams ausmacht und wie essenziell sie für eine erfolgreiche Produktentwicklung sind. Am wichtigsten ist die Kommunikation zwischen den Teammitgliedern und das gegenseitige Vertrauen.

Wie kann Vertrauen entstehen?

Ganz einfach: durch die Sicherheit im Team. Dazu gehört, die anderen zu akzeptieren und zu respektieren. Niemand soll verändert werden, sondern die Möglichkeit haben, sich einzubringen und Ansichten zu äußern. Ist ein Team einmal an diesem Punkt, können Konflikte früh angesprochen und beigelegt werden. Jeder lernt, den anderen einzuschätzen und auch Erwartungen entsprechend zu artikulieren. Dadurch entsteht Spaß an der Arbeit, und so abgedroschen es klingt: Dadurch wird auch die Entwicklungsarbeit im Team erfolgreicher! Wer Spaß an dem hat, was er tut, sucht nach Möglichkeiten, nicht nach Hindernissen. Häufig motivieren sich in diesem Moment die Teammitglieder gegenseitig und so entsteht eine echte Symbiose unterschiedlicher Fähigkeiten.

Teamentwicklung und möglichst viel Kommunikation – war da nicht was?

Agile Frameworks wie Scrum zielen genau darauf ab: kurze Feedbackschleifen sowie direkte und regelmäßige Kommunikation im Team. Es geht immer um Kommunikation und gerade dabei läuft so viel schief. Ermöglichen wir sie, entsteht ein besseres Zusammenarbeiten. Dazu hat Henrik Kniberg ein sehr interessantes und sehenswertes Video veröffentlicht.
So legt gerade die Retrospektive als institutionalisiertes Meeting den Fokus darauf, das Team kontinuierlich voranzubringen oder anders gesagt, das notwendige Vertrauen herzustellen. Anders als früher, als ein Lessons-Learned-Workshop am Ende eines Projekts durchgeführt wurde und keinen wirklichen Nutzen lieferte, reflektiert das Team von Anfang an die gemeinsame Zusammenarbeit im Projekt und schafft somit sehr früh eine stabile Vertrauensbasis.
Das gilt übrigens nicht nur auf der Teamebene, sondern auch auf skalierter Ebene. Denn Konflikte entstehen auf Grund der sozialen Verhaltensweisen auch zwischen Teams. Das sieht man zum Beispiel an fehlender Kooperation wegen eines dominanten Wettbewerbsgedankens, Status- oder Silodenkens. Informationen dürfen oder sollen, teilweise vorgegeben durch das Management, nicht geteilt werden. Allerdings fördert dies Misstrauen und verhindert letztendlich das Bestreben, ein gemeinsames Produkt zu entwickeln.
Produktentwicklungen sind jedoch nur dann erfolgreich, wenn die Zusammenarbeit zwischen Menschen ermöglicht wird. Ist diese Voraussetzung nicht gegeben oder wollen Menschen nicht miteinander arbeiten, scheitert jede Produktentwicklung. Der Faktor Mensch bestimmt am Ende jedes Projekt. Denn Menschen sind keine Maschinen, sondern Wesen mit sozialen Verhaltensweisen (z. B. mit dem Wunsch nach Anerkennung). Damit alle an einem Strang ziehen, müssen sie auch in dieselbe Richtung schauen. Eine gemeinsame Vision, an die alle glauben und auf die sie sich immer wieder rückbesinnen können, sobald unterschiedliche Strömungen auftreten, hilft dabei.
 

ModernRE 2017 – Interview mit Boris Gloger über agiles Requirements Engineering

 
Im Zuge der ModernRE 2017 kam Gerhard Versteegen, Geschäftsführer von HLMC Events GmbH auf mich zu und hat mich gebeten ein paar Fragen zum agilen Requirements Engineering zu beantworten:
 

1. Worin unterscheidet sich agiles Requirements Engineering maßgeblich von klassischen Requirements Engineering ?

Es geht im Grunde um einen Paradigmenwechsel. Das agile Requirements Engineering fragt nicht, was der Kunde möchte, sondern was er tatsächlich braucht und welche Bedürfnisse noch gestillt werden müssen.

2. Was sind die wesentlichen Vorteile von agilem Requirements Engineering deiner Meinung nach?

Der Kunde muss sich nicht mit Fragen beschäftigen, die er in der Regel sowieso nicht beantworten kann. Die Verantwortung für das Erheben der Anforderungen liegt beim Fragenden, der nach Problemen nicht nach Anforderungen fragt.

3. Welche Erhebungstechniken sind aus deiner Sicht die erfolgreichsten?

Eine derzeit sehr beliebte Technik ist das Design Thinking. Hier wird systematisch versucht herauszufinden, was der Kunde wirklich braucht. Erwähnenswert sind zudem das Prototyping  – diese Methode zeigt dem Kunden sofort, was er bekommen könnte – sowie das ausführliche Erfragen von Problemen der Fokusgruppen.

4. Wo macht es Sinn, dass agile und klassische Ansätze miteinander vermischt werden?

Ich bin kein Freund von Hybridansätzen. Aber sicher können in einem klassischen Ablaufmodell Elemente von agilen Verfahren genutzt werden. Wie weit Sie damit kommen, ist eine andere Frage. Am Ende ist aber dennoch eine vollständige Umstrukturierung zumeist zielführend.

5. Gibt es Projekte, wo du sagen würden, dass agiles Requirements Engineering nicht erfolgreich wäre?

Natürlich gibt es zu Beginn und während eines Projektes auch Einschränkungen, man sollte aber im Laufe der Entwicklungen den Fokus nicht verlieren. Nachdem ich gesehen habe, dass man – wie es TriAlpha bereits umsetzt – einen Fusionsreaktor agil entwickeln kann, gibt es für mich keinen Grund zu sagen, dass agiles Requirements Engineering irgendwo nicht erfolgreich wäre.

6. Ist der Product Owner typischer Weise der Nachfolger des klassischen Anforderungsmanagers?

Leider wird das oft so gesehen, doch es ist grundlegend falsch. Die Anforderungen werden nicht vom Product Owner erhoben, sondern vom Entwicklungsteam selbst.

7. Mit welchen Tools hast du im agilem Requirements Engineering bisher gute Erfahrungen gesammelt?

Ganz klar: Design Thinking, User Storys, User Story Mapping und Prototypen.

8. Wo siehst du die größten Barrieren in Unternehmen, die einen Einsatz von agilem Requirements Engineering verhindern?

Das sind auf der einen Seite die Requirements Engineers und Business Analysts – sie müssen umlernen, sich neue Skills aneignen und zu Designern werden, statt weiterhin Anforderungsdokumente zu schreiben – und auf der anderen Seite sind es die Regulierungsbehörden. Wenn in diesen Instituten verstanden würde, wie agile Vorgehensweisen dabei unterstützen, die Standards der unterschiedlichen Industrien besser einzuhalten, als mit traditionellen Methoden, könnte ein regelrechter Produktivitätsschub durch die deutsche Wirtschaft gehen.