Scrum – eigentlich so einfach wie kochen

Einzelne Teams, inzwischen aber auch ganze Unternehmen stellen sich die Frage: Wie können wir uns angesichts sich ständig verändernder Marktbedingungen so aufstellen, dass wir unsere Anpassungsfähigkeit erhöhen und gleichzeitig schneller in der Umsetzung werden? Sicher: Auf diese Frage gibt es viele mögliche Antworten und ganz sicher gibt es nicht das eine Rezept. Eine Antwort ist, die Haltung und Methoden von Scrum für sich zu entdecken und anzuwenden.
Oft erleben wir viele Hemmungen, wenn Menschen zum ersten Mal von Scrum hören und es für sich und ihren Kontext anwenden sollen. Deshalb wollen wir das Thema einmal aus einer anderen Perspektive betrachten und es mit dem Kochen vergleichen. Stellt euch vor, ein Familienmitglied hat Geburtstag. Ihr wollt diesen Geburtstag bei euch Zuhause feiern und ein Festmahl zubereiten. So ähnlich ist es, wenn man den Scrum Flow für sich entdeckt und seinen Projekt-/Arbeitsalltag mit Leben füllt.

Mit Offenheit kocht es sich leichter

Eine wichtige Voraussetzung ist aus unserer Sicht die Haltung, beispielsweise die Offenheit für Experimente. Bezogen auf unser Menü bedeutet das, nicht zu lange zu überlegen, sondern bereit zu sein, einfach loszulegen. Sich darauf einzulassen, dass das Menü während des Kochens weiter Form annimmt. Natürlich kann man beliebig viel Zeit investieren, ein besonders kreatives Menü zusammenzustellen, doch lasst uns einfach mal damit beginnen!
Auf den Kontext der Organisation übertragen, bedeutet das eine neue Haltung in der Führung: sich beispielsweise gemeinsam mit den Mitköchen zu überlegen, was traue ich mir und meinen Mitköchen zu, die Aufgaben aufzuteilen und dann loszulassen. Es bedeutet, in die Selbstorganisationsfähigkeit des Teams zu vertrauen, in die Kollaboration über horizontale und vertikale Grenzen hinweg, damit das Essen gemeinsam gelingt. Welche Zutaten tragen wesentlich zum Gelingen bei?

Die Vision: Pasta oder Schweinshaxe?

Um den Geburtstag gebührend zu feiern, wollen wir unsere liebe Familie und die Freunde bekochen. Natürlich soll es etwas Besonderes geben. Wir haben es geradezu vor Augen: Das größte Festmahl aller Zeiten soll es werden! Ein rauschendes Fest, wie es die Welt noch nicht gesehen hat. Mit einem Leuchten in den Augen erzählen wir bei der Einladung von unserem Plan und sehen, wie geradezu der Funke überspringt. Alle freuen sich auf das anstehende Fest und bieten ihre Unterstützung an. Im Scrum-Kontext ist es der Product Owner, der diese Vision in ein Produkt verwandelt und emotional kommuniziert und dadurch das Team motiviert, voller Energie an der Umsetzung mitzuwirken.

Die Constraints: der Blick in den Kühlschrank

Wir stehen also in der Küche und haben die Vision eines opulenten Festmahls vor Augen. Ein Blick in den Kühlschrank holt uns zurück auf den Boden der Tatsachen. Er ist ziemlich leer. Es ist Monatsende und das Konto zeigt überdeutlich, dass ein Großeinkauf heute nicht mehr drin ist. Es gibt aber noch ein paar Dosen geschälte Tomaten und in der Vorratskammer findet sich eine Packung Nudeln. Etwas Knoblauch ist auch noch da, frische Chili-Schoten und Olivenöl. Leider ist der Backofen seit Wochen defekt, aber immerhin funktionieren die Herdplatten, im Schrank finden sich ein Topf und eine Pfanne. Mit diesen Rahmenbedingungen lässt sich zwar kein 10-Gänge-Menü zaubern, für eine große Portion Penne Arrabbiata dürfte es aber reichen. Zusammen mit der letzten Flasche von dem guten Rotwein ergibt es das bestmöglichste Gericht.
So ambitioniert eine Vision auch sein mag, kein Produkt und kein noch so leckeres Gericht ist frei von Einschränkungen und Rahmenbedingungen, eben den sogenannten „Constraints“. Im Kontext einer Produktentwicklung geben diese Rahmenbedingungen vor, wie die Vision umgesetzt werden kann. Wie groß ist das Budget? Wie viele Mitarbeiter können an einem Projekt arbeiten? Welche gesetzlichen Vorschriften müssen eingehalten werden? Was ist technisch überhaupt machbar?

Die Rollen: Verantwortung teilen – kochen im Team

Wie auch im Scrum Flow gibt es beim gemeinsamen Kochen zugewiesene Rollen. Diese Rollen sind klar voneinander abgegrenzt: Jeder der mitkocht, übernimmt eine bestimmte Arbeit. Im Scrum Flow gibt es die drei Kernrollen Scrum Master, Product Owner und Entwicklungsteam. In drei weiteren Rollen kommen noch Kunde, User und Management ins Spiel. Auch hier sind die Rollen klar voneinander abgegrenzt: Der Product Owner weiß genau, was er oder sie am Schluss vor sich stehen haben möchte. Er organisiert das Menü und ist dafür verantwortlich, dass jeder Koch im Team die benötigten Fähigkeiten hat, um das beste Menü auf den Tisch zu zaubern. Seine „Vision“ gibt er an die Mitköche weiter, die das Entwicklungsteam bilden. Sie kochen das Menü „tatsächlich“ und bringen es in eine Form. Ohne sie würde der Product Owner das Gericht nicht rechtzeitig zur Feier fertigbekommen.
Die Rolle des Scrum Masters kann in der Küche mit jemandem verglichen werden, der sich darum kümmert, dass jeder die Zutaten hat, um seine Arbeit schnellstmöglich auszuführen. Der Scrum Master sorgt auch dafür, dass das Team ohne Probleme und Einschränkungen kochen kann, indem zum Beispiel Geschirr abgewaschen oder Abfälle entsorgt werden. Um den Scrum Flow zu vollenden, benötigen wir noch Kunde, User und Management. Im unserem Fall ist das Geburtstagskind Kunde und User. Es gibt im Vorfeld an, welche Wünsche es hat (oder das Kochteam weiß das aus vergangenen Beobachtungen), und genießt das Mahl im Anschluss an die Zubereitung. Der Manager finanziert das Geburtstagsessen, er hat nichts mit der Küche und dem Kochen zu tun. In unserem Fall könnte das der Vater des Geburtstagskindes sein.

Kochen und abschmecken: Selbstreflexion und Feedback-Loops

Lasst uns nun kochen. Um das Rezept bestmöglich umzusetzen, bietet sich ein gewisses Vorgehen an. Die taktische Ebene des Scrum Flow umfasst alle Meetings und ist mit den Anleitungen in einem Rezept vergleichbar. In diesen Anleitungen steht genau beschrieben, welche Schritte und welche Zutaten wann eingesetzt werden.
Starten wir mit dem Sprint Planning 1: In diesem Meeting überlegen wir uns, was das Festmahl beinhalten soll. Eventuell möchten wir mehrere Gänge zubereiten und entscheiden uns dafür, dass Kartoffelsuppe das Beste für den ersten Gang sei. Nachdem alle zugestimmt haben, überlegen wir uns, wie wir unseren ersten Gang umsetzen werden – vergleichbar mit dem Sprint Planning 2. Jeder Koch hat seine Aufgabe zugeteilt bekommen: Der eine wäscht die Kartoffeln, der andere schält die Kartoffeln, der Dritte schneidet sie klein und so weiter.
Nun ist das Vorgehen klar und alle Köche kommen ins Tun. Während der Zubereitung kann es Rücksprachen geben – im Scrum Flow spiegelt sich das in den Dailys wider. In diesem täglichen, rund 15 Minuten dauernden Standup-Meeting halten alle Köche kurze Rücksprachen zu den einzelnen Aufgaben. Ist die Suppe fertig, wird der Product Owner in die Küche gerufen, um zu probieren. Gefällt ihm die Kartoffelsuppe, wird sie an den Tisch gebracht und kann vom Geburtstagskind und den Gästen probiert und bewertet werden. Sind die Gäste und vor allem das Geburtstagskind zufrieden, hat die Kartoffelsuppe bestanden. Sollte es jemandem nicht schmecken, wird zum Beispiel mit weiteren Gewürzen nachgebessert – das geschieht im Rahmen des Scrum Flow mit Produkten nach dem Review. Nachdem die Kartoffelsuppe von den Genießern „abgenommen“ wurde, trifft sich das Team in der Küche und reflektiert die Zusammenarbeit, wie in einer Retrospektive.
Die Prinzipien und Vorgehensweisen von Scrum sind also eigentlich nichts Neues – sie werden in anderen Kontexten täglich praktiziert. Was vielleicht ungewohnt ist, ist die Anwendung dieser Prinzipien auf die Wissensarbeit. Fangen Sie doch einfach genau so an, wie wir es hier beschrieben haben: Legen Sie einfach los, machen Sie sich den Spaß und bereiten Sie mit Freunden ein Essen nach dem Ablauf des Scrum Flow zu. Guten Appetit!

Diesen Artikel haben Mara Ambs, Michael Gissler und Miruna Sachse im Mob-Writing gemeinsam verfasst.

Von User Experience Design, Agilität und Personas

Im Rahmen des World Usability Days und der vom Beratungsunternehmen USECON organisierten Konferenz „Return on Experience“ durfte ich einen Vortrag über den Zusammenhang zwischen User Experience Design und agilem Arbeiten halten. Zu allererst: Was ist User Experience eigentlich genau? So wie viele andere Begrifflichkeiten wird auch “User Experience” oft ungenau verwendet. Im Wesentlichen bezeichnet es die Gesamtheit der Erfahrungen, die ein Anwender mit einem Produkt oder einer Dienstleistung macht. Ziel des User Experience Design ist es, ein Produkt oder eine Dienstleistung so zu gestalten, dass die positive Erfahrung maximiert wird und negative Aspekte wie Frustration etc. vermieden werden. Somit spannt sich User Experience Design von der Gestaltung von Bildschirmmasken bis hin zum zielgerichteten Auslösen von Emotionen während der Produktnutzung.
Doch was hat das Ganze jetzt mit agilem Arbeiten zu tun?
Wenn wir uns die Ideen rund um Scrum 3.0 näher ansehen, erkennen wir, dass der User heute noch viel stärker in den Mittelpunkt rückt. Innovationsmethoden wie Design Thinking gehen ebenfalls diesen Weg und orientieren ihre gesamte Prozessmethodik ausschließlich am Endanwender. Die logische Konsequenz: Kompetenzen wie User Experience Design werden zu einer zentralen Fähigkeit von Scrum-Teams. Sie benötigen daher nicht nur einen User Experience Designer im Team, sondern müssen diese Kompetenz breiter integrieren – User Experience muss jeden im Team etwas angehen!
Die Grenzen zwischen Agilität und User Experience Design verschmelzen besonders stark bei der ganzheitlichen Integration von Personas in den Entwicklungsprozess. Personas sind fiktive Endanwender. Sie werden im Rahmen der Entwicklung modelliert, um sich besser in die Lebenswelt der künftigen User einfühlen zu können. Personas werden meist mit einem kleinen Lebenslauf versehen, um sie so real wie möglich zu gestalten. Sinn und Zweck ist es, jede User Story mit einer Persona als Rolle zu versehen. Welche Funktionalität braucht diese Persona genau? Und wie muss diese Funktionalität nutzbar sein, um die Persona zu begeistern?

Ein Beispiel aus dem Online Banking:
Ein Digital Native (20 Jahre, Student) stellt ganz andere Ansprüche an eine Überweisung als ein typischer Filialkunde (65 Jahre, Rentner). Ein „Heavy Trader“ hat an das Wertpapier-Depot völlig andere Anforderungen als der Durchschnittsbürger, der mit Wertpapieren für eine Zusatzrente spart.
So schaffen Personas die Brücke zwischen User Experience Design und User Storys. Mit Hilfe der Persona an jeder User Story kann sich das Team in die potentiellen Anwender hineinversetzen und so die optimale Lösung/Experience für jeden Anwender-Typ designen. Für Product Owner bieten Personas zudem die Möglichkeit, eine zusätzliche Achse der Priorisierung einzubeziehen. Funktionen, die hochprofitable Kunden (wie z.B. Heavy-Trader) überdurchschnittlich nutzen würden, wären eventuell priorisierter zu betrachten als andere.
Doch Personas können noch weit holistischer als in User Storys verwendet werden. Auf einem höheren Level können sie auch in Customer Journeys verwendet werden. In Customer Journeys wird analysiert, wie bestimmte Personas mit dem Unternehmen in Berührung kommen, um dessen Produkte zu kaufen oder Dienstleistungen in Anspruch zu nehmen. Hier können wertvolle Inputs für das Design der User Experience und in weiterer Folge für die Entwicklung generiert werden. Wie sieht ihre Customer Journey aus? Ist es ein Erlebnis aus einem Guss oder eine beschwerliche Reise mit vielen Hindernissen?

Um den Kreis der Personas nach User Storys und Customer Journeys zu schließen, sollten in weiterer Folge die tatsächlichen Anwender, die die Produkte oder Dienstleistungen verproben, anhand dieser Personas ausgewählt werden. So können die verschiedenen Hypothesen, die auf Basis der Personas erstellt wurden, an realen Beispielen verifiziert werden. Dieser gesamtintegrative Ansatz stellt sicher, dass die Entwicklung zentral am User und dessen Vertreter in Form der Personas ausrichtet ist.
In Zeiten der Digitalisierung wird User Experience zunehmend an Stellenwert gewinnen – gerade in agilen Teams, die an den Innovationen von morgen arbeiten. Bereiten wir dieser Entwicklung den Boden und forcieren wir ein breites User Experience Wissen in unseren Teams, um diesen neuen Anforderungen zu begegnen.

Was bringt Scrum eigentlich dem Fachbereich?

Die Einführung von Scrum verlagert sich immer mehr in die Entwicklungsabteilungen von großen Konzernen. Die Vielzahl unserer Transitionsprojekte zeigt, dass die Scrum-Teams intensiv mit dem Fachbereich als internem Kunden (und oft auch Nutzer) zusammenarbeiten müssen. Da Scrum eine Produktentwicklungsmethode abbildet und somit auf die Kundenzufriedenheit ausgerichtet ist, ist es wichtig, den Fachbereich gut abzuholen und ihn über Scrum zu informieren. Immerhin birgt jegliche Veränderung auch eine Möglichkeit der Verschlechterung in sich und diese Bedenken gilt es aus dem Weg zu räumen. Um die Brücke zwischen Management, Technikern und Produktmanagern zum Fachbereich zu schlagen, habe ich ein paar Aspekte zusammengetragen, die für jeden Fachbereichsmitarbeiter bei der Einführung von Scrum wichtig zu wissen wären.

Als Fachbereichsmitarbeiter finde ich Scrum toll, weil…

Als Fachbereichsmitarbeiter muss ich mich erst an Scrum gewöhnen, weil…

Als Fachbereichsmitarbeiter wird sich meine Zusammenarbeit mit dem Scrum-Team folgendermaßen gestalten…

Diese Liste ist definitiv nicht vollständig und variiert je nach Unternehmenskontext. Dennoch sollte sie einen Ansatzpunkt für eine Schulung des Fachbereichs zum Thema Scrum und agiles Arbeiten bieten. Ich hoffe, diese Aufzählung hilft und freue mich über euer Feedback!

User Stories, eine Übung in Demut

Der Überlieferung nach begegnete der heilige Augustinus bei einem Spaziergang am Strand einem Jungen, der ein Loch in den Sand gebuddelt hatte. Der Junge hielt eine Muschel in der Hand, schöpfte Wasser aus dem Meer, und lief damit zum Loch zurück. Augustinus fragte ihn, was er da tue. Das Kind erwiderte, dass es das gesamte Meer in dieses eine Loch gieße.


Erwachsene, rational denkende Menschen, können eine solche Antwort schwer verdauen. Für den Jungen indes macht die Handlung durchaus Sinn: Die Mengen an Wasser, die er mit seiner Muschel vom Meer in das Loch befördert, sind für ihn symbolische kleine Teile, die für das große Ganze stehen.
 

Zeitsprung 2012

Ein Abteilungsleiter geht in ein neu geformtes Scrum-Team und sieht, wie das Team eifrig Karteikarten mit merkwürdig formulierten Sätzen schreibt. Auf die Frage, was das Team denn da tue, bekommt er als Antwort, es schreibe das gesamte Produkt in Form einsätziger Alsmöchteichdamit-Sätzen auf. Der Abteilungsleiter lacht, schüttelt ungläubig den Kopf, und sagt: „So so, damit verbringt ihr jetzt eure Zeit.“
Bei solchen Reaktionen kommen selbst hoch motivierte Team-Mitglieder ins Zweifeln. Und fragen sich, warum sie plötzlich User Stories schreiben sollen, wenn sie doch eh schon immer wussten, was zu tun war.
 

User Stories sind also vor allem eins: Eine Demutslektion.


Wir gestehen uns ein, dass Produktentwicklung komplex ist, und dass wir im Vorfeld unmöglich allescopyright Gerhard Peyrer wissen können.
 
Wir gestehen uns ein, dass wir gar nicht so genau wissen, wofür der Kunde sein Portemonnaie öffnen wird, und was den Benutzer zum Strahlen bringen wird.
 
Deshalb formulieren wir die Produkteigenschaften nicht als Anforderungen, sondern als Hypothesen über die Bedürfnisse unserer Nutzer. Hypothesen, die es am Ende eines Sprints zu validieren gilt.
 
Deshalb versuchen wir, die Entwicklung in kleine, mehrtätige Arbeitspakete herunterzubrechen, an dessen Ende eine (noch so rudimentäre) Funktionalität steht.
 
Jede einzelne User Story, so klein sie auch sein mag, steht bereits für das große Ganze. Deshalb lohnt es sich, selbst bei reinen Backend-Stories die Frage nach dem Nutzer und den Nutzen zu stellen.
Für wen entwickeln wir eine Funktionalität in letzter Instanz? Sicher nicht für den DB-Admin. Auch nicht für den Kollegen in der Entwicklung oder den Tester. Können wir die Frage nach Nutzer und Nutzen nicht beantworten, dann ist das fast immer ein Zeichen dafür, dass wir uns mit uns selbst beschäftigen und den Sinn unseres Tuns aus den Augen verloren haben.
 
Nachdem Augustinus dem Kind sagt, dass es niemals das gesamte Meer in das Loch gießen werde, antwortet der Junge: „Und so wirst auch du nie das Geheimnis der Dreifaltigkeit ergründen.”

Der Sinn des Dilettantismus in der agilen Produktentwicklungswelt

“Für sinnkonstituierende Systeme hat alles Sinn.“ (N. Luhmann)
Soll heißen: Auch der scheinbare Unsinn besitzt eine sinnstiftende Funktion.
In dem Artikel “Dem Amateur ist nichts zu schwör” aus dem Magazin der Süddeutschen Zeitung (Nummer 24/ 20120615), wird der Scheinwerfer auf die Dilettanten in der Politik, Wirtschaft und Wissenschaft gerichtet und auf das Faktum, dass nervige und zunächst substanzlos wirkende Fragen oftmals zum Nach- und Neudenken bewegen.
Berichtet wird unter anderem über das in New York beheimatete “Genspace”. Dabei handelt es sich um ein Labor, dessen Team aus Künstlern, Programmierern und einem einzigen Biologen besteht, das an zunächst sinnfrei erscheinenden Themen/Produkten forscht/entwickelt. Zum Beispiel möchte man, dass Zellen das tun, was man ihnen befiehlt oder dass Bakterien bei Schwarzlicht bunt leuchten. Zur Vorbereitung bekommen die Laien einen Einführungskurs in Genforschung und dann … werden sie losgelassen.
Es existieren nicht viele Gesetze, best practices, Rituale (auch verhaltensbasiert) dazu, was und wie man “es” tut. Dadurch existieren auch die in der Vergangenheit von den “ausgebildeten Experten” aufgestellten Denkblockaden – oder nennen wir es “creative thinking in a jail” (Kreativität des Denken in einer Gefängniszelle) – nicht. Einen Beweis, dass ein Dilettantenteam etwas Gehaltvolles liefert, ist am Anfang nicht möglich. Es braucht Pioniere mit Mut, Courage und Verstand die es: einfach mal machen.
Naja die Süddeutsche würde aber nur ungern so etwas ohne Bewies veröffentlichen und hat bis heute gewartet, um ihre Leser mit Sicherheit einzulullen:
Vor Zwei Jahren wurde ein Artikel in Nature, dem wichtigsten Wissenschaftsmagazin der Welt, veröffentlicht, dessen Ergebnisse teilweise von Amateuren stammten, die in einer Art Computerspiel die Struktur von Proteinsträngen analysiert hatten.”

Tipps vom Dilettanten?

Ich erlebe in meiner Arbeit häufig Meetings, bei denen vermeintliche Dilettanten Feedback und Verbesserungstipps zu einem hochkomplexen Produkt geben, das soeben von – zumindest für dieses Produkt – gestandenen Professionellen gebaut wurde. Es sind die Reviews, in denen das Scrum-Team auf die User und Stakeholder trifft, um aus dem Meeting Input & Improvements mitzunehmen. Nun erlebe ich im Anschluss der Vorstellung eines ProduktInkrements öfters, wie Wünsche, Fragen, und Feature-Ideen aus dem Dilettantenkreis auftauchen, an die die Entwickler keinen Gedanken “verschwenden” und direkt abwinken: “absurd”, “unmöglich”, “epic lol”…
Warum?
Sie bedienen sich des manifestiert Erlernten, bewegen sich somit in ihrem “creative thinking in a jail”, das genug Gesetze, Rituale, best practices kennt, um diese Ideen lebenslänglich in Einzelhaft zu nehmen. Mit viel Glück bekommt man noch ein “Jaaaa, in 10 Jahren vielleicht…” und sofort darf ich eine Frage stellen: “Was müsste denn bis dahin geschehen?” Das ist eine typische Frage, die in Startup-Unternehmen der Trigger ist, um innovative Produkte mit kreativen Lösungen für die Welt zu finden. Es ist die Freiheit, den Sinn der Gegebenheiten einmal zu ignorieren und seiner Kreativität dabei zu helfen, auszubrechen. Lösungen tatsächlich “out of the box” finden zu müssen.

Dilettanten sind Erneuerer

Die Süddeutsche erinnert an folgende Tatsache: “In der Kulturgeschichte galten Dilettanten lange Zeit als Erneurer.” Es ist nicht einfach, die Sinnfreiheit und den Dilettantismus zu nutzen, aber damit wir bei agiler Produktentwicklung wirklich etwas Neues schaffen, sollten wir es einfach mal machen.
Es war ja auch schon immer sinnfrei Jazz und elektronische Musik zu vereinen. Fragt dazu den ehemaligen Electromusic-Dilettanten Klaus Waldeck.
Es war ja auch schon immer sinnfrei, Klassik und elektronische Musik zu vereinen. Fragt dazu den ehemaligen Klassik-Dilettanten Henrik Schwarz.
Oder hört einfach mal in eure Produkte hinein. Um der Süddeutschen zu huldigen: Die beiden haben sich heute schon bewiesen und ihre Produktionen werden teilweise auf den wichtigsten Labels der Welt veröffentlicht.

Schleppst du noch oder surfst du schon?

Neulich habe ich bei einem großen Einrichtungshaus eine Kommode gekauft. Online. Nach der Bestellung kam eine E-Mail mit der Auftragsbestätigung und dem voraussichtlichen Lieferdatum. Dann habe ich eine Woche lang nichts mehr gehört. Nach acht Tagen (zwei vor dem voraussichtlichen Lieferdatum) lag plötzlich ein Zettel in unserem Briefkasten: Die Sendung konnte leider nicht zugestellt werden. Abholung am nächsten Tag in einer Filiale der Deutschen Post. Dort durfte ich dann das kolossale Paket in Empfang nehmen und den Preis in bar begleichen. Im Webshop selbst gab es keine Bezahlfunktionalität.

Einkaufen kann mühsam sein.

Zunächst waren es nur Bücher und Nischenprodukte, mittlerweile lässt sich (fast) alles über Webshops verkaufen. Der Einzelhandel hat längst verstanden, wie wichtig das Internet als Verkaufsplattform ist. Allerdings machen viele Händler einen entscheidenden Fehler: Sie gehen ins Internet, um dort auch mal vertreten zu sein. Sie sehen im Aufbau eines Webshops ein wertvolles Add-On,eine funktionale Ergänzung zu ihrer bestehenden Verkaufsstrategie, aber kein eigenständiges Produkt.
Dieser Denkfehler kommt nicht von ungefähr. Das Produkt des klassische Einzelhändlers besteht ja darin, das Einkaufen in reellen Räumen zu einem einzigartigen Erlebnis zu machen. Von der Konzeption des Gebäudes über die Einrichtung der Ausstellungsräume bis hin zur Beratung und Nachbetreuung – es gehört so vieles dazu! Ein Webshop ist da ungleich leichter zu bauen. Einen anständigen Katalog, ein funktionierendes Bestellsystem und irgendwie noch die Zahlungsabwicklung. Mehr braucht es doch nicht. Oder?

Einkaufserlebnisse sind auch online möglich.

Marty Cagan hat uns mit Inspired gezeigt, dass und wie großartige Produkte in der Software möglich sind. Für umsonst gibt es die freilich nicht – vielmehr gilt es, gewisse Prinzipien zu beherzigen.
Teste deine Produktideen – möglichst früh und immer wieder – am Kunden! Hol dir einen Produktmanager, der das Produkt, die neuesten technischen Möglichkeiten und den Markt versteht! Und, vor allem: Sieh zu, dass Produktmanagement und Entwicklung Schulter an Schulter arbeiten, damit das richtige Produkt auch richtig gebaut wird!
Wir nennen den Produktmanager Product Owner, weil er letzlich für die Gestaltung des Produkts verantwortlich ist. Der Product Owner bildet zusammen mit seinen Entwicklern, Testern, und weiteren Spezialisten ein Scrum-Team. So ist nicht nur der ständige Austausch gewährleistet, sondern auch die Ausrichtung hin auf ein gemeinsames Ziel: Die Lieferung eines Produkts, das die Kunden lieben werden.
Der Erfolg oder Misserfolg des Produkts zeigt sich dann nicht mehr am Ende, sondern schon während der Produktentwicklung. Am Ende eines jeden, in der Regel zweiwöchigen Sprints, können fertige Funktionalitäten dem Kunden und Benutzer vorgestellt werden.
Welches Feedback hättet ihr gegeben, wenn ihr schon nach drei oder vier Sprints mit einem Prototypen des oben genannten Bestellprozesses zu tun gehabt hättet? Vielleicht hättet ihr euch die Möglichkeit gewünscht, per Bankeinzug oder Rechnung zu bezahlen. Ich bin mir über meine Top-Prio ziemlich sicher: Eine Versandbestätigung mit Liefernummer, damit ich nie wieder am Samstag Morgen mit einem 30 Kilo schweren Paket durch die Stadt ächzen muss!
Marty Cagan: Inspired. How to Create Products Customers Love
 

Was der Berliner Flughafen mit agilen Werten zu tun hat

Die Schlagzeile des heutigen Tages, die Deutschland, Airlines und Passagiere weltweit nervös macht: Die Eröffnung des neuen Berliner Flughafens wird  auf unbestimmte Zeit verschoben. Der 3. Juni als Eröffnungstermin ist Geschichte. Niemand kann sagen, wann der Willy Brandt-Flughafen bereit sein wird, sich den Reisenden zu stellen. Man hört von sechs Wochen Verschiebung. Der Prestige- und Vorzeigebau wird nicht fertig. Deutschland ist (mehr oder weniger) schockiert. Und eine der Fragen, die sich die Medien stellen, lautet: „Warum hat niemand früher gesagt, dass es länger dauert?“ Denn drei Wochen vor Start wird doch schon abzusehen gewesen sein, dass dieses nicht kleine Bauvorhaben nicht fertig wird …
So die momentane Situation – zumindest soweit sie aus der Informationsflut, die uns zu diesem Thema derzeit umspült, nachvollziehbar ist. Aber mal ehrlich: Kennen wir das aus unserem Berufsalltag nicht auch? Projekte die nicht fertig werden? Ampeln, die den aktuellen Projektstand darstellen sollen und die dann doch ausgehebelt werden, wenn das Ende näher rückt?
In vielen Unternehmen reißen Projekt-Deadlines und es muss nachgearbeitet werden. Eigentlich ist es eher die Regel, dass die geplanten Zeiten nicht eingehalten werden. So weit nicht schlimm. Denn wir sind Menschen und können nicht in die Zukunft gucken. Das gilt auch für den Bau des Willy Brandt-Flughafens. Ein Projekt in dieser Größenordnung ist nur schwer zu greifen – irgendwas vergisst man immer …  Um auf Veränderungen schnell reagieren zu können und Gefahren wie eine Nicht-Fertigstellung möglichst früh erkennen zu können, machen wir Scrum. Iterative und überschaubare Zeiten, in denen man genauer planen kann. Ich möchte mich nicht zu weit aus dem Fenster hängen  und sagen: Berlin hätte sein Bauvorhaben mit Scrum machen sollen. Aber ist doch eine spannende Fantasie … erste Ansätze waren mit dem Passagier-Testbetrieb auch schon da.

Offen kommunizieren!

Ich möchte an unsere Offenheit appellieren. In Scrum bemühen wir uns, offen zu kommunizieren.
Wenn es länger dauert, können wir (je länger das Projekt läuft, desto genauer) bestimmen, wann wir fertig sind. Dass das in der Realität oft schwierig ist, will ich nicht verleugnen. Das Team in Berlin, das den Flughafenbau steuert und den Termin nicht geschafft hat: Verständlich, dass es erst drei Wochen vor Start mit der unangenehmen Wahrheit rausrückt, die Situation ist ärgerlich und die Reaktion der Medien und der Öffentlichkeit schwierig. Wir sollten an dieser Stelle nachsichtig sein, uns an der eigenen Nase nehmen und es in Zukunft besser machen. Wenn wir offen kommunizieren, dass wir etwas nicht schaffen, hat das nichts mit Versagen zu tun. Es hat damit zu tun,  dass wir nicht detailliert in die Zukunft sehen können. Dass es jetzt Konsequenzen für den  Flugverkehr hat, ist ärgerlich und kostenintensiv. Nicht jeder von uns setzt gleich einen ganzen Flughafen in den Sand, klar. Aber Verzögerungen und Schwierigkeiten treten nun mal auf. Es sollte nicht passieren, aber es kann passieren – uns allen, in den unterschiedlichsten Größenordnungen.

Wie erstellt man eine Persona?

Letztens habe ich in meinem Blogbeitrag vorgeschlagen, die User-Rolle mit Leben zu füllen, indem man sich tatsächliche Menschen vorstellt, die hinter diesen Rollen stecken. Schaut euch mal die Reportage von ABC über IDEO an. Die zeigt wunderbar, wie das Design-Team herauszufinden versucht, welche Menschen einen Einkaufswagen benutzen und vor allem wie sie diesen Einkaufswagen nutzen. Das Team von IDEO verwendet also offensichtlich das Element der Persona, um sein Produkt den Notwendigkeiten anzupassen.

Natürlich sind die wenigsten Produkt-Entwicklungsteams so aufgebaut wie ein IDEO-Team, aber welche Elemente können wir dennoch nutzen und was können wir von IDEO lernen? Hier meine 10 Tipps:

Lasst die Personas auch an eurem Entwicklungsprozess teilhaben! Sie sollten bei Meetings – dem Sprint Planning 1 und 2, während der Reviews, aber auch bei allen Design-Entscheidungen – mit im Raum sein.
Fragt euch immer: Wie würde die Persona das Feature sehen, das ihr gerade entwickelt bzw. entwickeln lasst?
 

Die User-Rolle ist tot, es lebe die Persona

Die XP-Community hatte vor etwa zehn Jahren die Idee, User Stories zu benutzten, um die Essenz einer Funktionalität aus der Sicht des Anwenders aufzuschreiben.
Zu Erinnerung:
Als User-Rolle
möchte ich eine Funktionalität
so dass ich den folgenden Nutzen habe. [1]
Eine super Idee, die dann von Mike Cohn aufgegriffen und durch sein Buch „User Stories applied“ populär gemacht wurde. Die Idee war so einfach, dass sie die damals gängigen Use Cases als Analysetool sofort überholte. Das Tool ist aber so einfach wie schwierig. Funktionalität aus Anwender-Sicht zu beschreiben, fällt vielen sehr schwer. Noch spannender ist zu beobachten, dass es tausende User Stories gibt, die im folgenden Format formuliert werden:
Als User möchte ich XX
Also wird zum einen einfach aus User-Rolle = User und die Frage nach dem “Wozu” wird oft weggelassen.

Echte Menschen für echte Rollen – die Persona

Heute möchte ich kurz über den User reden. Es ist wichtig zu sehen, dass User-Rolle gemeint war, nicht User. Es geht darum, dass sich der Product Owner und das Team eine echte Anwenderrolle überlegen und mit dieser arbeiten. Das Konzept der User-Rolle ist hier aber offenbar nicht griffig genug. Daher schlage ich vor, das Konzept der User-Rolle aus den User Stories zu streichen und durch das Konzept der Persona zu ersetzen. Personas sind am lebenden Menschen orientierte, imaginierte Personen, die unsere Applikationen, unsere Anwendungen, unsere Produkte benutzen.
Eine noch schönere und ausführlichere Beschreibung einer Persona findet ihr auf dieser Website, zusammen mit der folgenden Beschreibung, was eine Persona ist:
“Personas are archetypal users of an intranet or website that represent the needs of larger groups of users, in terms of their goals and personal characteristics. They act as ‘stand-ins’ for real users and help guide decisions about functionality and design. Personas identify the user motivations, expectations and goals responsible for driving online behaviour, and bring users to life by giving them names, personalities and often a photo.
Although personas are fictitious, they are based on knowledge of real users. Some form of user research is conducted before they are written to ensure they represent end users rather than the opinion of the person writing the personas.“
Wir machen also aus der Rolle Administrator zum Beispiel: Hans Müller, 35 Jahre, IT-Fachmann, lebt in München, fährt morgens mit der U-Bahn zur Arbeit. Er hat zwei Kinder, ist Studienabbrecher und faszinierter Science Fiction Fan. Er liebt es, mit seinen Kinder Lego zu spielen.
Diese Person ist aber erforscht. Das heißt, wir reden mit einigen Admins, finden heraus, wie die wirklich leben, wie sie unsere Applikation tatsächlich nutzen werden. Hat man mit seinem Team diese Personas identifiziert – und davon gibt es natürlich einige, ihr könnt auch mehr als eine Persona pro User-Rolle definieren -, dann kann man anschließend die User-Rolle durch die Persona ersetzen. Auf diese Weise entsteht eine wesentlich lebendigere Vorstellung davon, für wen man die Applikation erzeugt, als durch die User-Rolle. Zumal dann per se klar wird, dass es nicht nur einen User gibt.
Viel Spaß beim Erstellen von Personas!
[1] Boris Gloger: Scrum – Produkte zuverlässig und schnell entwickeln, Hanser, 3. Auflage, 2010