Kommentierte Links (XXXII)

Grafik: Pixabay / Geralt - Lizenz

Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" Texte aus dem letzten Jahr.

• Wolf Lotter: Wo Strategie draufsteht, ist meist nur Planung drin

  Einer der großartigen Texte in denen (unbewusst?) von Agilität die Rede ist, ohne dass sie bei diesem Namen genannt wird. Die Quintessenz: statt zu planen (eine Abfolge von Vorgängen zu definieren und sich dann stur daran zu halten) ist das Erarbeiten einer Strategie sinnvoller - "weiter reichendes Denken auf Vorrat, bei dem man ein festes Ziel mit unterschiedlichen Mitteln flexibel ins Auge fasst", wie Wolf Lotter, der Autor dieses Artikels, es mit unvergleichlicher Wortwahl nennt. Letztendlich findet sich hier, mit Verweisen auf Sun Tzu, Peter Drucker, Moltke, Clausewitz und einige andere, der Kern dessen was Agilität von Chaos unterscheidet: ständige Anpassung an sich ändernde Umstände bei gleichzeitigem konsequenten Verfolgen eines übergeordneten Ziels.
  

• Niels Pflaeging: Change ist so wie Milch in Kaffee geben

Ich beschreibe Change bei meinen Kunden immer wie das Salzen des Essens: wenn das Salz einmal drin ist bekommt man es nicht mehr heraus. Die Metapher mit Kaffee und Milch hat mich darum sofort angesprochen. Auch in den anderen hier geäusserten Ideeen erkenne ich Überzeugungen von mir wieder, vor allem in der, dass es für effektive Veränderung sinnvoller ist bestehende Regeln zu entfernen statt neue einzuführen. Sobald den Menschen in sich ändernden Organisationen klargeworden ist welche befreiende Wirkung ein derartiges Entfesseln hat werden sie von sich aus auf die Abschaffung weiterer Regeln drängen und so selbst für ein Aufrechterhalten des permanenten Wandels sorgen. Die Einführung immer neuer Regeln (selbst wenn sie noch so gut sind) führt dagegen früher oder später zu Verschlechterungen, zu versalzenem Essen gewissermassen.

• Andrew Tarantola: Robot chefs and en route baking could be the future of pizza delivery

  Beim hochinnovativen IT-Unternehmen aus dem Silicon Valley denken die Menschen an alles mögliche, ganz sicher aber nicht an einen Pizza-Lieferservice. Das Beispiel von Zume Pizza ist ein hochinteressantes Beispiel für viele Aspekte von Innovations- und Optimierungsmanagement: manuelle Prozesse werden automatisiert, aber nur dort wo es zielführend ist, kreative oder ästhetische Arbeiten werden weiter von Hand ausgeführt. Und besonders beeindruckend: die Trennung von Produktions- und Lieferprozessen wird aufgehoben und sogar je nach Nachfrage modifiziert - der Lieferwagen verfügt über mehrere Öfen und kann zu Zeitpunkten hoher Nachfrage als temporäres Back- und Logistikzentrum genutzt werden. Disruption in einer Branche in der sie keiner vermuten würde. (den Beitrag gibt es auch als Video) 

• Jo Szczepanska: Design thinking origin story plus some of the people who made it all happen

  Zur Abwechselung ein bisschen Geschichtsunterricht. Genau wie im Fall von Lean und Agile können auch die Ursprünge von Design Thinking über mehrere Jahrzehnte zurückverfolgt werden. Dieser Beitrag ist wunderbar geeignet um ihn allen zu schicken die das Ganze als neumodischen Hype abtun wollen, denn er enthält neben Darstellungen verschiedener Denkschulen und Vordenker auch eine grafisch aufbereitete Zeitleiste und ein umfangreiches Literaturverzeichnis. Wer weiter nach unten scrollt kommt auf noch mehr Inspirationen, denn in den Kommentaren werden weitere historische Stränge und Personen genannt.

• Karin Dames: The Biggest Waste in Agile

  Es gibt Blogs die wie Sternschnuppen sind - sie tauchen plötzlich auf, strahlen für einen kurzen Moment und verglühen wieder. Everyday Agile ist, bzw. war ein solcher Blog, er wurde leider nur von Februar bis Juni betrieben, gehörte aber in dieser kurzen Zeit sowohl optisch als auch inhaltlich zu den besseren. The Biggest Waste in Agile steht stellvertretend für die ingesamt gerade einmal zehn Beiträge die hier verfasst worden sind, die anderen sind ebenfalls lesens- und sehenswert. Und da der Titel schon sehr effektheischend ist kommt hier der vorgeschaltete Spoiler: die größte Verschwendung im agilen Kontext sind Informationen die bei der Kommunikation zwischen zu stark arbeitsteiligen Teams oder Personen verlorengehen.

• Alexandre Magno: Don’t copy the Spotify Model. Do copy the Spotify attitude.

  Dass das so genannte "Spotify Model" nur eingeschränkt zur Nachahmung empfohlen ist wird von den Beteiligten selbst immer wieder betont. Es beruht zu sehr auf organisatorischen, technischen und kulturellen Besonderheiten dieser Firma, die in dieser Konstellation praktisch nicht reproduzierbar sind. Da immer mehr Firmen trotzdem genau das versuchen (die meisten davon lediglich auf Basis der beiden berühmten Engineering Culture-Videos) gab es dieses Jahr gleich mehrere Konferenz-Auftritte von Spotify-Mitarbeitern auf denen davor gewarnt wurde, unter anderem auf der Agile 2017, der Lean Agile Scotland und der Agile Bangkok. Dass man das unreflektierte Kopieren unterlassen und sich trotzdem von dieser Firma inspirieren lassen kann zeigt Alexandre Magno, der zurecht darauf hinweist, dass das eigentlich Besondere hier die Bereitschaft war durch ständiges Lernen einen eigenen Weg abseits der etablierten Frameworks zu entwickeln. Das kann in der Tat als Vorbild empfohlen werden.

• Steve Denning: What Is Agile? The Four Essential Elements

  Steve Denning steht mittlerweile seit Jahren als kluger und interessierter Beobachter am Rand bzw. leicht ausserhalb der agilen Filterblase und notiert wie agile Praktiken langsam in die Welt der großen Unternehmen eindringen. Am Beispiel der Firmen des SD Learning Consortium beschreibt er einen neuen Versuch die Inhalte des agilen Manifests konzerntauglich zu machen. Die dabei entstandenen Grundsätze sind:
  
  • Delighting customers
    Eigentlich eine Selbstverständlichkeit: alles was ein Unternehmen unternimmt sollte darauf ausgerichtet sein, bei den Kunden Erfolg zu haben. In der Realität leider häufig nicht gegeben.
  • Descaling work
    Die Bewältigung von Volatilität und Ungewissheit durch die Dekonstruktion von großen Vorhaben in kleine Arbeitspakete, durch die schnelle Markterfolge und Lerneffekte möglich sind.
  • Enterprise-wide Agility
    Die Übertragung von schlanken und reaktionsschnellen Organisationsformen auf die ganze Firma statt der häufig zu findenden dysfunktionalen Hybridlösung aus agilen Umsetzungsteams und Command & Control-orientiertem Management.
  • Nurturing culture
    Das vermutlich Schwierigste von allem: die Veränderung der Unternehmenskultur in Richtung eines ganzheitlichen Innovations- und Unternehmer-Ansatzes auf allen Ebenen.
  Interessant ist auch die Begründung für diese Neuformulierungen: das ursprüngliche Manifest aus vier Gegensatzpaaren und zwölf Prinzipien wäre zu umfangreich um in Großunternehmen kommuniziert zu werden. Honi soit qui mal y pense.

• John Cutler: The Way of Ways

  Mit mehreren hundert Artikeln alleine im Jahr 2017 (!) dürfte John Cutler einer der produktivsten Agile-Blogger sein, vielleicht sogar der produktivste von allen. Auf den ersten Blick ist dieser Artikel von ihm einer von mittlerweile unzähligen die die Entstehung und den Aufstieg der Agile-Bewegung nacherzählen. In dieser Hinsicht ist er nicht einmal besonders, andere, z.B. der von Caroline Mimbs in The Atlantic sind wesentlich besser geschrieben. Was ihn einzigartig macht ist die Erzählperspektive: stichwortartig notiert aus der Sicht der ersten Pioniere erkennt man den Zwiespalt aus der Begeisterung über die immer größere Verbreitung und der Verzweifelung angesichts von zunehmendem Kontrollverlust und Missbrauch. Am Ende steht die selbe Erkenntnis wie am Anfang - irgendetwas stimmt hier nicht, wir müssen an Verbesserungen arbeiten. Ein ewiger, sich selbst stimulierender Zyklus.

Das Increment als Geschenk

Reden wir über Geschenke. In meinem beruflichen Alltag als Scrum Master und/oder Agile Coach sind sie zwar nicht alltäglich, tauchen aber immer wieder auf, dann nämlich wenn ich im Rahmen von Workshops den Scrum-Flow mit seinen Rollen und Events auf ein Flipchart zeichne. An seinem Ende steht fast immer das Increment, also das benutzbare (Teil)Produkt. Und fast immer hat dieses Increment die Form eines Geschenks.

Dass ich meistens diese Darstellung wähle hat zum einen seinen Grund darin, dass viele Kunden, Auftraggeber und Stakeholder die regelmässige Auslieferung tatsächlich als Geschenk empfinden. Mit den Worten eines Managers eines DAX-Konzerns mit dem ich früher zusammenarbeiten durfte: "Früher haben wir zum Teil jahrelang warten müssen bevor irgendetwas zurückkam, jetzt habe ich das Gefühl als wäre alle zwei Wochen Weihnachten."

Der andere Grund ist der, dass ein Geschenk auch immer mit einer Erwartungshaltung an den Schenkenden verbunden ist. Ein Geschenk soll so ausgesucht sein, dass der Beschenkte es brauchen kann. Etwas das er noch nicht hatte und nach den er vielleicht schon länger vergeblich gesucht hat. Im besten Fall etwas das ihm Möglichkeiten aufzeigt an die er selbst noch gar nicht gedacht hat, die ihm aber sofort gefallen. Eigenschaften die sich idealerweise auch in jeder Produktneuerung wiederfinden sollten.

Zuletzt steckt im Geschenk auch implizit der Moment des Überreichens. Sei es mit oder ohne Geschenkpapier, das persönliche Geben und Entgegennehmen gehört dazu. Und mit der Zeit lernen wir durch die direkte Reaktion der Beschenkten wie es angenommen und bewertet wird, so dass wir beim nächsten mal eine noch bessere Auswahl treffen können. Auch das ist etwas was in den Beziehungen mit Auftraggebern und Kunden hochgradig Sinn macht.

In diesem Sinn: Schöne Bescherung.

Merit-Kalender

Bild: Pixabay / Hans Braxmeier - Lizenz

Zu den faszinierendsten Ideen aus dem Management 3.0-Bereich gehört das so genannte Merit Money. Statt finanzielle Boni auf "traditionelle" Art und Weise an von Managern definierte Ziele zu binden entstehen sie durch die Beziehungen zwischen den Teammitgliedern. Jedes Teammitglied kann in definierten Intervallen bestimmte Mengen einer virtuellen Einheit (Punkte, Kudos, etc.) öffentlich an andere Teammitglieder vergeben (nicht an sich selbst), woraus sich in Summe die ausgezahlten Boni ergeben. Statt Egoismen wird so Teamwork gefördert.

Trotzdem tun sich viele Teams mit diesem Ansatz schwer. Es wird befürchtet, dass Beliebtheitswettbewerbe oder Klüngelrunden entstehen, dass manche Kollegen gar nicht belohnt werden oder dass sonstige Probleme auftreten. Um diese Sorgen zu zerstreuen kann es hilfreich sein zunächst einen Probelauf einzulegen, in dem ein Team noch ohne die finanziellen Folgen ein Merit-System ausprobieren kann. Ein Beispiel für einen solchen Lauf habe ich vor einiger Zeit mit einem von mir gecoachten Team durchgeführt - mit einem Adventskalender.

Es handelte sich genaugenommen nicht um nur einen Kalender sondern um mehrere (einen pro Teammitglied) hinter deren Türen sich Süßigkeiten befanden. Vor dem Daily Standup konnte jeder seine Süßigkeit des Tages an einen anderen vergeben, immer verbunden mit einer Begründung warum der sich das an diesem Tag verdient hatte. Bedingt durch den geringfügigen Wert war die Hemmschwelle deutlich geringer als sie es bei echten Boni gewesen wäre, gleichzeitig sorgte die tägliche Frequenz für einen schnellen Gewöhnungseffekt.

Selbst wenn sich die Weihnachtszeit durch den hohen Bekanntheitsgrad der Adventskalender besonders für solche Experimente anbietet kann man sie natürlich auch im restlichen Jahr durchführen. Und statt Süßkram können auch andere Belohnungen vergeben werden, von der Ernennung zum Mitarbeiter der Woche bis hin zu Wildcards mit denen Refactorings im Backlog hochpriorisiert werden können.

Letztendlich werden sich viele Teams auch nach erfolgreichen Probeläufen trotzdem gegen Merit Money-basierte Boni entscheiden, was auch in Ordnung ist. Mitunter behalten sie dann aber Elemente bei mit denen sie vorher experimentiert haben. Auch das ist dann bereits ein Mehrwert der sich gelohnt hat.

Kontrollierte Experimente

Bild: Wikimedia Commons / Giorgio Selvini - CC BY 4.0

Ein kontinuierlicher Verbesserungsprozess klingt immer gut, in der Realität stellt sich aber immer wieder die Frage wie er konkret aussehen soll. Wer beschließt Verbesserungsmassnahmen? Wann werden sie beschlossen? Ab wann kann man mit einer erreichten Verbesserung zufrieden sein? Diese und weitere Fragestellungen werden immer wieder diskutiert. Ein Weg um hier mehr Klarheit zu bekommen sind kontrollierte Experimente, die jedes Team selber durchführen kann.

Ausgangspunkt eines solchen Experiment ist eine Verbesserungsidee, die irgendwann identifiziert wurde, z.B. in einer Retrospektive. Eine solche Idee könnte etwa sein, dass durch Pair Programming die Qualität einer Anwendung verbessert wird. Unerfahrene Teams setzen das häufig so um, dass sie sich einfach vornehmen mehr Pairing zu machen. Fragt man dann nach einiger Zeit ob es Verbesserungen gegeben hat kommen meistens unklare Antworten wie "vom Gefühl her ja, genau belegen kann ich es aber nicht".

Um derartige Situationen zu vermeiden hilft es, wenn man sich zu Beginn einige Gedanken macht: Welche Maßnahmen wollen wir konkret umsetzen? Wie wollen wir die Erreichung messen? Wann wollen wir die Messung vornehmen? Was passiert wenn wir unser Ziel erreicht, bzw. nicht erreicht haben? Am weiter oben genannten Beispiel würde das bedeuten: Um die Qualität der Anwendung zu verbessen wollen wir mindestens zwei Pairing Sessions pro Woche durchführen. Wir messen die bessere Qualität anhand der Zahl der nötigen Anpassungen die sich aus den folgenden Code Reviews ergeben, diese Zahl wollen wir halbieren. Wir überprüfen nach einem Monat wie sich diese Zahlen entwickelt haben. Wenn keine Veränderung sichtbar ist beenden wir das Pairing, wenn es zwar eine Verbesserung gibt aber nicht in der angestrebten Größenordnung diskutieren wir nochmal darüber.

Neben der besseren Überprüfbarkeit des Erfolgs ist bei diesem Vorgehen noch ein zweiter Vorteil hervorzuheben: wirkungslose Verbesserungsmassnahmen können einfach wieder rückgängig gemacht werden. Einer der häufigsten Einwände gegen Prozessverbesserungen ist, dass man die neu eingeführten Schritte nie wieder los werden kann. In dem Moment in dem klar wird, dass das im Misserfolgsfall sehr wohl geht gehen die Widerstände dagegen zurück.

Stillarbeit

Bild: Freegreatpictures / Max Pixel - CC0 1.0

Ein Fall aus der Praxis: im Team eines von mir gecoachten Scrum Masters war eine spürbar steigende Unzufriedenheit mit den Retrospektiven spürbar. Der Grund lag in den unterschiedlichen Charakteren der Teammitglieder - während die einen eher extrovertiert und impulsiv waren handelte es sich bei den anderen eher um stille Menschen. Infolgedessen verteilten sich die Redeanteile sehr ungleich, die Introvertierten hatten das Gefühl nicht zu Wort zu kommen, die Extrovertierten fühlten sich als wären sie die einzigen die Dinge ansprechen. Schwierig.

Auch die Moderationsversuche des Scrum Masters hatten nicht das gewünschte Ergebnis sondern führten dazu, dass das Team jetzt auch mit ihm unzufrieden war. Die Extrovertierten nahmen es so wahr als würde er ihnen ständig ins Wort fallen, die Introvertierten fühlten sich auf unangenehme Weise bedrängt und ins Scheinwerferlicht gestellt. Moderation war also auch nicht die Lösung, zumindest nicht mit einem darin noch relativ unerfahrenen Moderator.

Der Ansatz der die Situation spürbar verbessern konnte war die so genannte Stillarbeit. Jeder Teilnehmer der nächsten Retrospektive wurde gebeten zunächst in Ruhe seine Themen auf Post Its zu schreiben. Danach wurden sie der Reihe nach vorgestellt (Diskussionen wurden an der Stelle noch wegmoderiert), gemeinsam priorisiert und erst danach der Reihe nach diskutiert. Bei der kurzen "Retro der Retro" am Ende gab es für diese Art der Durchführung durchweg positives Feedback.

Die Diskussion hatte zwar immer noch ein gewisses Ungleichgewicht, allerdings hatte jeder Teilnehmer seine Themen in Ruhe vorstellen können, so dass die Introvertierten sich weniger übergangen fühlten und die Extrovertierten nicht mehr das Gefühl hatten alleine Input liefern zu müssen. Für den Scrum Master wurde ausserdem die Moderation einfacher, da er die bereits vorgestellten Themen als Ausgangspunkt für weiterführende Fragen nutzen konnte und nicht mehr ständig darum bitten musste, dass überhaupt Beiträge geliefert wurden.

Natürlich ist diese Art der Themensammlung nicht immer die passende, in diesem und in anderen Fällen hat sie von mir gecoachten Teams aber sehr geholfen und ist später auch in andere Meetings übernommen worden.

Kick the ball out of the tent

Ein Parforce-Ritt durch eine ganze Reihe von Aspekten: Wasserfall, Komplexität, Lean, Agile, Flow, Prinzipien, Prognosen und vieles mehr. Erkennbar für ein Publikum ohne vertiefte Vorkenntnisse gedacht und gerade deshalb geeinet für jeden der Inspirationen für seine eigenen Einführungsworkshops braucht.



Ähnlich wie ich experimentiert Kniberg anscheinend mit seinen Vorträgen und verändert sie immer wieder, im wesentlichen sind die Folien aber mit diesen hier identisch.

User Stories

Bild: Pxhere - CC0 1.0

Wenn immer es möglich ist sollten Scrum Teams versuchen ihre Anforderungen in Form von User Stories zu verfassen. Das ist zwar nicht im Scrum Guide vorgeschrieben sondern kommt aus dem Extreme Programming und es muss auch nicht immer in der klassischen Form Als [Benutzer mit Rolle ...] möchte ich [Aktion ... durchführen können] um [Mehrwert ... zu haben] sein (es gibt auch andere), es empfiehlt sich aber trotzdem so vorzugehen. Die Vorteile sind unverkennbar.

Um im Sinn des agilen Prinzips Maximizing the amount of work not done vozugehen lohnt es sich darüber nachzudenken wie man die Menge neu implementierten Codes so gering wie möglich halten kann. Ein weithin beliebter Ansatz ist dabei die Fokussierung auf den (End)Anwender. Nur was der tatsächlich benutzen kann ist von Wert, alles andere kann im Zweifel weggelassen werden. Folgerichtig sollten Anforderungen idealerweise auf Use Cases (Anwendungsfällen) beruhen.

User Stories greifen diese Idee auf und reichern sie um weitere Elemente an: in verständlicher Sprache erklären sie wer der Anwender ist, welche neue Funktion er braucht/bekommt und welcher Mehrwert damit verbunden ist. Neben dem oben genannten häufigsten Muster gibt es auch andere Variationen, etwa Um [Ziel ... zu erreichen] ermöglichen wir [Benutzer mit Rolle ...] die Aktion [...] durchzuführen oder ganz schlicht Nutzer: [...], Aktion: [...], Mehrwert: [...].

Natürlich werden trotzdem immer wieder Anforderungen auftauchen die nicht in dieses Muster passen: Arbeit an technischen Komponenten, Anpassungen an Architekturvorgaben, Bugfixes, Absicherung durch Tests, Code Cleaning, Abbau technischer Schulden, etc. Da viele von ihnen ein Zeichen von fehlender Anwender-Zentrierung oder (Spät)Folgen nachlässiger Arbeit sind kann es hilfreich sein das Verhältnis zu tracken: wieviel Prozent der umgesetzten Anforderungen sind User Stories und wie viele nicht? Bei einem zu niedrigem User Story-Anteil kann sich ggf. eine Retrospektive lohnen.


PS: es gibt leider auch Teams in denen der Begriff User Story ein generisches Synonym für Anforderungen aller Art ist. Mitglieder dieser Teams mögen sich bitte zur Behandlung in der nächsten Coach-Klinik melden.

Scaled Agile: Chief Product Owner

Bild: Flickr / Rod Waddington - CC BY-SA 2.0

[Edit] Durch das 2020-Update des Scrum Guide ist eine Aktualisierung dieses Artikels nötig geworden, er wurde entsprechend angepasst.

Wenn Teams nach Scrum arbeiten gilt in Bezug auf die Rolle des Product Owners das Highlander-Prinzip: Es kann nur einen geben. Der Scrum Guide formuliert das an gleich zwei Stellen sehr eindeutig: "For Product Owners to succeed, the entire organization must respect their decisions." und "The Product Owner is one person, not a committee." Für ein einzelnes Team ist das auch nachvollziehbar, aber was passiert wenn mehrere Teams zusammenarbeiten müssen? Einen Ansatz findet man in diesem Kontext immer wieder.

Passend zum teamübergreifenden Konstrukt des Tribes findet man in vielen Organisationen die Rolle des Chief Product Owners oder CPO (auch Head PO, Lead PO, o.ä.), der hierarchisch oberhalb der eigentlichen Product Owner angesiedelt ist. Wie diese Rolle aussieht wenn sie mit Scrum kollidiert wäre ein eigenes Thema, bezogen auf "Scrum by the Book" gibt es aber die klare Grenze, dass der eigentliche Product Owner nicht in seinen Kompetenzen eingeschränkt werden darf. Die spannende Frage: ist das überhaupt möglich? Welcher Spielraum bliebe noch für eine zusätzliche Rolle?

Eine Möglichkeit wäre diese: Das Produktmanagement-Themenfeld das der Scrum Guide für höhere Ebenen zugänglich hält ist die initiale Auswahl, bzw. Definition der Produkte, verbunden mit dem Setzen der Produktziele. Es heisst zwar "The Product Owner is [...] accountable for effective Product Backlog management, which includes: Developing and explicitly communicating the Product Goal.", aber das Entwickeln und Kommunizieren eines Produktziels ist eben etwas anderes als dessen Auswahl. Ein CPO kann also Produkte und deren Ziele (vor)auswählen, um sie dann den POs und deren Teams zu übergeben.

Was in Scrum explizit nicht zum Aufgabenbereich eines CPO gehören kann ist im Anschluss daran die Arbeit an den Backlogs, er soll also weder eine Ausdetaillierung der Backlog Items vornehmen noch spezifische Arbeitsaufträge an die Teams vergeben oder deren Reihenfolge oder Priorität festlegen. Das bleibt dem PO vorbehalten, der dafür auch Teil mehrerer Scrumteams sein kann (was so seit 2020 auch explizit im Scrum Guide steht und nicht mehr implizit daraus abgeleitet werden muss).

Diese Aufteilung in CPO (ausserhalb des eigentlichen Scrum) und PO (offizieller Teil von Scrum) kann in der Anwendung schnell künstlich wirken und im schlimmsten Fall zu Konflikten führen, durch die Ressourcen gebunden und die Organisation gelähmt werden. Im Rahmen des Scrum-Frameworks ist es aber die einzige mögliche Aufteilung. Das heisst zwar nicht, dass man nicht alles anders organisieren könnte - aber dann ist es kein Scrum mehr.

Nachtrag 26.02.: 
Eine Übersicht über andere Interpretationen der Chief PO-Rolle gibt es hier.

Kommentierte Links (XXXI)

Grafik: Pixabay / Geralt - Lizenz

• Mary Poppendiek: The cost center trap

  Ich sage ja: ein Scrum Master sollte über den Tellerrand blicken und wirtschaftliche Zusammenhänge kennen. Mary Poppendiek beschreibt einen weiteren guten Grund dafür - das Center-Konzept, das in vielen Unternehmen verbreitet ist. Wenn die Softwareentwicklung eines Unternehmens als Cost Center (oder Service Center) gilt und nicht als Profit Center, dann besteht das dauerhafte Risiko im wahrsten Sinn des Wortes kaputtgespart zu werden. In einer solchen Situation kann man mit agilen Ansätzen bestenfalls Symptome abschwächen. Bevor es zu strukturellen Verbesserungen kommt muss das zentrale Impediment beseitigt werden: die Center-Zuordnung in ihrer bisherigen Form.

• Jason Little: We don't need agile leadership

Hinter diesem Artikel stehen zwei Aussagen. Zum einen die, dass es sich bei den meisten Begriffen die "agile" als Präfix haben um Unsinn handelt. Speziell das aktuell gehypte agile Leadership hat erkennbar den primären Zweck Lehrgänge und Zertifikate zu verkaufen. Wirklich Bemerkenswertes findet man hier selten. Interessanter finde ich die zweite: Jason Little geht davon aus, dass der typische agile Coach ständig auf der Suche nach Neuem ist (oder wie er es sagt - schnell gelangweilt). Bedingt dadurch werden auch die obskursten Ideen durchdiskutiert und ausprobiert. Da ist leider etwas dran. Andererseits - wie sonst soll man diese Ansätze bewerten können?

• John Cutler: The trouble with Scrum

  Ein Thema das immer wieder aufkommt. Man kann sich komplett an alle Scrum-Regeln halten und trotzdem kann das Ergebnis unbrauchbar sein. Zweifellos richtig. Was John Cutler als "mechanistisches Scrum" bezeichnet kann auf derartige Effekte herauslaufen. Viele agile Practicioner (darunter auch ich) würden das allerdings nicht als echte Umsetzung betrachten sondern als Cargo Cult. Das zu erklären und zu begründen ist mittlerweile eine der Hauptaufgaben von agile Coaches und Scrum Mastern geworden, und dazu eine die dauerhafte Beschäftigung verspricht. Denn dass die mechanistischen Lösungen eine magische Anziehungskraft auf klassische Manager ausüben kann man in fast jeder größeren Firma erleben.
  

• Anna Steiner: So einfach geht Elektroauto

  Was Anna Steiner hier zur Firma Streetscooter zusammengetragen hat klingt sehr nach agiler Produktentwicklung. Die hier hergestellten Elektroautos sind MVPs (sie sind in der ersten Generation nur auf kurzen Strecken und in gemäßigten Klimazonen nutzbar), sie werden modular und iterativ weiterentwickelt (mit neuen Funktionalitäten in jedem Produktzyklus) und nach jeder dieser Iterationen können die Nutzer Feedback und Weiterentwicklungswünsche abgeben, die zügig in die Planung aufgenommen und umgesetzt werden. Verabschiedet hat man sich dafür von dem an Overengeneering grenzenden Perfektionismus, der im deutschen Ingenieurwesen noch immer vorherrscht. Man kann gespannt sein wie dieser Geist nach der Übernahme durch den Großkonzern Deutsche Post weitergetragen wird.

• Ron Miller: How bad decision making could undermine good innovation

  Wie man auf englisch sagt - der Niedergang von Kodak ist eine Geschichte "that keeps on giving". Nachdem ich schon vor drei Monaten eine Analyse des damaligen Management-Verhaltens verlinkt hatte führt Ron Miller in weitere Aspekte ein: die Firma Kodak hat nicht nur die Technologie von der sie vom Markt gefegt werden sollte (Digitalfotografie) selbst entwickelt, sie hat sie sogar selbst an den Markt gebracht. Das allerdings so sehr im Rahmen der bisherigen Produktstrategie, dass für die Nutzer kaum relevanter Mehrwert entstand. Erst als andere Firmen die neue Technologie auch in neuen Kontexten einsetzten wurden sie zu einer Disruption. Man kann erahnen welcher gewaltige Mindset-Change hier für agiles Reagieren notwendig gewesen wäre.

Ein Kanban-Flickenteppich

Agile und Lean im Konzern - geht das überhaupt? Und wenn ja wie? Diese Fragen stellen sich immer wieder. Dieses Video zeigt, dass es grundsätzlich geht und führt Möglichkeiten und Potentiale vor, aber auch Begrenzungen und Kompromisse. Denn selbst wenn das Gesamtbild beeindruckend ist - ab Minute 29 erkennt man noch das klassische Gantt-Chart- und Langfristplanungs-Projektmanagement.



Offenlegung: Daniel und ich kennen und schätzen uns.

Rollen und Tätigkeiten

Bild: Wikimedia Commons / Andriy Makukha - CC BY-SA 3.0

Zu den Gründen aus denen viele Unternehmen Verschlimmbesserungen an Scrum vornehmen (was häufig zum Harikiri führt) gehört die Sorge, dass komplexe Vorhaben ohne leitende und koordinierende Rollen nicht funktionieren. Die Argumentationen sind immer wieder die gleichen: Es gibt viele übergreifende Tests? Dann braucht man einen Testkoordinator. Es gibt eine komplexe Architektur? Dann braucht man einen Architekten. Es müssen verschiedene Features gleichzeitig Live gehen? Dann braucht man einen Releasemanager. Und so weiter. Die Folge: Mit den Rollen kommen Arbeitsteilung und Bürokratie zurück, alles wird langsamer, die Agilität verschwindet.

Dass diese Entwicklung immer wieder auftritt lässt sich auf einen zentralen Denkfehler zurückführen: Es wird davon ausgegangen, dass Tätigkeiten nicht mehr durchgeführt werden wenn sie keiner Person zugeordnet sind. Würde das zutreffen wäre es tatsächlich ein Problem, allerdings trifft es in richtig implementiertem Scrum nicht zu. Hier werden diese Tätigkeiten auch weiterhin erledigt, nur eben von keinem Koordinator oder Mittelmanager mehr sondern vom Entwicklungsteam selbst, und zwar immer dann wenn es notwendig ist.

"Aber das geht nicht, das können die gar nicht!" wird an dieser Stelle häufig eingewandt. Und hier kommen wir wieder zum korrekt implementierten Scrum zurück: Wenn zu den Aufgaben die erledigt werden müssen z.B. Testmanagement gehört, dann müssen dem Entwicklungsteam Personen zugeordnet sein die das können. Der Scrum Guide ist da eindeutig - Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment. Auch hier gilt die alte Wahrheit, dass dieses Framework nur funktioniert wenn man es einsetzt wie gedacht.

Und das lässt sich sogar noch weitertreiben: um dem Regelwerk formal Genüge zu tun könnte man einfach den Test- oder Releasemanager in das Team versetzen, wo er zwar seinen Titel verlieren würde, seine Rolle aber weiter ausüben könnte. Zu empfehlen wäre das aber nicht, da er zum einen in nur einem Team kaum ausgelastet wäre und zum anderen der Bus-Faktor bedenklich nach unten gehen würde. Zielführender wäre auch hier die Anwendung des Pull-Prinzips: Die Tätigkeit kommt als Task auf das Board und sobald sie erledigt werden muss kann sie vom jeweils nächsten Teammitglied übernommen werden das eine Aufgabe abgeschlossen hat.

Natürlich muss umgedacht werden wenn so gearbeitet wird. Manager müssen Verantwortung dorthin geben wo sie bisher noch nicht war, Mitarbeiter müssen weitergebildet werden und Entwickler müssen Aufgaben übernehmen die sie vorher noch nicht hatten. Die Vorteile wiegen das aber mehr als auf - Wissensverteilung, Abbau von Flaschenhälsen, ganzheitliche Sicht und Übernahme von Verantwortung sind nämlich genau die Faktoren die ein Team schon nach kurzer Zeit effektiver und effizienter machen.

Agilität, dort wo man sie nicht vermutet (II)

Bild: Pixabay / Skeeze - Lizenz

Einer der wirksamsten Impulse gegen festgefahrenes Denken besteht in der Bemerkung, dass einige der besten Umsetzungen agiler Arbeitsweisen aus dem öffentlichen Dienst kommen. In der Regel führt das sofort zu Widerspruch. Das wäre ja gar nicht möglich. Der Staat sei doch für starre Strukturen und ineffizientes Handeln bekannt, für langsame Prozesse, lange Dienstwege und ähnliches. Wor wären denn da Einheiten die flexibel und reaktionsschnell arbeiten würden? Die gäbe es doch gar nicht.

Allerdings - es gibt sie doch, und sie sind sogar so bekannt, dass jeder sofort etwas mit ihnen anfangen kann. Zu ihnen gehören Feuerwehrwachen, Notaufnahmen und Operationsteams in Krankenhäusern, Flugleitzentralen, militärische Einheiten im Fronteinsatz und viele mehr. In jedem dieser Fälle sind die jeweiligen Teams mit sich schnell ändernden und instabilen Umgebungen konfroniert, in denen es überlebenswichtig sein kann innerhalb kürzester Zeit Entscheidungen zu treffen und sie umzusetzen. Und genau deshalb findet das dort statt.

Das Ziel dieses Gedankenspiels (Agilität im öffentlichen Dienst) sind verschiedene Erkenntnisse. Zum einen: jede organisatorische Einheit kann es schaffen sich agil zu organisieren. Wenn sogar Behörden es schaffen können, dann kann jede andere Organisation das auch. Denn soviel Wahrheit steckt doch im Klischee - die deutschen Amtsstuben sind im Normalfall eben doch ein Umfeld das eher Gemächlichkeit und Geruhsamkeit befördert. Aber das kann überwunden werden, wenn man nur will.

Hieraus ergibt sich dann auch die zweite Erkenntnis: es sind oft die Umgebungsfaktoren, die die Fähigkeit eines Teams zur agilen Organisation erst möglich oder unmöglich machen. Wenn die Umgebung einen Sinn in schnellen Reaktionen sieht (z.B. in Notaufnahmen oder Brandwachen), dann wird sie alles dafür tun diese auch herzustellen - sogar beim Staat. Wenn dieser Sinn aber nicht erkannt wird, dann werden die organisatorischen und bürokratischen Hürden im Zweifel nicht beseitigt werden, dann geht alles weiter seinen gemächlichen Gang.

Exkurs in die empirische Sozialforschung

Dieser Talk von Linda Rising erinnert mich sehr stark an die Seminare zur empirischen Sozialforschung die ich vor langer Zeit an der Universität gemacht habe. Und genau wie bei einigen meiner damaligen Dozenten bin ich mir nicht sicher - finde ich ihren Vortragsstil beruhigend, spannend, einschläfernd oder nervtötend? Unabhängig davon hat sie einen Punkt: wenn man im Lean Startup-Modus Experimente durchführen will sollte man darüber nachgedacht haben was das ist.

Über den Tellerrand

Bild: Max Pixel / Reinhard Thrainer - CC0 1.0

Zu den etwas irritierenden Momenten meines Jobs gehört im Augenblick, dass ich (der agile Coach) die Mitarbeiter eines Kunden bei ihren PMI-Weiterbildungen begleiten darf. Ich bin zwar alles andere als ein Fan, habe mich aber bereits vor einiger Zeit durch den dazugehörigen "Body of Knowledge" gearbeitet und kann daher aufzeigen wo er Schnittmengen mit agilen Vorgehensweisen hat (z.B. bei der Rolling Wave-Planung) und wo nicht. Und wenn es dazu beiträgt mehr Realitätsbezug und weniger Bürokratie in Projektplanungen einzubringen, dann hat es sich bereits gelohnt.

Bei einem anderen Kunden wurde ich vor einiger Zeit in Meetings gebeten in denen ein SAFe-Projekt aufgesetzt wurde. Auch davon bin ich kein besonderer Fan, hatte mich aber irgendwann eingearbeitet und konnte dadurch etwas beitragen: als ein Manager darauf bestehen wollte, dass man in dieser Methode möglich viel zentralisierte Planung haben will konnte ich belegen, dass (zumindest in der Theorie) das Gegenteil der Fall ist. Zentralisiert wurde später zwar trotzdem, allerdings zumindest ohne das Wort "Agile" dafür zu missbrauchen.

Im Umkehrschluss kenne ich eine ganze Reihe von Scrum Mastern und agile Coaches die in vergleichbaren Situationen aus Diskussionen aussteigen mussten, weil sie vom jeweiligen Thema keine Ahnung hatten. In einigen dieser Fälle waren Beschlüsse das Ergebnis, die nur mit Mühe oder gar nicht mehr zurückgedreht werden konnten. Hier hätte es geholfen zumindest ein Grundverständnis zu haben.

Genau dieses Grundverständnis ist auch der Punkt um den es geht. Natürlich kann niemand alles wissen, es ist aber auf jeden Fall sinnvoll bis zu einem gewissen Grad mitreden zu können, sei es in den genannten Beispielen zu PMI oder SAFe oder im Fall von ITIL, Prince2, ISTQB oder sonstigen Ansätzen mit kryptischen Abkürzungen. Den meisten überzeugten Agilisten macht das Beschäftigen mit diesen Themen zwar nur wenig Spass, dass es im Job vorteilhaft sein kann dürfte aber offensichtlich sein.

Ein häufiges Argument gegen die Einarbeitung in diese Wissensgebiete ist übrigens, dass das Zeit erfordert, die nicht zur Verfügung steht. Ironischerweise kommt es häufig von Menschen die nicht erklären können was ein Scrum Master/Agile Coach den ganzen Tag macht. Vielleicht besteht da ein Zusammenhang.

Update des Scrum Guide 2017

Bild: Wikimedia Commons / Quintin Smith - CC BY 2.0

Der Scrum Guide scheint selbst agiler zu werden, jedenfalls werden seine Releasezyklen kürzer. Ein Jahr nach dem letzten Update gibt es jetzt ein neues, diesesmal mit einem anderen Schwerpunkt. Während 2016 mit den Scrum Values ein kompletter Abschnitt neu hinzugefügt, bzw. zurückgebracht wurde gab es dieses Jahr verschiedene kleinere Ergänzungen. Aus meiner Sicht werden vor allem zwei davon spürbare Auswirkungen haben: die im Bereich des Daily Scrum und die im Bereich des Sprint Backlog.

• Daily Scrum

  Die drei Fragen sind jetzt optional. Die neue Formulierung heisst "The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based". Damit wird offiziell was viele Teams ohnehin schon machen und was ich bereits bei einigen Teams eingeführt habe. Letztendlich wird hier ein Auseinanderklaffen von Theorie und Realität repariert. Wenn von den drei Fragen abgewichen wird um Status-Reporting und Kalenderverlesung zu vermeiden wird es von jetzt an weniger Diskussionen geben.

• Sprint Backlog

  Ein ganz anderer Fall. Die neue Formulierung heisst "The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting". Auch das ist nicht völlig neu, an vielen Boards gibt es bereits Kaizen-Lanes. Allerdings sind derartige Boards bisher eher in der Minderheit. Dass es ab jetzt offizieller Teil von Scrum ist wird für viele Diskussionen sorgen. Und ungeachtet der Tatsache, dass es Sinn macht den ständigen Verbesserungsprozess zu verankern -  wie passt das mit dem (fachlichen) Sprintziel zusammen? Da kann man auf die sich herausbildenden Practices gespannt sein.

Was die anderen Änderungen betrifft halte ich es frei nach dem Schlußsatz des agilen Manifest - sie sind nicht unwichtig, aber die beiden Punkte auf die ich eingegangen bin halte ich für wichtiger. Und zuletzt noch eine Beobachtung: im Livestream von Sutherland und Schwaber waren die Logos von Scrum.org und Scrum Inc prominent eingeblendet, das der Scrum Alliance aber nicht. Ein weiteres Zeichen der Entfremdung?

Hart gecodet

Bild: Wikimedia Commons / Clio20 - CC BY-SA 3.0

Zu den Ausdrücken die bei vielen Projektmanagern Fragezeichen in den Augen verursachen gehört "hart gecodet". Begleitet von einem Augenrollen oder Stöhnen der Entwickler bedeutet es oft, dass an einer Stelle eine "zu einfache" Lösung gewählt wurde, die jetzt durch eine "richtige" ersetzt werden müsste. Da auf der Benutzeroberfläche alles gleich aussieht ist für einen Nicht-Entwickler aber nicht klar warum dieser Aufwand Sinn macht. Ein Übersetzer ist gefragt. Und eine mögliche Übersetzung könnte in Form eines Praxisbeispiels stattfinden, das so tatsächlich existiert hat:

Eine Firma betreibt einen Web-Shop, der wie jede andere Website ein Impressum haben muss. Dieses muss unter anderem eine Adresse und den Namen der vertretungsberechtigten Personen enthalten, in diesem Fall der Geschäftsführung. Etwa so:

ABC AG
XYZ Strasse
Vorstand: Herr Baumann, Herr Bergmann

Wie kommen diese Informationen jetzt auf die Website? Eine Möglichkeit besteht darin, sie direkt in den Code zu schreiben. Genau das ist es was man unter hart gecodet versteht. Das könnte dann so aussehen:

<div id="imprint">
ABC AG<br />
XYZ Strasse<br />
Vorstand: Herr Baumann, Herr Bergmann<br />
<div>

Warum könnte das jetzt ein Problem sein? Nehmen wir an die Firma ist ein schnell wachsendes Startup. Um immer mehr Mitarbeiter unterbringen zu können zieht es in kürzerer Zeit mehrfach um. ausserdem wird im Rahmen der Professionalisierung die Geschäftsführung vergrößert, vielleicht verkauft auch ein Gründer seine Anteile und steigt aus. Jedesmal muss das Impressum aktualisiert werden. Und: auf einmal gibt es mehr als eine Stelle an der ein Impressum vorgeschrieben ist. Es gibt eigene Aktions- oder Produkt-Websites, es gibt automatisierte Mails an die Kunden, es gibt einen Email-Presseverteiler, etc., etc., etc. Schon bald erfordert jede Aktualisierung eine Schnitzeljagd nach allen Stellen an denen das notwendig ist und früher oder später werden einzelne davon vergessen und nicht mehr aktualisiert. Teure Abmahnungen können das Ergebnis sein.

Um dieses Risiko zu umgehen können alle Daten des Impressums an einer zentralen Stelle hinterlegt werden. Wenn die einzelnen Websites und Mailprogramme dann so designt sind, dass sie die Daten immer aus dieser zentralen Stelle abgelesen werden, müssen sie nur noch ein einziges mal aktualisiert werden wenn sich etwas ändert. Das könnte so aussehen:

<div id="imprint">
<p class="getimprint">
<div>

Natürlich verbirgt sich hinter dem <p class="getimprint"> jetzt etwas mehr als nur die bloßen Buchstaben, es ist eine Funktion die die Impressumsdaten aufruft. Die zu schreiben ist aufwändiger als die hart gecodete Eingabe der Informationen, weshalb man auf die Idee kommen könnte durch die einfacher scheinende Lösung Zeit zu sparen. Das man von dieser scheinbaren Ersparnis wieder eingeholt werden würde sieht man an dem oben genannten Beispiel.

<Disclaimer> Es gibt natürlich Fälle in denen harte Codierung unbedenklich ist, oft genug ist sie es aber nicht. Und wenn ein Entwicklungsteam sagt, dass es eine solche Stelle bereinigen möchte ist es eine gute Idee ihm die Zeit dafür zu geben.

Selbst- und Fremdwahrnehmung von IT-Berufen

Wie so oft: klischeehaft, überzeichnet, aber mit einem nicht völlig zu bestreitenden Realitätsbezug. Und die armen Sysadmins haben in der Realität leider wirklich einen durchgehend schlechten Ruf.
Was hier fehlt sind die Scrum Master und agile Coaches. Kommt vielleicht in der nächsten Version (Bild: Imgur).

Kommentierte Links (XXX)

Grafik: Pixabay / Geralt - Lizenz

• Joshua Kerievsky: Size teams for few to no handoffs

  Ein schönes Beispiel dafür wie sich Lean und Agile überschneiden. Übergaben zwischen Teams führen zu Wartezeiten, Wartezeiten führen zu langsamen Produktionsvorgängen und langsame Produktionsvorgänge sind nicht mehr agil. Joshua Kerievsky definiert die Freiheit von Übergaben (→ Crossfunktionalität und Autonomie) als so wichtig, dass dafür im Zweifel sogar relativ große Teams (größer als zehn Mitglieder) in Kauf genommen werden sollten. Ein interessanter Gedanke, selbst wenn ich glaube, dass in der täglichen Arbeit mit hoher Wahrscheinlichkeit ein Zerfall in Subteams stattfinden würde.

• Michael Küsters: How splitting work kills companies

Der gleiche Gedankengang aus einer anderen Perspektive. Dass selbst kleine und gut gemeinte Aufgabenteilungen zwischen mehreren Teams zu Bürokratie und Verlangsamung führen können ist auf einer abstrakten Ebene klar, das ganze Ausmaß erschließt sich aber erst an konkreten Beispielen. Das in diesem Fall genannte ist besonders anschaulich, da es sich nicht um Softwareproduktion handelt sondern um einen outgesourcten Kundenservice. Und auch ein weiterer Aha-Effekt ist enthalten: wenn Bürokratie selbst in einem so begrenzten Fall bereits entstehen kann - was passiert dann erst in komplexen Umgebungen?

• Claire Lew: The Culture Cliché

  An der Universität habe ich gelernt, dass Kultur die Summe der impliziten und expliziten Konventionen, Normen, Werte und gemeinsamen Erinnerungen ist, aus der eine soziale Gruppe ihre Identität konstruiert. Claire Lew formuliert es einfacher: “Culture is the way we do things around here.” Was beiden Definitionen gemeinsam ist - man kann Kultur nicht verordnen oder einführen. Sie ist einfach da und überlagert früher oder später alles andere. Wenn im Rahmen einer Unternehmenstransition nicht auch die Kultur geändert wird ändert sich im Zweifel gar nichts, zumindest nicht so wie gewünscht.
  

• Leon Tranter: Technical debt — or technical bankruptcy?

  Vermutlich muss man eine ausser Kontrolle geratene technische Schuld selbst erlebt haben um ihre Tragweite erfassen zu können. Wenn selbst kleinste Änderungen zu umfangreichen Arbeiten in allen Anwendungsteilen, systemweiten Ausfällen und langwierigem Bugfixing führen ist dieses Endstadium erreicht, das Leon Tranter sehr anschaulich als "technischen Bankrott" beschreibt. Sowohl die Ursachen als auch mögliche Lösungen sind gut zusammengefasst, jetzt müsste sie nur noch jemand lesen, der den Entwicklern seines technisch bankrotten Projekts/Unternehmens erlauben kann sie umzusetzen.

• Patrick Beuth: Feindbild Algorithmus

  Kurz nachdem die Digitalbranche zum größten Arbeitgeber in Deutschland geworden ist zeigt der Staat, dass er diesen Wandel leider noch immer nicht versteht. Wenn Bundesjustizministerium, wissenschaftlicher Dienst des Bundestages und weitere Politiker jetzt fordern, dass den Nutzern von Google, Facebook & Co offengelegt wird welche Algorithmen einem Suchergebnis oder Newsfeed zugrundeliegen, dann wird deren Volatilität verkannt. Alleine im letzten Jahr wurden in der Web-Suche von Google 9800 Modifikationen im Livebetrieb getestet, von denen dann 1600 dauerhaft eingeführt wurden (Bericht hier). Soll dann jeder Benutzer 27 Benachrichtigungen pro Tag erhalten? Vielleicht würden dem Bundestag und der Regierung eine Einführung in die Grundlagen agiler Softwareentwicklung gut tun.

Das Ende der Selbstorganisation

Bild: Wikimedia Commons / Famartin - CC BY-SA 4.0

Einer der zahlreichen heiligen Grale der Agilität ist die Selbstorganisation der Teams. Autonom, crossfunktional und empowered sollten sie sein, von niemandem gemicromanaged, lediglich von Servant Leadern umgeben und unterstützt. Nur wenn all das gegeben ist können sie zu schlagkräftigen und reaktionsschnellen High Performance-Units werden, ungebremst von Flaschenhälsen oder Handovers. Das stimmt in der Theorie und das stimmt auch in der Praxis, und doch - Selbstorganisation muss häufig Grenzen haben.

Man kann es am einfachsten an den Extremfällen sehen. Ein Team in einer Firma für Bürosoftware kann noch so selbstorganisiert sein, wenn es sich entscheiden würde statt eines Antivirus-Patch der Bürosoftware lieber Computerspiele zu programmieren würde das Management das zu Recht verhindern. Und ein Entwicklungsteam einer Bank kann noch so selbstorganisiert entscheiden, dass es seine Prozesse nicht mehr dokumentiert, die Bafin würde ungerührt untersagen, dass die so entstandene Software in Produktion geht.

Auch Grenzfälle sind bei genauerer Betrachtung offensichtlich: ein Team das die eigene Anwendung sowohl weiterentwickelt als auch wartet kann zwar selbstorganisiert entscheiden wann seine Mitglieder ihren Urlaub nehmen, es muss aber dafür sorgen, dass immer jemand da ist der die Live-Version am Laufen hält. Und ein Team das eine neue Software baut kann zwar wählen welche Programmiersprache es benutzt, das Unternehmen kann aber verlangen, dass es eine ist die auch ausserhalb des Teams verstanden wird.

Schwierig wird es schließlich wenn die Selbstorganisation mit Unternehmensgrundsätzen kollidiert. Darf ein Team für seine MVPs Quick & Dirty-Lösungen implementieren wenn das Unternehmen Clean Code will? Dürfen sich Entwickler selbstorganisiert zu Teams von über 20 Personen zusammenschliessen wenn das Unternehmen auf kleine Squads oder Scrum Teams setzt um agil zu bleiben? Spätestens hier heißt es oft: "Wenn Ihr das vorschreibt schafft Ihr die Selbstorganisation ab!" Aber ist das wirklich ein Argument?

In den meisten Fällen zeigt sich an solchen Situationen, dass nie daran gedacht wurde festzulegen bis wohin Selbstorganisation geht (dass es solche Grenzen gibt sieht man an den ersten Beispielen). Bei vielen agilen Transitionen heisst es einfach "Ab jetzt sind die Teams selbstorganisiert". Und wenn die im Rahmen ihrer Selbstorganisation auf eine Stelle stossen an der diese doch nicht gewünscht ist knallt es gelegentlich. Das muss nicht sein.

Es ist empfehlenswert, dass Management und Team gemeinsam (!) Grenzen festlegen bis zu denen die Autonomie reicht. Welche das sind kann von Fall zu Fall unterschiedlich sein, sie sollten aber begründet und nachvollziehbar sein. Und es sollte auch jedem klar sein, dass diese Grenzen nicht unverrückbar sind sondern sich verschieben können. So kann etwa zu Beginn noch ein Architekt vorhanden sein, der sich irgendwann später selbst abschafft und in das Team geht.

Zuletzt kann jedes einzelne Teammitglied anhand dieser Grenzen entscheiden ob es sich hier noch richtig aufgehoben fühlt. Und wenn das nicht der Fall ist kann es mit den Füssen abstimmen und gehen, in ein anderes Team oder ein anderes Unternehmen.

Kollektives Gedächtnis

Bild: Pxhere - CC0 1.0

Zu den häufigsten Beschwerden bei der Einführung agiler Methoden gehört die, dass man sich "das alles" unmöglich merken könnte. Das Grundgerüst von Scrum oder Kanban würde ja noch gehen, aber die zahllosen good und best Practices aus Extreme Programming, Lean Startup, Lean Management, TPS, Design Thinking, Clean Code, DevOps und sonstigen Ursprüngen wären einfach zu viel.

Bis zu einem gewissen Grad ist dieser Einwand sicher richtig, kein Mensch ist in der Lage sich alles zu merken. Dass in Summe trotzdem viel mehr an Wissen hängenbleibt als man denken sollte liegt an einem Phänomen das man als "kollektives Gedächtnis" bezeichnet, welches erstmals 1939 vom Soziologen Maurice Halbwachs beschrieben wurde. Vereinfacht gesagt bedeutet es, dass sich Gruppen von Menschen mehr Dinge merken können als einzelne Personen. Wie so oft: ein Ganzes ist mehr als die Summe seiner Teile.

Zunächst klingt das banal. Person A lernt Wissensgebiet A, Person B lernt Wissensgebiet B und zusammen wissen beide mehr als jeder für sich genommen. In der Realität ist es aber komplexer als das. Da die verschiedenen Personen sich kontinuierlich miteinander austauschen wird das Wissen nicht nur untereinander und mit Dritten geteilt, es wird auch immer wieder zurück in Erinnerung gerufen, so dass es nicht in Vergessenheit geraten kann. Ohne diese Kommunikation würde das Wissen irgendwann wieder verfallen.

An dieser Stelle überschneidet sich die Idee des kollektiven Gedächtnis mit verschiedenen good Practices im agilen Vorgehen. Die überschaubare Größe von Organisationseinheiten und die verschiedenen Querschnittsgruppen sorgen dafür, dass die gemeinsamen Erinnerungen durch eine permanente Kommunikation immer wieder erneuert werden, während der Soft Power-Aspekt der Methode dafür sorgt, dass das auch gerne und von sich aus stattfindet. Die verschiedenen themenspezifischen Meetingformate bieten den geeigneten Rahmen.

Ein für große Organisationen unerfreulicher Aspekt ist übrigens, dass auch schlechte Erinnerungen im kollektiven Gedächtnis hängenbleiben. Besonders das Fehlverhalten herausgehobener Personen (→ Manager) kann jahrelang im gemeinsamen Bewusstsein erhalten bleiben und selbst in jüngere Generationen hereingetragen werden die es gar nicht selbst erlebt haben. Ein Grund mehr das eigene Tun regelmässig zu überdenken.

Scaled Agile: Gilden

Bild: Wikimedia Commons / Gerbrand van den Eeckhout - Public Domain

Wenn es um die Skalierung von agiler Softwareentwicklung geht sind die Gilden in den letzten Jahren zu einem Buzzword geworden an dem kaum jemand vorbeikommt. Fast jedes größere Unternehmen oder Projekt das mehr als fünf Entwicklungsteams umfasst hat mittlerweile mehrere von ihnen, in denen gleichartige Spezialisten zusammengefasst sind. Frontend-Gilden, QA-Gilden, Architektur-Gilden, etc.

Wann genau die Verwendung dieses Begriffs in diesem Kontext angefangen hat ist nicht mehr genau nachzuvollziehen, es dürfte aber innerhalb der letzten zehn Jahre gewesen sein. Zwar gab es auch vorher schon Gruppierungen die sich in Anlehnung an die mittelalterlichen Handwerksvereinigungen Gilden nannten, allerdings waren das noch Zusammenschlüsse von Softwareentwicklern im Allgemeinen, die Spezialisierung auf bestimmte Teilbereiche erfolgte irgendwann in der Zeit danach.

Popularisiert wurde das Konzept schließlich durch das Spotify Model und die Management 3.0-Bewegung, von der auch die heute am weitesten verbreitete Definition stammt. Ihr zufolge ist eine Software-Gilde eine freiwillige Vereinigung von Entwicklern, die sich (wie in einer klassischen Community of Practice) über ihr jeweiliges Spezialthema austauschen, gleichzeitig aber auch Standards und Werkzeuge weiterentwickeln. Das Ziel ist dabei, sowohl die Mitarbeiter als auch die Methoden selbst immer weiter in Richtung Exzellenz zu bewegen und so bessere Produkte zu schaffen.

Der zentrale Unterschied zu Scrum of Scrums und Chaptern ist in der Regel, dass die Gilden nicht das Ziel haben die Arbeitsfortschritte der einzelnen Teams zu koordinieren. Es geht eher um die Weiterentwicklung der "Handwerkskunst" im Allgemeinen, unabhängig vom jeweiligen Produkt- oder Projektkontext. Die Ergebnisse können in die tägliche Arbeit einfliessen, müssen es aber nicht. Und häufig werden sie der Welt als Open Source zur Verfügung gestellt.

Bedingt durch die schnelle Verbreitung und dadurch dass er nicht geschützt oder geregelt ist kann der Begriff der Gilden natürlich auch anders verwendet werden. Gerade in einem eher hierarchischen Umfeld ist er mittlerweile oft als Bezeichnung für klassische Koordinationsgremien anzutreffen, etwa als Testmanagement-Gilde. Derartige Verwendungen sind starke Indikatoren für Cargo Cult und sollten daher am besten intensiv hinterfragt werden.

Story Points

Bild: Publicdomainpictures - CC0 1.0

Es gibt eine Grundsatzdebatte die bei fast jeder Scrum-Einführung aufkommt, und zwar die um die Story Points. Muss das sein? Warum braucht man die? Warum schätzen wir nicht in Personentagen, wie jeder andere auch? Alle diese Fragen sind berechtigt und müssen beantwortet werden wenn diese Methode vom Team akzeptiert und angewandt werden soll. Story Points sind nämlich keineswegs Teil von Scrum, sie sind lediglich eine ursprünglich aus dem Extreme Programming kommende good Practice und können von jedem Team auch weggelassen werden.

Um zu verstehen warum man es zwar kann aber nicht sollte bietet sich ein Gedankenspiel an. Ein Team schätzt eine Anforderung während eines Backlog Refinements und benutzt dabei Personentage als Metrik. Die Schätzung ist aus der Sicht aller Beteiligten auch einigermassen realistisch. In einem der folgenden Sprints beginnt die Umsetzung, jetzt stellt sich aber heraus, dass die geschätzte Zeit nicht stimmt und die Umsetzung deutlich länger oder kürzer dauert. Fast jedes Team wird an dieser Stelle bestätigen, dass es diese Situation aus eigener Erfahrung kennt. Woran kann das liegen?

Ein häufiger Grund ist, dass die einzelnen Teammitglieder unterschiedliche Kenntnisse und Erfahrungswerte in verschiedenen Themengebieten haben, was dazu führt, dass unterschiedliche Personen unterschiedlich lang mit der Umsetzung der selben Aufgabe beschäftigt wären. Jacob bräuchte z.B. sechs Tage für das Implementieren einer Upload-Funktion, Jennifer dagegen nur drei. Da die Aufwandsschätzung aber lediglich den Konsens oder Mittelwert eines Teams darstellt kann sie im Einzelfall nur danebenliegen, bestenfalls um Stunden, schlimmstenfalls um Tage.

Aber kann man dann nicht einfach im voraus festlegen wer welche Aufgabe übernimmt? Im Prinzip ja, allerdings zu einem Preis. Wenn Arbeitspakete von Beginn an einer Person zugeordnet sind nimmt man sich Fexibilität und riskiert, dass diese Person zu einem Flaschenhals werden kann der ggf. alle anderen verzögert. Der Busfaktor (das Risiko, dass der Ausfall einer einzigen Person Auswirkungen auf alle anderen hat) steigt und zuletzt wird es deutlich schwerer die Teammitglieder durch Hands On-Erfahrungen mit neuen Themem in Richtung T-Shape zu entwickeln.

Durch die Nutzung von Story Points kann ein Grossteil dieser negativen Effekte kompensiert werden, und zwar einfach dadurch, dass sie eine neutrale Schätzgrösse bilden. Das Team kann sie weiterhin gemeinsam schätzen, aber der Schätzwert von z.B. fünf Story Points bedeutet dann eben für Jacob sechs Tage und für Jennifer drei. Entgegen einem häufigen Vorurteil muss man dafür auch nicht die Prognosefähigkeit für die nächste Zeit aufgeben, denn in der grossen Zahl mitteln sich die Unterschiede und man kann mit einem Durchschnittswert von Story Points pro Sprint planen, der Velocity.

Es gibt darüber hinaus noch weitere Argumente für Story Points, etwa die Veranlagung des menschlichen Gehirns zum relationalen Schätzen oder die dadurch möglichen Moderationstechniken, wie z.B. Planning Poker. Wenn all das einem Team erklärt wird entscheidet es sich in vielen Fällen von sich aus dafür dauerhaft mit dieser Metrik zu arbeiten, selbst wenn es zu Beginn die oben genannten Fragen gestellt hat.

Bad technology choices can influence your culture

Die agile Coaches dieser Welt werden nicht müde es zu betonen: praktisch alles in der agilen Softwareentwicklung basiert auf der (Unternehmens)Kultur, bzw. auf ihren einzelnen Ausprägungen. Auf Werten, Verhaltensweisen, Überzeugungen und Mindsets. Das ist zwar richtig, verkennt aber einen zentralen Aspekt - die eingesetzten Technologien können auch die Kultur beeinflussen. Tim Gross erklärt in diesem Video Zusammenhänge und Auswirkungen.



Man kann es natürlich auch umgekehrt sehen: wenn die richtige Kultur vorhanden ist wird das automatisch zur Folge haben, dass bestimmte technologische Entscheidungen nicht getroffen oder verworfen werden. Grundsätzlich stimmt das zwar, stellt aber alle Unternehmen vor große Herausforderungen in denen der Kulturwandel gerade stattfindet und ggf. gerade erst begonnen hat. Wenn in einer solchen Situation die falschen technologischen Entscheidungen getroffen (oder nicht korrigiert) werden, dann kann das den Wandel stoppen oder sogar zum Scheitern bringen.

Ein Bild sagt mehr als 1000 Worte (XX)

Diese Grafik liefert die Antwort auf eine immer wieder gestellte Frage: warum soll ein Scrum Team nicht mehr als neun Mitglieder haben? Die Antwort ist die: für schnellen Wissensaustausch und schnelle Entscheidungen muss in selbstorganisierten Teams jeder mit jedem kommunizieren. Ab einer bestimmten Größe würde das zu einer unbeherrschbaren Menge an Kommunikationskanälen führen. Zu sehen hier im Bild.

The challenge with adding more engineers to a project. Just moving from 3 developers to 4 doubles the number of lines of communication. pic.twitter.com/sltsBUVq8w

— Rich Rogers (@RichRogersIoT) 1. Oktober 2017

Es gibt keine Kanban-Rollen - oder doch?

Bild: Pixabay - The Digital Artist - Lizenz

Zu den Fragen die im Rahmen von Kanban-Trainings immer wieder gestellt werden gehört die nach den Rollen die dieses Framework mit sich bringt. Vor allem die nach einem Äquivalent des Scrum Masters taucht immer wieder auf. Die Antwort kann allerdings immer nur sein, dass derartige Rollen in Kanban nicht vorgesehen sind. Das ergibt sich sogar zwangläufig aus seiner Natur, die eine andere ist als die von Scrum.

Scrum ist designt als ein Framework mit dem Zweck der Produktherstellung. Es definiert daher verschiedene Rollen, einen bestimmten Ergebnistyp und klar definierte zeitliche Abläufe, während derer bestimmte Tätigkeiten auszuüben sind um die gewünschten Ergebnisse zu erzielen. Kanban ist im Gegensatz dazu ein Framework mit dem Zweck der Prozessverbesserung, das auf jeden beliebigen bestehenden Prozess aufgesetzt werden kann um ihn nach und nach zu optimieren. Da zu diesen bestehenden Prozessen auch bestehende Rollen gehören können ist es nicht möglich neue Rollen verbindlich zu definieren. Der bestehende Prozess würde dadurch nicht mehr nach und nach optimiert sondern aprubt verändert, was so nicht vorgesehen ist.

Ungeachtet dieser grundsätzlichen Funktionsweisen besteht aber trotzdem eine Konstellation in der die Schaffung von Rollen nötig sein kann. Dann nämlich wenn eine neue Organisationseinheit von Beginn an mit den Kanban-Werzeugen arbeiten soll (Boards, Wertströme, WIP-Limits), und zwar bewusst ohne sich initial an die bisher bestehenden (suboptimalen) Prozesse anzulehnen. Zwar könnte man auch komplett ohne Vorgaben starten und warten bis sich aus dem Chaos Strukturen bilden, der damit verbundene Effektivitäts- oder Effizienzverlust führt aber dazu, dass dieses Vorgehen praktisch nie angewandt wird.

Der zur Zeit populärste Ansatz wurde 2016/2017 unabhängig voneinander von David Anderson und Jeff Sutherland entwickelt und lehnt sich stark an Scrum an. Als Äquivalent zum Scrum Master gibt es auch hier einen Prozessverantwortlichen (Flow Master, Flow Manager oder Delivery Manager), als Äquivalent zum Product Owner ist auch ein Produktverantwortlicher vorgesehen (Service Manager, Product Owner oder Product Manager). Anders als bei Scrum handelt es sich hier um Rollen im eigentlichen Sinn, das heisst sie können ggf. auch von Personen übernommen werden deren eigentliche Jobs ganz andere sind. Auch ein Umsetzungsteam existiert, das aber stärker arbeitsteilig sein kann als in Scrum.

Von elementarer Bedeutung ist, dass auch diese Rollen sich im Rahmen der kontinuierlichen Optimierung verändern, verschwinden oder vermehren  können. Wäre das nicht mehr der Fall gäbe es Teile der Organisation die per Definition nicht optimiert werden dürften. Das aber wäre mit Kanban nicht mehr vereinbar.

Die Zertifizierungs-Tretmühle

Bild: Freegreatpicture / Maxpixel - CC0 1.0

Angekündigt hatte es sich schon im letzten Jahr, seit einigen Tagen steht es auf der Website der Scrum Alliance: die angebotenen Zertifizierungen ändern sich, es werden weitere dazukommen. Die drei Basis-Zertifizierungen für Scrum Master, Product Owner und Developer werden ergänzt um ein Advanced-Level, der bisher rollenübergreifende Scrum Professional wird ebenfalls auf die drei Rollen aufgespalten. Aus bisher vier Zertifizierungen werden so neun¹. Und obwohl ich verstehe warum das so kommt glaube ich nicht, dass das eine gute Entwicklung ist.

Von der geplanten Erweiterung des Zertifizierungsspektrums habe ich zum ersten mal letztes Jahr auf dem Global Scrum Gathering Munich gehört. In den dort stattgefundenen Diskussionen war der Konsens der, dass die bisherigen Zertifizierungen über die Jahre weitgehend entwertet worden sind. In manchen Unternehmen wurde das gesamte mittlere Management geschlossen in die Zertifizierungslehrgänge geschickt, zahllose Freelancer kleben sich das Siegel auf den Lebenslauf um ihre Kunden zu beeindrucken und Schulungsanbieter haben in den dazugehörigen Kursen eine Goldgrube entdeckt.

Bedingt durch diese Inflation beweisen die Zertifikate heute eigentlich nur noch zwei Dinge: a) ihr Inhaber hatte genug Geld für die Prüfungsgebühr und b) er ist in der Lage eine überschaubare Menge an Lernstoff auswendig zu lernen. Das zu ändern und die Zertifikate durch mehr Stoff und mehr Praxiserfahrung aufzuwerten ist zunächst ein nachvollziehbares Anliegen, aber selbst wenn es von der Zielgruppe angenommen werden sollte ist für mich fraglich ob das gesteckte Ziel damit erreicht werden wird.

In den Gesellschaftswissenschaften gibt es den Begriff der Euphemismus-Tretmühle, der besagt, dass jedes neutrale oder positive Wort mit dem man die Benutzung eines negativ geprägten Begriffs umgehen will irgendwann die negative Konnotation seines Vorgängerausdrucks annehmen wird, solange sich die tatsächlichen Verhältnisse nicht verändern. Analog dazu glaube ich, dass wir uns gerade im Prozess einer "Zertifizierungs-Tretmühle" befinden.

Demnach findet im Moment Folgendes statt: eine Zertifizierung hat durch massenhafte Verteilung ihre Aussagekraft verloren und wird darum um eine "höhere Stufe" ergänzt. Auch die erleidet absehbar das selbe Schicksal, weshalb zur "Aufwertung" noch eine Stufe dazukommt, etc. Bereits nach kurzer Zeit wird die verästelte Hierarchie der entstehenden Zertifikate so groß, dass die meisten Menschen den Überblick verlieren². Abgesehen von wenigen Experten weiss keiner mehr was sich im Einzelfall dahinter verbirgt.

Der Effekt ist, dass die Menschen sich am Ende nur noch genervt abwenden wenn das Gespräch auf dieses Thema kommt. Noch einmal eine Parallele zur Euphemismus-Tretmühle: ausserhalb winziger Milieus gilt heute jeder der von "LSBTTIQ-Menschen", "Professorx" oder "Person mit Migrationshintergrund ohne eigene Migrationserfahrung" spricht als weltfremder Wunderling mit dem Unterhaltung eher anstrengend werden. Wer zukünftig den Scrum Master in CSM, A-CSM und CSP-SM unterteilen will dürfte schnell in der selben Schublade landen, und das nicht einmal völlig zu Unrecht.

Nun ja. Wie man hier im Rheinland sagt: Et es wie et es. Mal sehen wie die Sache ausgeht.

¹Dazu kommen die vor kurzem eingeführten Trainer-, Coach- und Leader-Zertifikate, die nochmal ein Thema für sich sind.
²Ich glaube, dass das gerade stattfindet.

Kommentierte Links (XXIX)

Grafik: Pixabay / Geralt - Lizenz

• John Cutler: One Day Sprints

  Ich habe bereits Teams begleiten dürfen deren Anforderungen so klein geschnitten waren (und so klein geschnitten werden konnten), dass sie innerhalb eines Tages zu erledigen waren. Für die hätte man einen solchen Versuch starten können. Der Grund warum ich den meisten aber davon abraten würde ist, dass es bei komplexen Anwendungen und Anwendungslandschaften sehr schwer fallen wird in nur einem Tag ein Increment zu erzeugen, also eine Funktionalität die einen benutzbaren und bestenfalls vermarktbaren Mehrwert erzeugt. Trotzdem - probieren kann man es, etwa indem man es als Experiment für die Dauer eines "normalen" Sprints laufen lässt. Selbst wenn es nicht beibehalten wird - die Überlegungen zum Kleinerschneiden von Requirements sind in jedem Fall eine wertvolle Übung.

• Roman Pichler: Choosing the Right Planning Horizon for Your Product

  Wenn ich als Berater oder Coach in ein Unternehmen komme in dem Scrum/Agile nicht optimal laufen ist die fehlende mittel- und langfristige Planung ein Problem dass fast immer vorliegt. Das was Roman Pichler hier vorstellt ist ein guter Weg damit umzugehen, vor allem weil er nicht nur verschiedene Horizonte/Zeiträume nennt sondern auch Ratschläge gibt in welchen Zeiträumen sie aktualisiert werden sollten. Mein Modell, das ich bei manchen Kunden eingebracht habe, ist in einigen Punkten noch weniger ausformuliert, gegebenenfalls werde ich das eine oder andere von Pichler übernehmen.
  

• Stephan Grabmeier: Heterogene Teams bilden und führen – Diversity Faultline

Mit Sollbruchstellen in Teams habe ich auch schon Erfahrungen machen dürfen, besonders mit einer die Stephan Grabmeier gar nicht beschreibt: der zwischen internen und externen Mitarbeitern. Selbst wenn es nach Klischee klingt - alleine durch die häufigen Wechsel von Unternehmenskulturen, angewandten Technologien und Produkten sind externe Entwickler häufig flexibler, offener umd umfassender qualifiziert als interne, die seit Jahren oder Jahrzehnten in der gleichen Abteilung an der gleichen Anwendung arbeiten. Hier einen Ausgleich zu finden und Team Spirit zu fördern kann eine Herausforderung sein.

• Robert Galen: Agile Leadership – Eating our own Dogfood

  Was diesem Artikel zugrundeliegt ist ein grundsätzliches Problem: (Change)Manager haben häufig bessere Arbeitsbedingungen als "normale" Mitarbeiter. Bessere Hardware, bessere Software, weniger Vorschriften, weniger Deadlines, etc. Die Implementierung neuer Arbeitsweisen wird daher von ihnen häufig als einfacher empfunden als von den Entwicklungsteams. Um die "Schmerzen des Übergangs" nachvollziehbar zu machen empfiehlt es sich daher, die neuen Regeln auch auf die Change-Manager selbst anzuwenden. Die besten Change-Teams die ich erleben durfte (die auch die höchste Akzeptanz durch die Entwicklungsteams hatten) waren die, die selbst nach Scrum oder Kanban gearbeitet haben.

• Adam Henshall: How to Build an MVP App Without Writing Code

  Es ist einer der zentralen Painpoints bei Teams oder Unternehmen die sich an Design Thinking oder Lean Startup versuchen. Entweder hat bei Prototypen und MVPs ein "Dumbing down" bis zu einem fast schon albernen Level stattgefunden (z.B. wird der Testgruppe ein mit Buntstiften auf Papier gemalter Website-Entwurf vorgelegt um Feedback zur Usability zu erhalten) oder es ist bereits soviel Arbeit und Geld in ihn geflossen, dass das Verwerfen zu einem schmerzhaften Schritt wird ("das darf nicht alles umsonst gewesen sein!"). Adam Henshall bietet einige gute Werkzeuge um dieser Situation auszuweichen und mit sehr geringem Aufwand vorzeigbare und benutzbare Ergebnisse zu erstellen, die man im Zweifel auch ohne Bauchschmerzen wieder verwerfen kann.