Agile Banking & Customer Experience

Die drei Säulen des Digital Bankings haben Boris und ich in diesem Video bereits angesprochen. Heute will ich mir die Customer Experience genauer ansehen, denn damit punkten Fintechs bei den Kunden: mit schönen, einfachen und intuitiven Benutzeroberflächen. Hier liegt das große Potenzial der Kundenbindung und gerade in diesem Bereich lässt sich mit modernen Produktentwicklungsmethoden viel erreichen. Mehr dazu in diesem Video.

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.

How to get customers on board

Just the other day I was meeting the representatives of a potential new client. As we were discussing their expectations regarding Scrum they brought up a topic that has made me curious for some time now: „Our clients do not understand what we are doing. We need to explain them how to write good requirements according to Scrum and train them on the method.“ First of all, I do not want to talk about expectation management in agile product development and I also do not want to talk about a “you-change-and-I-don’t“-culture. What I would like to talk about is how to get an internal or external client, the management or even regional Key Users aboard this Scrum flight.
I can offer an easy answer: „Do it!“ That is all! Involve your users in the process, deliver continuously, reflect and adapt and use the framework to let them find their role and contribution.
Now here’s the not-so-easy answer: „Do it!“ Of course, customers will not understand why they have to be with the team for a Review meeting every second week when everything is going well anyway. They will not understand why they should take part in a Backlog Refinement session every week, and if the team is really ambitious they also have to attend the Sprint Planning every second week. They will probably not understand why they have to prioritize requirements together with the Product Owner and why they have to let go of some ideas, because in the past they only had to point out the requirements they wanted. And most probably at the beginning, customers both internal and external will not see the benefit of telling the Development Team what they do in their departments every day, how they work and answering questions they do not have the feeling a developer should care about.

Make them an essential part of your daily routine

Here’s the cure: Keep them in the loop. Let them become an essential part of your daily routine. Talk to them. Make them feel valuable for the development process. Listen to them. Understand them. Make them feel what it means to be part of Scrum. And again, that is all! All the concepts you write for communication channels, all the explanations you give on your work and all the trainings that you consider helpful to make them understand are only as good as your daily practices and communication routine with them.
However, you need to explain your why. Why do you do the things you do and why do you mean to change current ways of working relations? If that is clear to you, you can make it clear to them. And then, after some nice talks, maybe two or three joint retrospectives and finally, after the first delivery that meets the expectations in solving their daily problems and in which they can see their ideas growing, they will value the close working relationship and the quick feedback that this framework offers. And soon, they will not leave the plane before take-off anymore.

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!

Die (Über-)Lieferung von Vertrauen

Nahezu jedes Unternehmen hat Erfahrungen mit der Beauftragung von Software-Entwicklungsprojekten und das sind zum Teil schlechte Erfahrungen. Durch solche schlechte Erfahrungen haben über die Zeit immer mehr Organisationen das Vertrauen in ihre Software-Entwicklung verloren. Ich möchte nicht behaupten, dass es nur furchtbare Software-Entwicklungsprojekte gibt. Aber ich behaupte, dass wir hier zu großen Teilen in einer Vertrauenskrise leben. Diese Vertrauenskrise hat nicht nur mit enttäuschten Erwartungen zu tun, sondern auch mit einer veränderten Welt, in der Vertrauen nicht mehr über langfristige Bindungen aufgebaut wird (Vertrautheit), sondern in der Schnelllebigkeit entstehen muss. Wir brauchen also einen anderen Weg, um Vertrauen über mangelnde Vertrautheit zu entwickeln. Kommen wir nochmal zurück zu den Software-Entwicklungsprojekten und verallgemeinern kurz: Umso weniger Vertrauen besteht, desto mehr Kontrolle möchte man ausüben. Vertrauen und Kontrolle versteht man weitläufig als entgegengesetzte Pole, die nicht gleichzeitig existieren können.

Wenn wir das Problem kennen, dann kennen wir doch auch die Lösung?

Vertrauen entsteht nicht über Worte, das wissen wir bestimmt, denn das ist neuronal in unserem Gehirn so verankert. Wir benötigen also Taten, die sich einer schnelllebigen Welt anpassen. Taten, die es ermöglichen, die Erwartungen eines Auftraggebers, eines Kunden und jene von Endnutzern mit dem Beauftragten abzugleichen. Wir als Software-Entwickler brauchen Lieferungen qualitativer, anwendbarer Software in kurzen Zyklen. Mit den Lieferungen zeigen wir, dass wir verstanden haben und liefern können was beauftragt wurde. Wir zeigen, dass wir den impliziten Anspruch auf Qualität halten können. Zudem rücken wir Kunden und Nutzer in den Mittelpunkt, beziehen ihn immer wieder in die Entwicklung ein und geben ihnen eine Stimme. Wichtig dabei ist, dass wir diesen Prozess wiederholen, ritualisieren, oft durchführen, damit wir als Software-Entwickler Verlässlichkeit zeigen können. Wir zeigen, dass es kein Glückstreffer war, sondern dass wir wiederholt qualitative Software  liefern können – wir zeigen professionelles Arbeiten. Im Scrum-Prozess stehen die Lieferung und das Präsentieren der fertigen Funktionen am Ende jedes Sprints, üblicherweise nach 14 Tagen. Am Ende jedes Sprints zeigt das Scrum-Team die lauffähigen Funktionen im Review den Kunden und Nutzern.
Da wir gerade beim Kunden sind, bleiben wir kurz bei ihm. Es wäre fahrlässig, würde der Kunde die Kontrolle aufgeben. Die beauftragte Software ist relevant für die Ergebnisse des eigenen Unternehmens und soll dazu beitragen, die Zukunft des Unternehmens zu sichern. Als Kunden brauchen wir also einen Kontrollmechanismus. Diesen Kontrollmechanismus sollte man nicht an Worten, konkret Verträgen, festmachen, sondern man sollte auch hier wieder auf Taten setzen. Ein wichtiges, wenn nicht gar das Kontrollelement des Kunden sind die Reviews, die er einfordern und aktiv daran teilnehmen sollte. Das Review ist die Fortschrittskontrolle und die Kontrolle des inhaltlich Gelieferten. Zudem ist es die Kontrolle über die Schnelllebigkeit der Märkte, denn wenn Sie als Kunde agil entwickeln lassen, bekommen Sie Kontrolle über Time-to-Market und haben Einfluss auf Änderungen – idealerweise sogar “Change for free“, solange sie auch den Umfang Ihres Produkts/Projekts anpassen. Dafür sollten Sie auch einen Vertrag aufsetzen, der das Ganze widerspiegelt. Auch das ist heutzutage möglich und sogar Wunsch bei vielen Software-Entwicklungen.

Fazit

Liefern wir als Software-Entwickler regelmäßig in kleinen Abständen mit hoher Qualität, so haben wir die Chance, zerstörtes Vertrauen aufzubauen oder dem gewährten Vertrauensvorschuss gerecht zu werden. Nutzen wir Rückkopplungspunkte wie Reviews dazu den Kunden einzubinden, lösen wir sogar das Paradoxon von Vertrauen und Kontrolle zu unserem Vorteil auf. Letztlich gewinnen beide, der Kunde und die Software-Entwicklung. Die Software-Entwicklung vielleicht sogar ein wenig mehr, denn sie hat etwas zurückzugewinnen und das gilt für die gesamte Branche.

Der Kunde ist König, der Product Owner Kaiser

Warum verschwinden Unternehmen vom Markt? Weil sie zu sehr auf ihre Kunden hören. Das ist zumindest die These von Clayton M. Christensen in The Innovator’s Dilemma.
 
Moment mal: Wie kann das sein? Bekommen wir nicht überall gesagt, dass ein zufriedener Kunde das A und O für erfolgreiche Geschäfte ist? Dass man den Kunden gar nicht genug in die Produktentwicklung einbinden kann? Wie passt das zusammen?
 
Christensen hat sich die Geschichte der Festplattenentwicklung angeschaut. Seine These: Festplatten-Herstellern wie Digital, Seagate und IBM hat es nie an Innovationskraft oder Kundennähe gemangelt. Im Gegenteil: Ihre Festplatten wurden von Jahr zu Jahr schneller, günstiger und boten mehr und mehr Speicher. Und das in einem Tempo, das den Bedarf der Kunden zufrieden stellte. Eigentlich lief also alles gut. Doch genau in solchen Erfolgsmomenten, in denen Unternehmen scheinbar alles richtig machen, kann laut Christensen der Anfang vom Ende keimen. Andere Unternehmen kommen mit einer Lösung auf den Markt, die einen Bruch mit allem bisherigen darstellt: Bei den Festplatten war das der Bau kleinerer Festplatten. Das Problem war nicht, dass die Platzhirsche das nicht hätten bauen können – zum Teil hatten sie sogar schon Prototypen auf Lager. Nur: Keiner konnte etwas damit anfangen – am wenigsten der Kunde. Denn die kleineren Festplatten waren nur ein wenig günstiger, dafür hatten sie aber deutlich weniger Speicherplatz und waren notorisch langsamer. Die etablierten Unternehmen bauten die Festplatten für große Mainframe-Rechner – und dort gab es zunächst keinen Bedarf für kleinere Festplatten. Diese fanden dann in Mini-Computern und später (in noch kleinerer Form) in Desktop-Computern und Laptops Verwendungen. Erst nachdem sie sich dort – in einem alternativen, kleinen, heranwachsenden Markt – etabliert hatten, traten sie den Siegeszug an: Die kleinen Festplatten wurden immer leistungsfähiger und verdrängten schließlich den größeren Bruder komplett vom Markt. Zu dem Zeitpunkt war es für die Platzhirschen zu spät, um noch aufzuholen.

Nein!

Kennst du Menschen, die immer versuchen, es ihren Freunden recht zu machen? Die kritische Worte schwer über die Lippen bekommen und ganz selten deutlich “Nein” sagen? Vielleicht sind viele Unternehmen genau so gestrickt. Ein zufriedener Kunde ist schließlich ein zahlender Kunde. Da mag es schwer fallen, den Kunden mal nicht als König zu betrachten und bewusst einen ganz anderen Weg einzuschlagen, der zunächst nur wenige (und andere) Kunden verspricht. Die Hersteller größerer Festplatten bauten für wenige Großkunden und hatten entsprechend hohe Betreuungs- und Verkaufskosten, die wiederum durch Gewinnmargen kompensiert wurden. Bei den kleineren Festplatten sah das Geschäftsmodell ganz anders aus: Billige Komponenten, große Stückzahlen, einfache Verkaufskanäle und geringe Margen. Es ging also nicht nur darum, ein anderes Produkt zu bauen. Es geht vielmehr darum, das eigene Geschäftsmodell in Frage zu stellen.
 
Agile Teams haben bisweilen den Kunden als Product Owner. Das ist praktisch, denn der Kunde kann dem Entwicklungsteam genau sagen, was er will. Und wenn er das bekommt, was er will, dann ist das Unternehmen ja auch erfolgreich. Richtig? Nun ja, genau das haben wir eben exemplarisch in Frage gestellt. Wir haben gesehen, dass ein Kunde heute ganz andere Bedürfnisse haben kann als morgen. Und dass er von seinen zukünftigen Bedürfnisse bisweilen keine Ahnung hat. Aus der Perspektive kann es nicht schaden, wenn ein Product Owner sich eine gewisse Unabhängigkeit vom Kunden bewahrt und einen Schritt weiter denken kann. Nicht aus Arroganz oder Undankbarkeit, sondern aus einer gesunden Dosis Selbstvertrauen. Es ist sicherlich ein Risiko, Produkte zu lancieren, für die es noch keinen etablierten Markt gibt und vielleicht nicht geben wird (wer kann das schon im Voraus beurteilen?). Aber die Alternative – und Christensen zeigt das eindrücklich – kann bisweilen in eine tödliche Sackgasse führen.




Clayton M. Christensen: The Innovator’s Dilemma. The Revolutionary Book that Will Change the Way You Do Business.

… you can't have those people to work on the most important thing!!!

Als ich Steve Denning im Video zu seinem Vortrag “One management idea that beats all others” schon fast etwas ungeduldig knappe 15 Minuten zugehört hatte, wurde ich wieder hellhörig. Er sprach mit der Stimme von Managern, die sagten: “You can’t have those people because they are very important to me, to meet my targets.”
 
Ein déjà-vu! Erst einige Tage zuvor hatte ich mit einer Gruppe von Managern zusammengesessen, und hatte den fast gleichen Wortlaut gehört. Dabei schien zu Beginn des Termins alles noch so einfach …
Um die Integration einzelner Produkte zu einer Gesamtlösung von strategisch besonderer Bedeutung zu verbessern, stellten sich die Manager vor, sie würden mit genau diesem Ziel eine neue Firma gründen. Mit diesem Gedankenexperiment konnten sie die gewohnten organisationalen Rahmenbedingungen kurz ausblenden. Sie konzentrieren sich darauf, was abseits der Abteilungs- und Projektgrenzen am sinnvollsten wäre, um das besagte Ziel zu erreichen. Mir kam es schon fast etwas spanisch vor, wie schnell sich alle einig wurden: Man brauche Teams, die aus Mitarbeitern der unterschiedlichen Abteilungen bestehen. Nur so könne das Wissen der Einzelnen und die Kommunikation miteinander dafür sorgen, dass die Integration der Produkte zu der Gesamtlösung funktionierte.

Was ist aus Kundensicht wichtig?

Doch zu früh gefreut! Die organisationalen Rahmenbedingungen holten uns schneller ein, als gedacht. “Wenn ich jemanden aus meinem Projekt in dem Team arbeiten lasse, dann fehlt mir die Ressource, um mein Projekt erfolgreich weiter zu führen.” So oder so ähnlich klangen die Einwände der Manager, die erst einige Minuten zuvor die Teamlösung als “äußerst sinnvoll”, “benötigt”, “effizient” bis zu “unabdingbar” identifiziert hatten. Mit beidem hatten sie recht.
Vor dem oben zitierten Einwand der Manager stellte Steve Denning den Ansatz der Bürokratie entlang Abteilungen mit “big budgets and big plans” dem mir vertrauten Ansatz zu fragen “What are the most important things in the organization for customers?” entgegen. Er erklärt weiter, dass man aus diesen wichtigsten Sachen DIE wichtigste herausfiltern und dazu die besten Mitarbeiter identifizieren solle, um daran zu arbeiten. Die Mitarbeiter, die dann woanders fehlen würden und ihre Manager daran hindern, ihre Ziele zu erreichen. Und genau das würde man in Kauf nehmen! Denn wendet man dieses Prinzip weiter an, würden ca. 80% statt der vorher ca. 20% der Mitarbeiter an den aus Kundensicht wichtigsten Dingen arbeiten. 
In den nächsten 5 Minuten erklärt Denning dann, wie Scrum funktioniert – ein Must! Doch das Wesentliche war für mich bereits gesagt.
 
Obwohl ich wusste, dass sich mit Scrum Zielkonflikte mit dem bestehenden System ergeben und es ein radikales Umdenken erfordert, brachte es Denning auf den Punkt. Die Manager haben aus ihrer bürokratischen Sicht keinen Vorteil davon,übergeordnet das Richtige zu tun. Erster Schritt muss also sein, dass die Organisation die wichtigsten Dinge aus Kundensicht identifiziert und priorisiert. Im Anschluss an den Termin wollten die Manager genau das einfordern.

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.”

Was stört, ist der Kunde

Viele Produkte, für die man sich einen Vorteil durch die Einführung von Scrum erhofft, sind keine Neuentwicklungen, sondern bereits langjährig bestehende Produkte. Mit hohem Wartungsaufwand, langen Releasezyklen und drängelnden Kunden. Und genau diese drängelnden Kunden machen den Product Ownern, Produktmanagern oder Projektleitern zu schaffen. Die Liste der Kundenwünsche ist so lang und individuell, dass ein Abarbeiten, geschweige denn Zufriedenstellen der Kunden im nächsten Jahrzent unmöglich scheint. Außerdem gehen die Wünsche der Kunden oft derart auseinander, dass es sich kaum unter einer konsistenten Vision oder gar Technologie vereinen lässt.
 
Die Auswirkungen sind bekannt. Der Kunde, der am lautesten mit dem Wechsel zur Konkurrenz droht, kommt mit seinen Feature-Wünschen durch. Wenn nicht beim Product Owner selbst, dann über die Eskalation über das Management. Product Owner und Team werden völlig entmachtet. Der Product Owner wird zum Glaskugelleser, in Bezug auf das, was der Kunde mit seinem vage formulierten Wunsch meinen könnte. Das Team muss ein Feature umsetzen oder gar eine Technologie anwenden, die nicht zum Produkt oder der zugehörigen Strategie passt. Verwirrung, Unverständnis und Demotivation sind die Folge. Team und Product Owner arbeiten gegeneinander.
 

Steht der Kunde Scrum im Weg? 

Das oben beschriebene Problem scheint paradox, denn Scrum plädiert doch immer dafür, den Kunden und End User einzubeziehen. Doch Scrum meint nicht in Form von Product Owner oder gar Team-Verantwortlichkeiten (der Kunde gibt vor, was gemacht wird und wie es implementiert sein muss), sondern als Feedback-Geber (wie viel ist man bereit, für ein vom PO vorgeschlagenes Feature zu zahlen und wie gut funktioniert das Implementierte). Um diese Rolle des Kunden und End Users ausüben zu können, müssen sie jedoch erstmal in die Lage versetzt werden, Feedback geben zu können.
 

Aktion statt Reaktion

Product Owner – legt dem Kunden etwas vor, anstatt ihn zu fragen, was er haben möchte. Fangt im nächsten Release mit ein paar Features an. (Keiner spricht davon, den Kunden komplett zu ignorieren!!!) Stellt euch die Frage: Was braucht das Produkt, damit die Kunden der Konkurrenz zu uns wechseln. Nicht: Was müssen wir tun, damit die Bestandskunden bei uns bleiben? Übernehmt so Stück für Stück Ownerschaft für das Produkt. Motiviert das Team dazu, zuerst im nächsten Release on top ein paar coole Features mit einzubauen – Features, von denen ihr und das Team überzeugt seid, dass sie beim End User ankommen. Überzeugt mit Erfolgen, nicht mit Argumenten! Diese Masche zieht sowohl beim Kunden als auch beim Management!
 

Die Kunst, NEIN zu sagen

Ich bin davon überzeugt, dass man NEIN sagen kann, ohne Kunden direkt zu verärgern oder gar zu verlieren. Allerdings nur unter einer Bedingung: Ich muss etwas Besseres im Angebot haben.
Hat man jahrelang nur auf den Kunden gehört und sich nicht zugetraut, etwas Besseres im Angebot zu haben, wird das wohl kaum über Nacht funktionieren. Denn schließlich ist auch der Kunde an das Vorgehen gewöhnt. Jedoch kann man die Zeit, die man dafür aufwendet zu argumentieren, warum Scrum nicht funktionieren wird, dafür aufwenden sich zu überlegen, wie man es zum Funktionieren bringt!

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.