Von der Projektkultur zur Produktkultur

Ihr seid vielleicht damit beschäftigt, eure Entwicklung effizienter zu machen bzw. eure Produktivität oder Qualität zu steigern. Aber die Frage, wie man richtig, schnell oder gut liefern kann, sollte nicht die einzige Frage sein, die uns bewegt. Zentral ist die Frage, ob wir das Richtige tun, ob wir richtig auf den Kundenbedarf antworten. Mit anderen Worten: Was bedeutet es, eine Produktorganisation zu sein? Wie sieht es mit eurer Produktkultur aus?
Die Einführung von Scrum wird oft von der IT-Abteilung initiiert, der historisch eine typische Haltung als Dienstleister oder Support-Abteilung zukommt. In einer solchen Organisation ist das Produktmanagement im besten Fall eine separate Abteilung (ein weiterer Silo), deren Schwerpunkt u.a. auf Marketing, Innovation oder Business Development liegt. Leider ist diese Abteilung oft sehr weit von der IT entfernt. Im schlimmsten Fall gibt es überhaupt keine Produktmanagementkultur, sondern eine reine Projektmanagementkultur. Die Gründe dafür, warum die Entscheidung auf ein bestimmtes Projekt/eine bestimmte Produktentwicklung fällt, sind nicht transparent bzw. nicht jedem bekannt.
Meistens sind solche Entscheidungen meinungsgetrieben (Kostenanalyse, Vorstandsprojekt, Lenkungsausschuss, etc.) und selten datengetrieben (Marktentwicklung, Kundenbedarf, Wertschöpfung, Outcome, etc.). In Unternehmen mit reifen Portfolios sammeln “Produktmanager” Anforderungen aus dem Verkauf oder dem Kundenmanagement und beschränken sich auf die Aufgabe des Ressourcenmanagements. Die Produktentwicklung wird nach den verfügbaren Ressourcen priorisiert.
Auch die agile Transition wird oft von der IT-Abteilung vorangetrieben – also von einer Abteilung, die von Produktentwicklung keine Ahnung hat, weil sie über Jahrzehnte in die Rolle des Umsetzers und Dienstleisters gedrängt wurde. Deswegen konnten sich auch kaum die nötigen Kompetenzen oder das passende Mindset entwickeln. Zwar kann sich die IT dann darin verbessern, das Produkt richtig zu liefern, aber gleichzeitig weit davon entfernt sein, das Richtige zu liefern. Also wird auch der Unternehmenserfolg nicht in dem Ausmaß vorangetrieben, in dem er vorangetrieben werden könnte.
Wenn eine agile Organisation eine kundenorientierte Organisation ist, dann bedeutet das eigentlich, eine Produktorganisation aufzubauen. Es bedeutet also, eine Produktkultur einzuführen. Es bedeutet, ständig nachvollziehen zu können, ob der Kunde mit den Produkten zufrieden ist, ob neue Produkte vom Kunden angenommen werden und ob das Unternehmen damit Erfolg hat. Der Aufbau der agilen Organisation/die agile Transition sollte daher aus Produktsicht getriggert, gewünscht und geführt werden. Kundenbedarf, Wert für den Kunden, User Experience und Unternehmenserfolg: Das ist letztendlich die Sprache, die gelernt werden muss.
Wenn ich mir meine bisherigen Scrum-Implementierungen durch den Kopf gehen lasse und mir die Wege dieser Unternehmen zur agilen Organisation ansehe, sehe ich immer den Product Owner bzw. die Produktorganisation als wichtigen Knotenpunkt. Die Einbettung der Agile Delivery in eine Produktkultur ist für die Zukunft eines Unternehmens entscheidend:

Daher habe ich eine Bitte: Unterstützt eure Product Owner dabei, echte Produktmanager zu werden! Denkt von Anfang an daran, dass das Produktmanagement kein isolierter Silo sein darf, sondern eine Funktion und sogar ein Mindset sein muss, das alle im Unternehmen betrifft!

Das Review als Nicht-Meeting

Der Sprint ist zu Ende. Das Team legt die Arbeit nieder und geht in das Review. Und schon ist sie wieder da: Die steife Meeting-Atmosphäre, in der die erlegten Stories nacheinander vorgeführt werden, ScrumMaster und Product Owner im Mittelpunkt stehen, und Anwesende ungeduldig auf den Stühlen rutschen. Wenn es ganz schlecht läuft, muss das Team sich auch noch gegenüber Product Owner und Management rechtfertigen, warum etwas so und nicht anders umgesetzt wurde.
Ein gutes Review ist wie eine gute Retrospektive: In dem einen geht es um die Auseinandersetzung mit dem Prozess, in dem anderen um die Auseinandersetzung mit dem Produkt. Alles andere sollte im Review im Hintergrund verschwinden. So ist es für das Review zum Beispiel irrelevant, wie viele Stories das Team geschafft hat. Ebensowenig sollte das Team im Review irgend etwas vorführen müssen, das keinen Nutzer interessiert. Deshalb macht der Product Owner die Abnahme der fertigen Stories bereits im Sprint und nicht erst im Review.
Für ein erfolgreiches, spannendes und wirklich kommunikatives Review kommt es auf die richtige Perspektive an:

Wie gestaltet ihr Eure Reviews? Was hat funktioniert, was nicht?

Die KITA-Bewohner spielen wieder!

Sieben frisch aufgesetzte Scrum-Teams arbeiten derzeit eine klassische Releasebeauftragung eines halben Jahres ab. Mitten im Release ging der Überblick darüber verloren, was tatsächlich schon ausgeliefert worden war, was bereits fertig entwickelt war und auf den Releasewechsel wartete und was noch zu tun war. Jedes Team für sich konnte dazu zwar Auskunft geben, aber die Zuordnung zum Company Backlog war mehr als schwierig aus den elektronischen Tools, aber auch vom Releaseboard abzulesen.
Dort sah man zwar ca. 100 Stories und Epics, allerdings konnte man nicht erkennen, was zu welchem Item aus dem Company Backlog beitrug bzw. ob es überhaupt im Company Backlog auftauchte. Die klassische Beschriftung mit Zahlen brachte uns leider auch kein Stück weiter. Also gingen wir auf Textmarker-Jagd, um möglichst viele unterschiedliche Farben zu ergattern. Als wir mit dem ersten Product Owner anfingen, die Stories aus seinem Backlog den unterschiedlichen Company Backlog Items zuzuordnen, gingen uns aber zu schnell die Farben aus. Was in der Theorie so schön aussieht, war bei uns im aktuellen Release absolute Theorie und hatte nichts mit dem tatsächlichen Releaseboard zu tun.
Nach kurzer Ratlosigkeit kam ein ScrumMaster auf die Idee, nicht nur Farben, sondern zusätzlich Symbole einzuführen. Ich gebe zu, ein Workaround! Wir sind einfach noch nicht bei thematischen Releases.
Aber immerhin half uns dieses Vorgehen zu identifizieren, was im Company Backlog alles fehlte und bei welchem der hoch priorisierten Epics im Backlog die Arbeit noch nicht mal gestartet worden war. Außerdem hatte es den schönen Nebeneffekt, dass sich die POs selbst Symbole und Farben aussuchen durften, mit denen sie ihre Stories kennzeichneten. Ich freue mich schon, wenn wir im Grooming demnächst über das Sonnenepic sprechen 😉
Da die Visualisierung initial einiges an Zeit beanspruchte, bekamen wir von den Büro-Bewohnern in unmittelbarer Umgebung des Releaseplans bei jeder Gelegenheit zu hören: “Ach, die KITA-Bewohner spielen wieder.” Für mich war es toll zu sehen, wie das Arbeiten an den Wänden, auf dem Boden und im Stehen zu sehr viel Interaktion und Aktion führte. Stifte wurden hin und her geworfen, über blöd gemalte Symbole gelacht, sich gegenseitig beim schnellen Ausmalen geholfen…
Meine Hypothese, warum es funktioniert hat? Weil es einfach war und jeder sofort mitmachen konnte!
Und trotzdem: Wir haben zwar jetzt eine Zuordnung der “User Stories” und Aufgaben zu einer übergeordneten Liste. Ein Company Backlog ist das allerdings noch nicht. Ein rhythmisches Liefern erst recht nicht! Es hat aber deutlich gemacht, dass wir etwas ändern müssen, wenn wir anfangen wollen, gemeinsam zu liefern!

Warum überhaupt schätzen?

Schätzen bedeutet für viele Menschen Stress. Wie sollte es auch anders sein? Solange Schätzungen herangezogen werden, um das Fertigstellungsdatum festzulegen, wird es ein abgekartetes Spiel bleiben. Die einen wollen ein tolles Produkt liefern und versuchen daher, durch möglichst großzügige Angaben und dem Einschieben von vielen Pufferzonen ihre Freiheit zu erkaufen. Die anderen wollen den Kunden behalten, haben ihm vielleicht sogar schon Zusagen gemacht, und versuchen daher, die Zeit bis zur Auslieferung maximal zu reduzieren.
Natürlich ist die Spannung beiden Seiten bekannt – und so versucht jeder, das Spiel mit möglichst wenig Kompromissen zu überstehen. Das Spiel kostet üblicherweise viel Zeit und Nerven, und führt letztendlich zu lokalen Optimierungsstrategien: Hier die Strategie, das beste Produkt zu entwickeln. Dort die Strategie, den besten Marktwert für das Produkt zu erzielen. Das Gesamtergebnis muss suboptimal bleiben, weil jede Strategie eigensinning arbeitet, ohne die andere wirklich miteinzubeziehen.
Angesichts dessen haben wir zwei Möglichkeiten: Das Schätzen komplett sein zu lassen und dem Kunden nur noch das zu versprechen, was in den nächsten Iterationen jeweils fertig gestellt werden kann. Vorteil: Der Kunde zahlt für genau das, was er bekommt. Und er kann nach jeder Iteration entscheiden, ob er noch mehr braucht. Dadurch spart er sich den Aufwand und die Schleierhaftigkeit, die mit allen großen Spezifikationskatalogen einhergehen. Nachteil: Nicht jeder Kunde möchte so arbeiten.
Die zweite Möglichkeit besteht darin, das Schätzen komplett umzudeuten. Wir machen das so: Anstatt die Entwicklungsmannschaft nach dem Fertigstellungsdatum zu fragen, lassen wir sie mit dem Product Owner über das Produkt reden. Geht es zum Beispiel darum, ein neues Suchfeld zu implementieren, wird nicht über Aufwand für Entwicklung und Testen gesprochen, sondern um die Funktionalitäten dieses neuen Suchfelds.
Die Entwicklungsmannschaft fragt dann den Product Owner, was dieses Suchfeld leisten soll: Nach welchen Kriterien Anfragen durchgeführt werden sollen, in welcher Reihenfolge und Form die Ergebnisse angezeigt werden sollen, und so weiter. Aus solchen Gesprächen entwickelt sich ein gemeinsames Verständnis für das Produkt. Das Team wird in die Lage versetzt, die noch verbleibende Arbeit nach ihrem funktionalen Umfang zu schätzen.
Und damit ist auch die Brücke zwischen Entwicklung und Markt geschlagen: Der Product Owner, der nach einigen Sprints weiß, wie viel Funktionsumfang sein Team im historischen Durchschnitt pro Sprint liefern kann, kann nun zum Kunden gehen und ihm anhand seines priorisierten Backlogs erklären, welche Funktionalitäten er wann erwarten kann (Kristina Kleßmann hat hier eine anschauliche Beschreibung zum Schätzen nach Funktionalität geschrieben).

Eine große Umstellung

Das Schätzen nach Funktionalität bedeutet für viele eine große Umstellung. Wir alle sind es gewohnt, nach Aufwand zu schätzen. Ein Entwicklungsteam möchte möglichst früh klären, was alles zu tun ist, um eine neue Produkteigenschaft zu implementieren. Zudem wird beim Schätzen nach Funktionalität schnell deutlich, wenn keine Weiterentwicklung stattfindet. Konzeptstories (auch “Spikes” genannt) liefern genau so wenig Produktivität wie technische Aufgaben und solche, die “nur” auf ein Redesign einer bestehenden Funktionalität abzielen. Im “schlimmsten” Falle heißt das dann: Das Team hat über mehrere Sprints keinen funktionalen Mehrwert geliefert. Für viele Teams ist das ein echtes Problem – vor allem dann, wenn das Management sie an ihrer Velocity (also dem Durchsatz an Funktionalitäten pro Sprint misst). Sie schätzen dann lieber nach Aufwand oder Komplexität (oder einer alchemistisch anmutenden Mischung aus beiden), um dem Unternehmen zu zeigen: Schaut her, wir machen unsere Arbeit.
Und so ist es in Scrum häufig wie beim Arztbesuch. Keiner steht gerne im Unterwäsche vor dem Mensch im weißen Kittel, um sich auf Herz und Nieren prüfen zu lassen. Trotzdem ist es wichtig, sich ab und an die Blöße zu geben. Zu erkennen, dass es hier und da nicht so gut läuft. Dass kein Kunde der Welt wirklich bereit ist, für Konzepte oder Generalüberholungen zu zahlen. Dass ein Unternehmen es nicht mehr schafft, seine Produkte weiter zu entwickeln, sondern an Bestehendem herumdoktert.
Entscheidend ist dabei, wie ein Unternehmen mit dieser Erkenntnis umgeht. Wie geht es Mitarbeitern, die solche Defizite offen ansprechen? Werden sie ernstgenommen und anerkannt, oder eher sachte beiseite geschoben und am Ende des Tages ignoriert? Und selbst wenn es ein Problembewusstsein gibt: Führt das im Unternehmen zu Hilflosigkeit und Frustration oder raufen sich alle zusammen, um einen Schlachtplan zu entwerfen? Teams spüren sehr genau, wie ihr Unternehmen tickt, welche “Persönlichkeit” es hat. In einem Unternehmen, das am liebsten gut dastehen möchte, wird die Offenheit, die mit dem Schätzen nach Produktivität einhergeht, keine guten Chancen haben. Das heißt aber nicht, dass die Methode die falsche ist. Es zeigt nur, dass sie nicht zum Selbstverständnis des Unternehmens passt.
Siehe auch: Martin Fowler: Purpose of Estimation

Gedanken eines frisch gebackenen Product Owners

Wahrscheinlich ist es meine Verantwortung für den ROI, die mich immer wieder dazu verleitet, die Priorisierung einzig und allein vom Wert der User Story in Euro und Cent, also dem originären Business Value ableiten zu wollen. Doch der Versuch, einen absoluten Wert hinter die Story zu schreiben, den der Kunde im Endeffekt sicher bezahlen wird, lässt mir eher graue Haare wachsen als ein priorisiertes Backlog gedeihen.
Denn machen wir uns doch nichts vor: Das, was ich hier im Backlog formuliere, sind Hypothesen. Wenn der Kunde noch nichtmal weiß, dass er das bald unbedingt haben will, weiß er doch auch heute noch nicht, wie viel er dafür zu bezahlen bereit sein wird. Ok, das Risiko bleibt also mal wieder an mir hängen. Ich muss mir sicher sein, dass meine Hypothese so gut ist, dass es sich lohnt, die Jungs und Mädels ein paar Tage dran zu setzen.
Auf der anderen Seite: Zu den Zeiten, in denen mir der Kunde vorgegeben hat, was er als Nächstes haben möchte und auch gleichzeitig den Preis mitgeliefert hat, möchte ich auch nicht zurück. Ok, also erstmal keine Euros … aber wie komme ich dann zu meiner Priorisierung? Irgendjemand hat mir mal gesagt, dass Scrum viel mit Menschenverstand zu tun hat … also …
Bauchgefühl? 
Hm, hat zwar weniger mit Verstand zu tun, aber dafür habe ich davon eine ganze Menge 🙂 Aber reicht das? Ich hätte da lieber was, mit dem ich die Komplexität zumindest scheinbar etwas greifbarer machen kann.
Was könnte greifbarer sein als die gute alte Deadline? Verliert ein Feature seinen Wert oder wird er erheblich verringert, wenn ich es erst nach der bestimmten Deadline auf den Markt bringe? Oder schlimmer noch: Muss ich vielleicht sogar mit einer Strafe rechnen, wenn ich das Feature nicht rechtzeitig zur Verfügung stelle? Klingt nach zwei guten Kategorien.
Wen muss ich denn mit dem Produkt beglücken? Gibt es Stakeholder, die ich vorrangig zufrieden stellen muss und oder kann ich einzelne Stories bestimmten Themen zuordnen, die als Gesamtpaket unterschiedlich wertvoll oder wichtig für das Produkt sind?
Da wir mit Scrum auch endlich mal unsere Systeme in den Griff bekommen wollen, könnte ich mir natürlich auch genau die Stories raussuchen, die die meisten Systeme gleichzeitig anfassen. Oder die Stories, die sich erstmal mit dem zentralen Sorgenkind beschäftigen. So können wir möglichst schnell identifizieren, wo die größten Probleme liegen. Apropos Probleme – was ist eigentlich mit Risiken? Könnte in die Kategorie Systemarchitektur fallen, aber auch der auslaufende Vertrag mit dem Zulieferer könnte zu einem Risiko werden, wenn wir noch vorher die entsprechende Unabhängigkeit der Daten sicherstellen.
Da fällt mir die Kooperation mit der Uni ein. Die haben bestimmte Vorlaufzeiten, damit sie die Studenten auftreiben können.
Puh, was könnte noch eine Rolle spielen?
Naja, wir hatten uns ja bei der Ausrichtung des Produktes damals so viele Gedanken gemacht, was es eigentlich für die Firma bringen soll. Vielleicht kann ich bewerten, wie gut das Feature dieses Ziel unterstützt? Falls mir das noch nicht reicht, könnte ich eine Kombination mit Methoden wie z. B. MuSCoW oder Kano versuchen:
MuSCoW: Must – Should – Could – Won’t
Kano: Basis-, Leistungs-, Begeisterungs- und Zurückweisungs-Merkmale!  
Ok, bevor ich das alles ausprobiere, erstmal zum PO Weekly. Immerhin gibt es auch noch die Abhängigkeiten zu den anderen Teams, die Einfluss auf meine Prio nehmen könnten. Und jetzt, wo wir so viele neue Scrum-Teams haben, könnten wir doch eigentlich eine übergreifende Priorisierung vornehmen und dabei die gleichen Kriterien anwenden. Mal sehen wie die anderen es machen – bekanntlich ist es ja einfacher, wenn man ab und zu die Köpfe im Team zusammensteckt.
Wir könnten im PO Team einfach mal aufschreiben, wer wie priorisiert und sehen, wo die Gemeinsamkeiten und Unterschiede sind und welchen Nutzen die einzelnen Aspekte für den jeweiligen PO haben. Macht es Sinn, dass wir die gleichen Kriterien anwenden und was verstehen wir eigentlich genau darunter? Und wahrscheinlich hat mein ScrumMaster auch noch ein paar Ideen und kann mir bei der Fülle der Möglichkeiten für die Priorisierung helfen … Aber wahrscheinlich wird er am Ende wieder sagen: “Triff einfach eine Entscheidung!” Product Owner sein heißt Entscheidungen treffen, und die trifft man per Definition unter Unsicherheit! Man muss es trotzdem tun und vor allem dazu stehen.

Am Ende eines langen Tages

Kennt ihr ihn auch? Den ausgepowerten Product Owner, der vor lauter Terminen seinen Tag doppelt bis dreifach verplant hat? Oder den eifrigen ScrumMaster, der noch abends im leeren Teamraum sitzt und die Retro für den nächsten Tag akribisch vorbereitet? Manche sagen dann: “Das kann nicht gut sein.” Und zitieren das Agile Manifest, das von “nachhaltiger Entwicklung” und von einem “gleichmäßigen Tempo” erzählt, das “auf unbegrenzte Zeit” haltbar sein soll. Häufig geistert dann noch dieses eine Wort herum: Burnout.
Ja, der gute Product Owner hat eine ganze Menge zu tun: Er soll möglichst nah an seinem Team sein, mit dem Kunden im ständigen Kontakt stehen, und darüber hinaus die gestalterische Gewalt über das Produkt haben. Für manchen klassischen Projektleiter bedeutet das ein deutliches Mehr an Aufgaben und an Verantwortung. Auch der ScrumMaster ist, wenn er für sein Team da sein und Scrum in die Organisation tragen soll, gut ausgelastet.
Am Ende eines langen Tages stellt sich dann der Frust über die vielen Stunden ein, die man wieder mit Meetings und Abstimmungen verbracht hat. Spannenderweise beziehen sich die Klagen, die mir zu Ohren kommen, fast immer auf die Quantität. Dabei scheint es eine fest verankerte Vorstellung von “Normalität” zu geben: Der Achtstundentag gilt als das gesunde Maß aller Dinge. Neun Stunden werden noch toleriert, zehn gelten vielerorts schon als grenzwertig – und bei allem, was darüber liegt, erntet man besorgte Blicke und gilt als ernstzunehmender Burnout-Kandidat.
Tomas Chamorro-Premuzic hat im Harvard Business Review einen wunderbar provokanten Text geschrieben, der genau diese Korrelation zwischen Dauer und Last in Frage stellt. Seine Behauptung: Überarbeitung ist nur dann möglich, wenn du keinen Spaß bei der Arbeit hast (http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html):
“Work is just like a relationship: Spending one week on a job you hate is as dreadful as spending a week with a person you don’t like. But when you find the right job, or the right person, no amount of time is enough. Do what you love and you will love what you do, which will also make you love working harder and longer. And if you don’t love what you are doing right now, you should try something else — it is never too late for a career change.”
Nehmen wir das Zitat ernst, sollten wir am Ende eines langen Tages Rückschau halten und für uns prüfen: Was habe ich heute alles gemacht? Was davon hat mir Spaß gemacht, was hat mich herausgefordert, wo ist die Zeit schnell vergangen? Und wo habe ich mich herumgequält, wo war es einfach nur mühsam und frustrierend? Am Ende eines ganztägigen Trainings bin ich manchmal so kaputt, dass ich kaum noch aufräumen und packen kann. Und trotzdem schwebe ich einen halben Zentimeter über dem Boden, halb euphorisiert und halb benommen von den vielen Eindrücken und Erlebnissen des Tages. Die Belastung eines solchen Tages ist enorm, aber sie macht mich nicht fertig. Es ist dann wie ein langer, langer Lauf, an dessen Ende man glücklich auf dem Rasen sitzt und keuchend grinst.
Wenn wir mit Scrum erreichen möchten, dass Menschen anders miteinander arbeiten und daran wachsen, dann können wir nicht einfach weitermachen. Wir müssen uns vielmehr überlegen, was von der bisherigen Arbeitsweise noch Sinn macht, und was komplett gestrichen werden muss.
Drei Vorschläge:

Tomas Chamorro-Premuzic: Embrace Work-Life Imbalance. HBR Blog Network. http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html
Principles behind the Agile Manifesto: http://agilemanifesto.org/principles.html

Warnhinweis: Produkte entstehen nicht von selbst

Wozu Scrum? Die Antwort auf diese Frage variiert von Unternehmen zu Unternehmen – und dennoch geht es meistens um schnellere Auslieferungen, bessere Qualität, stärkere Kundeneinbindung, zufriedene Mitarbeiter.
 
All das ist wichtig und gut, doch beantwortet es nicht die Frage nach dem Wozu. Denn ich kann großartigen Code schreiben, alle zwei Wochen releasen, meine Kunden ständig dabeihaben und immer noch nicht wissen, welchen Zweck ich damit verfolge. Solange die Geschäftszahlen stimmen, mag das nicht weiter schlimm erscheinen. Gewinn ist ein täuschend echter Unternehmenszweck.
 
Verändern sich aber die Marktbedingungen (und das ist heute eher die Regel als die Ausnahme), ist die eigene Ausrichtung zu überprüfen: Ist das, was sich bisher blendend verkauft hat, auch heute noch das Richtige? Und spätestens da stellt sich die Frage nach dem Wozu. Um sie zu beantworten, muss ich erstmal verstehen, wie mein Produkt aussehen könnte und was es zum Produkt macht. Wir haben dafür eine eigene Rolle in Scrum: Den Product Owner. Ohne die Frage nach dem “Wozu” wären Product Owner überflüssig: Die Entwicklungsteams könnten direkt mit Kunden und Benutzer sprechen, seine Anforderungen aufnehmen und dann umsetzen.

Was ist das denn: ein Produkt?

Laut Wikipedia ist es das Ergebnis eines vom Menschen bewirkten Transformationsprozesses, in dem Produktionsfaktoren wie Güter und Dienstleistungen in einen Output umgewandelt werden. Das ist sicher nicht falsch, aber es zieht am Wesentlichen vorbei.
 
Ein Produkt ist für mich so etwas wie ein Leuchtturm in der Beziehung des Menschen zu seiner Umwelt. Ein Anker, eine feste Referenz, die unser Leben besser, schöner, einfacher, anspruchsvoller macht.
Ein Kunstwerk, ein Schlüssel, ein Zug, ein Studium, ein Hut, eine Tasse Kaffee. Das alles sind Produkte – feste Bestandteile des menschlichen Lebens, milliardenfach produziert und in Anspruch genommen, weil sie nützlich sind.
Ein gutes Produkt fügt sich ungezwungen in die Interaktion zwischen Mensch und Umwelt. Es wird nicht als Last oder Hindernis, sondern als Stärkung empfunden. Als etwas, das man gerne in die Hand nimmt, trägt, bedient, in Anspruch nimmt.
 
In der Softwareentwicklung fällt der Bau guter Produkte nicht leicht. Mit Software lässt sich sehr viel sehr schnell bauen. Diese Fülle an Möglichkeiten, die ja die Kraft von Software ausmacht, ist zugleich ihre Achillesferse. Benutzer wollen einfache, intuitiv bedienbare, gut aussehende und zugleich leistungsstarke Software. Zu oft fühlen sie sich jedoch überfordert und frustriert, haben eine vorbelastete Beziehung zu Software und würden am liebsten ohne sie auskommen, wenn sie die Wahl hätten. Da sie diese Wahl nicht haben, werden sie bisweilen stiefmütterlich behandelt. Es sollte niemanden verwundern, wenn die gleichen Benutzer bei der erstbesten Gelegenheit dem Konkurrenten in die Arme laufen und dem alten Produkt keine Träne nachweinen.
 
An welchem Produkt arbeitest du mit? Was macht es stark? Wie beeinflusst es die Interaktion zwischen Mensch und Umwelt? Wer sind diese Menschen? Die Antwort auf diese Fragen nennen wir Produktvision. Es lohnt sich, Zeit dafür zu investieren. Denn nur die Produktvision kann die Frage nach dem Wozu beantworten. Software wird nicht entwickelt, um fehlerlos zu laufen. Oder um möglichst viel Abfragen in möglichst geringer Zeit zu bearbeiten. Sie ist da, um Spuren im Alltag der Menschen zu hinterlassen. Du kannst bei dem, was du entwickelst, beim besten Willen keine Produkteigenschaften feststellen? Dann versuche es mit folgenden Fragen:

  • Wer sind deine Kunden? Was haben sie davon, dass es euch gibt?
  • Welcher Bedarf deines Kunden wird durch euer Produkt erfüllt?
  • Welche sind die vier bis fünf kritischen Funktionalitäten, die den Erfolg des Produktes ausmachen?
  • Wie wird das Unternehmen vom Produkt profitieren?

Nimm dir zum Schluss noch zehn Minuten, um deine Erkenntnisse in einen “Elevator Pitch” zusammenzufassen – einem Statement, das so knapp und prägnant ist, dass während einer Fahrt im Aufzug die Vision kommuniziert werden kann.
 
Unsere Produktvision bei bor!sgloger lautet übrigens wie folgt: Nach ihrem Arbeitstag sollen unsere Kunden nach Hause gehen und dorthin die Energie und Zufriedenheit mitnehmen, um mit ihren Kindern zu spielen.

Der Sprint – ein Zeitplan für Macher

Wer beim Sprinten ins Stolpern kommt, wird meist von etwas abgelenkt. Das gilt zumindest in den Sprints, die im Büro stattfinden. Den Sprint in Scrum gibt es aus vielen Gründen: Er dient der Synchronisation, stellt eine Grenze gegen Überlast dar (WIP-Limit) und sorgt für störungsfreies Arbeiten.

Synchronisation

Der Sprint dient der Synchronisation für die Priorisierung und Lieferung. Hierbei besteht die gleiche Kadenz für Priorisierung und Lieferung. Die gleiche Kadenz heißt, es wird zu Anfang des Sprints festgelegt, was in die freien Slots kommt, die im nächsten Sprint frei sind und es wird festgelegt, wann das Scrum-Team die nächsten Ergebnisse liefert. Sobald man in Scrum das Sprinten startet, legt man den Rahmen, die Kadenz automatisch fest. Man legt Synchronisationspunkte fest und die damit verbundenen Transaktionskosten.
Die Transaktionskosten der Koordination minimiert man bei einer regelmäßigen Priorisierung. Es ist klar, wann wer zusammenkommen muss und jeder kennt den Rhythmus.
Transaktionskosten für die Lieferung hängen von mehreren Faktoren ab: Wie aufwendig sind Koordination und Integration, wie hoch ist der Grad der Automatisierung und wie schnell kann, wie schnell muss man Geschäftswert für den Endnutzer bereitstellen.
Die Automatisierung hat heutzutage noch viel mit Professionalisierung der Software-Entwicklung zu tun. Unternehmen, bei denen bisher wenig automatisiert ist, haben meist hohe Transaktionskosten. Solche Kosten sind oftmals auf manuelle Qualitätssicherung und hohe Koordinationskosten für Integration und Releases zurückzuführen. Meist führen gerade solche langen Lieferzeiten jedoch zu einem Teufelskreis: Da die Transaktionskosten hoch sind, meiden Unternehmen kurze Zyklen. Lange Zyklen beinhalten immer ein höheres Risiko an Fehlern. Kombiniert man nun lange Zyklen mit der Angst vor Fehlern in der Praxis, stellen sich nochmals höhere Transaktionskosten durch ausgeprägte Testphasen ein. Da man zum einen mehr testet, zum anderen fehlerhafte Funktionen länger in der Praxis hat, verlängert sich der Zeitraum des fehlenden Geschäftswerts. Derweil sitzt der Kunde noch mit Praxisfehlern auf der langen Bank. Wartet der Kunde auf der Bank, dann führt das häufig zu Mitnahmeeffekten durch Wettbewerber.

WIP-Limit

“Limit work in progress” – so richtig wichtig, leider oft so richtig wenig verstanden. Überlast in Unternehmen führt nicht nur dazu, dass alles lange dauert und keiner mehr Lust hat. Es führt vor allem dazu, dass fast nichts mehr geht. Menschen betankt man nicht wie Maschinen, die dann bis auf eine gewisse Grundwartung mit einer geringen Fehlerquote arbeiten. Wann geht fast nichts mehr? Wenn alles aufeinander wartet und gemeinsame Synchronisationspunkte zu selten oder unkoordiniert stattfinden. Dann ergeben sich Abhängigkeiten, die nur noch so ungefähr aus der Vogelperspektive erfasst werden können. Wenn die Vogelperspektive hier helfen würde, dann wäre das schön, meiner Erfahrung nach zählen allerdings vor allem die Details.
Im Sprint limitiert das Entwicklungsteam die eigene Auslastung. Das Entwicklungsteam zieht sich die eigene Auslastung, manchmal auch die eigene Überlastung. Dadurch entsteht für den Zeitraum des Sprints ein limitiertes System, ähnlich einem Währungssystem, es entsteht eine Knappheit. Mit dieser Knappheit kann man arbeiten. Indem ich ausweise, dass im nächsten Zeitraum nicht mehr geht, zeige ich deutlich auf, was geliefert wird. Meine Lieferung rückt in den Fokus.
Des Weiteren kann bei Blockaden nicht auf etwas weniger Wichtiges ausgewichen werden, sondern es muss genau an dem gearbeitet werden, was wichtig ist. Trifft man auf Blockaden, so sind sie zu lösen. Ist das System nicht limitiert, so wäre die natürliche Reaktion, sich mit etwas anderem zu beschäftigten. Das führt in vielen Organisationen dazu, dass Blockaden selten oder nie gelöst werden und man sich mit ihnen abfindet. In einem knappen System geht das nicht. Es muss etwas getan werden, der Fokus auf den Wert bleibt erhalten und man reduziert deutlich die Parallelität und damit den Auslöser für das heutzutage vielmals gescheiterte Multiprojektmanagement.
Wichtig ist, die so erzeugte Knappheit im System aufrechtzuerhalten: Wird das System ständig gestört z. B. durch Incidents, dann werden schnell die Vorteile eines solchen Systems obsolet (stabile Transaktionskosten für Priorisierung, Lieferung, konsequentes Auflösen von Hindernissen, etc.).

Störungsfreies Arbeiten

Wer kennt es nicht: Manager hetzen stundenweise von Termin zu Termin. Stimmen sich ab, tauschen sich aus und tragen all die neuen Erkenntnisse überall dorthin, wo sie aktuell noch gar nicht sein müssten – ins Entwicklungsteam. Auf der anderen Seite sitzen im Entwicklungsteam Menschen, die Zeit benötigen, sich in ihre Arbeit zu vertiefen.
Ich beschreibe Software-Entwicklung meist so: Du sitzt da vor deinem PC und über dir schwebt ein stetig wachsendes Konstrukt von Beziehungen, Abläufen und Strukturen. Es ist wie ein kleines Wolkenschloss, dass mit jeder Zeile Code, die du liest, wächst. Immer mehr Gedankenblasen steigen vor dir auf bis dann… ja dann klingelt das Telefon, es kommt jemand herein, spricht dich an und du siehst weit am Horizont die letzte Gedankenblase zerplatzen und dein Wolkenschloss ist vom Winde verweht. Um ein solches Konstrukt zu erzeugen benötigt es Zeit, es ist aufwendig und anstrengend.
Wenn wir die Zeitpläne eines Managers mit dem eines Entwicklungsteams vergleichen, dann sehen wir kleine Zeiteinheiten über den Tag verteilt beim Manager und große Zeiteinheiten beim Entwickler. Jetzt würde manch einer sagen, dass es jede Menge Entwickler gibt, die auch einen zerstückelten Zeitplan mit sich herumtragen. Hier stelle ich die Frage: “Wie viel wird von demjenigen dann noch entwickelt und wie viel managt er schon?”
Paul Graham nannte 2009 die unterschiedlichen Zeitpläne “Maker’s schedule, manager’s schedule“. Er bringt dort zum Ausdruck, dass diese beiden Zeitpläne konträr zueinander stehen und so wenig wie möglich aufeinandertreffen sollten, damit die Produktivität der Macher (Entwickler) möglichst wenig beeinträchtigt wird. Im Umkehrschluss schlägt er vor, dass beide Zeitpläne voneinander entkoppelt werden sollten. Spannenderweise findet dieses Prinzip sich im Agilen im Allgemeinen und bei Scrum im Speziellen wieder. In Scrum entkoppeln die Sprints die beiden unterschiedlichen Zeitpläne voneinander. Im Sprint sorgt der ScrumMaster für störungsfreies Arbeiten und gibt seinem Entwicklungsteam den Freiraum und die Zeit, möglichst autonom und produktiv zu arbeiten. Zum anderen entkoppeln die Rollen Product Owner und ScrumMaster die Zeitpläne. Das geschieht dadurch, dass beide für das Scrum-Team zwischen den Zeitplänen vermitteln, indem sie selbst als Puffer und Filter agieren. Ein weiterer Vorteil ist, dass sich das Entwicklungsteam gegenüber Störungen ausgehend von den beiden Rollen auch durchsetzen kann, da weder ScrumMaster noch Product Owner disziplinarische Vorgesetzte des Teams sind.

Zieleinlauf

Der Sprint isoliert die hektische Welt des Managements vom Zeitplan eines Entwicklers. Entwickler können sich so fokussieren und gedankenintensive Arbeit leichter abschließen. Der Sprint fördert stabile Bedingungen, die zu niedrigeren und stabilen Transaktionskosten führen und ermöglicht Professionalisierung aufgrund von kleinen Lieferungen. Als knappes System führt der Sprint dazu, dass Blockaden gelöst werden müssen und zukünftig nicht auch anderen Arbeiten im Weg stehen. “Wenn Sie mich fragen: Ich mag ihn, den Sprint!”

Sie können abschalten, wir haben die Vision

Was sagt die Hirnforschung zum Nutzen von (Produkt-)Visionen? Ich bin daran höchst interessiert, aber ich weiß es nicht. Was ich allerdings weiß, ist Folgendes:
In der Hirnforschung gibt es einen Bereich, der sich mit Improvisation beschäftigt. Improvisation ist ein kreativer Prozess, Jazz ist dafür ein gutes Beispiel. Wir wissen, dieser Musikstil lebt von Improvisation. Misst man die Gehirnaktivität bei der Improvisation, dann stellt man etwas Spannendes fest: Entgegen der ersten Annahme, dass ein Feuerwerk der Aktivität im Hirn veranstaltet wird, schaltet das Hirn bestimmte Teile stark ab. Klar sind die Teile des Hirns, die für das Hören zuständig sind, sehr aktiv. Aber der frontale Teil des Hirns  (Frontallappen) schaltet sich bewusst weitgehend ab. Genauer gesagt schaltet sich der planerische Teil des Hirns ab – also der Teil, der weiß, was als Nächstes getan wird, der den Schritt nach dem Schritt kennt. Aktiv bleibt allerdings der Teil, der sich den langfristigen Zielen oder Rahmen widmet. Im Jazz wären das dann die kulturellen Grenzen der jeweiligen Zeit (Zeitgeist) und die damit verbundenen Muster.

Zu welcher Schlussfolgerung bringt mich das?

Wenn wir davon ausgehen müssen, dass wir für kreatives Handeln wie bspw. Improvisation sowohl 1.) einen Rahmen zur Orientierung brauchen und wenn 2.) kreative Prozesse planerisches Handeln ausschalten, dann bringt mich das zu Folgendem:
Planen und kreatives Handeln stehen für unser Hirn im Konflikt. Immer wenn wir Neues erschaffen, benötigen wir einen Rahmen, eine Orientierung, eine Marschrichtung, eine langfristig angelegte Mission oder Vision. An dieser Vision richten wir uns aus und im Rahmen der Orientierung können wir kreativ handeln. Den zu genauen Plan schiebt unser Hirn beiseite (sobald wir etwas Neues erschaffen müssen). Der Plan im Vorfeld ist nicht wichtig und kann nicht beachtet werden. Ausgehend von einem sehr groben Zielbild, einer Vision, die als Rahmen dient, orientiert sich unser Hirn an langfristigen Zielen. Diese Ziele müssen bekannt sein und grob vorliegen. In der Agilität schaffen wir eine Vision, arbeiten mit User Stories und in Scrum mit Sprint Goals. Alle drei Artefakte folgen dem groben Rahmen und vermeiden das detailreiche Planen. Könnte unser Hirn die Grundlage für den Erfolg dieser Artefakte sein?
Ob ich damit richtig liege, ich weiß es nicht. Ist es wichtig? Ich denke, nein. Wichtig ist jedoch zu wissen, dass Kreativität viel mit Kontrolle des Hirns über das Abschalten von Hirnaktivität zu tun hat und dass zuviel Detailplanung in kreativen Prozessen teilweise nicht berücksichtigt wird und unnötig ist – zumindest dann, wenn wir einen erneuten kreativen Prozess starten. Vielleicht noch ein belehrender Hinweis zum Schluss: Immer wenn wir neue Anforderungen für unser Produkt angehen, immer dann, wenn wir Software in Schale gießen, dann starten wir einen solchen kreativen Prozess.
Bevor Sie jetzt abschalten, noch eine Frage: “Wie ordnen sich meine obigen Gedanken zu ‘Front-Up-Design’ und zu ‘Emergent-Design’ ein?”

Wie viel bin ich wert? Die Geschichte einer User Story

Am Anfang war das Nichts und es war dunkel. Und mit einem Mal blitzte es kurz auf, es ward Licht im Geiste und ich entstand als eine assoziierte Idee. Und meine Erzeugerin sprach: „Ja, jetzt hab ich‘s“ und schuf mich auf einer kleinen, weißen Welt. Ich glaube, meine Welt war eine Scheibe. Jedenfalls war sie äußerst flach. Im Laufe der Zeit veränderte mich meine Erzeugerin noch an der einen und anderen Stelle. Teile von mir wurden durchgestrichen, Teile von mir wuchsen neu aus mir heraus.
 
Meine Erzeugerin war stolz auf mich und zeigte mich den anderen Göttern. Diese begannen sofort, über mich zu sprechen, meine Sinnhaftigkeit zu hinterfragen. Wie groß und komplex ich sei. Und dass ich in meiner jetzigen Form gar nicht umzusetzen sei. Zu aufgebläht sei ich und viel zu viele Abhängigkeiten hätte ich an mir haften. Die anderen Götter wollten mich halbieren und in kleine Stücke zerschneiden, denn ich sei eine Dreizehn!
 

Meine Erzeugerin gebot Einhalt und sprach:
„Nur im Ganzen kann ich sie brauchen. In kleinen Teilen nützt sie mir nichts!”

 
Die Götter aber ermahnten meine Erzeugerin und sprachen: „Dann sag uns, wie wertvoll sie für dich ist!“
Meine Erzeugerin antwortete beschämt: „Das kann ich nicht. Ich weiß nicht, wie viel sie wert ist. Aber sie ist wichtig, wir müssen sie umsetzen.“
 
Die Götter aber riefen voller Zorn: „Alles, was du uns bringt, ist wichtig und muss umgesetzt werden! Nenne uns ihren Wert, sonst werden wir sie in kleine Stücke hacken und einzeln umsetzen!“
Meine Erzeugerin nahm mich mit zu ihren Brüdern und Schwestern und fragte diese nach meinem Wert. Die anderen Erzeuger aber sprachen: „Wir wissen nichts über ihren Wert. Alles, was wir erzeugen, ist wichtig und dringend und muss umgesetzt werden.“
 
So wurde ich schließlich in einen Stapel gesteckt und zwischen anderen Welten meiner Art eingequetscht. Ich verlor das Bewusstsein kurz nachdem ich die Götter sagen hörte, ich sei wohl doch eher eine Vierzig. Als ich nach langer Zeit wieder erwachte, fand ich mich selbst wieder – gewandelt in eine Funktionalität. Seit langer Zeit warte ich nun darauf, dass ich endlich von jemandem benötigt und ausgeführt werde. Ich gebe die Hoffnung nicht auf, schließlich war ich doch so wichtig …
 
 
Die Moral dieser Geschichte ist ganz einfach. Product Owner dieser Welt, denkt über Business Value nach und gebt Euren User Stories einen ernsthaften, echten Wert mit auf den Weg!
 
Stories mit Business Value werden Euch helfen, Euer Backlog in eine priorisierte Ordnung zu bringen. Und sie werden die Kommunikation zwischen dem Team und Euch auf eine neue, ganz andere Ebene heben!
Das mag vielversprechend und beinahe zu schön klingen. Auf die Spitze getrieben möchte ich es folgendermaßen formulieren: Macht Euch und Eurem Team ein schönes und bequemes Leben, denn ohne Business Value habt Ihr die völlige Freiheit, tun und lassen zu können, was Ihr gerade gerne möchtet.
 
“Ich mache mir immer wieder Vorwürfe, dass meine Malerei nicht wert ist, was sie kostet.”
Vincent van Gogh
 
“Meist belehrt erst der Verlust über den Wert der Dinge.”
Arthur Schopenhauer