Delivering twice the value at half the cost

Bild: Flickr / Peter Linke - CC0 1.0

Einmal mehr hat sich der bekannteste Sales-Pitch von Scrum beinahe unbemerkt geändert. Bereits 2018 schwenkte Jeff Sutherland, der Verfasser von Doing twice the work in half the time um auf Delivering twice the value in half the time, aber auch das ist mittlerweile nicht mehr der neueste Stand. Der ist seit gestern Delivering twice the value at half the cost. Man kann das begrüssen, ähnlich wie die letzte hat auch diese Neuformulierung das Potential weniger missverständlich zu sein.

Da die bisherigen Formulierung nur in ihrem hinteren Teil verändert wurde soll es hier nur um den gehen (zum ersten Teil siehe hier), und zwar zunächst um die alte Version. Liefert Scrum tatsächlich in der Hälfte der Zeit? Die Antwort: nicht zwingend, genau das ist es was missverständlich ist. Ein Vergleich der unterschiedlichen Ansätze zeigt warum.

Zuerst zu Scrum: sein Anspruch ist, durch bessere Strukturen und Prozesse in kurzer Zeit lieferfähig sein. Zum einen bedeuten crossfunktionale Teams weniger Übergaben und weniger Koordinationsaufwand, zum anderen kann die Integration der Abnahme-, Integrations- und Regressionstests in jeden einzelnen Sprint die vor dem Projektende stattfindende Integrations- und Bugfixing-Phase entfallen lassen. Zusätzlich verhindert das schnelle Beheben der Fehler, dass diese sich gegenseitig verstärken und dadurch aufwändiger zu beheben sind. So verkürzt sich die Gesamtlaufzeit, wodurch das ursprüngliche Versprechen in half the time zustande kam.

Auf der anderen Seite stimmt aber auch: klassisches Projektmanagement kann "ambitionierte Lieferfristen" ebenfalls immer wieder erreichen, und zwar mit einer einfachen Massnahme. Diese besteht darin, dass zur Erreichung der gesetzten Ziele mehr Personal in das Projekt gepumpt wird¹. Mit mehr Leuten kann dann versucht werden mehr zu schaffen, entweder durch parallele Arbeit gleichartiger Teams oder durch ein überlappendes Vorgehen der Teams die den unterschiedlichen Phasen zugeordnet sind. Es bleibt daher die Frage - wenn beide Ansätze schnell liefern können, macht der Umstieg auf Scrum überhaupt einen Unterschied?

Dass die Antwort darauf Ja ist liegt in den entstehenden Kosten begründet. Die Faktoren die in Scrum zu schnellem Arbeitsfortschritt beitragen sind im Gegensatz zum klassischen Projektmanagement nicht mit zusätzlichem Personalaufwand verbunden. Da dieser aber gleichbedeutend mit zusätzlichen Ausgaben ist bedeutet das, dass die Entwicklung im Vergleich billiger ist. Für praktisch jedes Vorhaben dürfte das ein wesentliches Argument sein, das Budget ist schliesslich in jedem Vorgehen ein entscheidender Faktor. Und damit erklärt sich auch die Sinnhaftigkeit der neuen Formulierung Delivering twice the value at half the cost.


¹Dass dieses Vogehen zu anderen Problemen führen kann ist nochmal ein Thema für sich

Toyota Flow System

Manchmal kommen grosse Neuigkeiten überraschend an. In einem zunächst eher unspektakulären Artikel erwähnt der Forbes-Journalist Steve Denning etwas Bemerkenswertes: nach 70 Jahren hat die Firma Toyota ihr legendäres Toyota Production System (den Ursprung des Lean Management) weiterentwickelt zu etwas Neuem, dem Toyota Flow System. Der Name ist fast gleich geblieben, der Inhalt dagegen hat sich spürbar verändert - es finden sich jetzt deutliche Spuren agiler Frameworks in ihm.

Grafik: Toyota Connected / Thurlow, Turner, Rivera - CC BY 4.0 (zum Vergrößern klicken)

Vor allem in der linken Säule taucht einiges auf was aus der agilen Welt bekannt ist. Scrum, the Toyota Way hat bereits 2018 für Aufsehen gesorgt, und auch andere bekannte Konzepte finden sich hier, etwa Cynefin und OODA-Loops. Die mittlere Säule greift eher Ideen aus dem Coaching-Umfeld auf, wie z.B. psychologische Sicherheit, aktives Zuhören und Mentoring, während die rechte Säule sich auf die sozialpsychologischen und organisatorischen Aspekte der Teamarbeit konzentriert. Zusammen mit den beiden Grundlagen Toyota Way und Toyota Production System kommt ein Gesamtbild zu Stande, dessen Einzelbestandteile es ermöglichen genug Lesestoff für Wochen zusammenzugoogeln. Auf jeden Fall spannend.

Frameworks und Werte

Bild: Wikimedia Commons / ChinaFlag - CC0 1.0

Wer schon einmal in einem Workshop war in dem es darum ging agile Vorgehensmodelle zu erklären oder ihre Einführung vorzubereiten wird dort mit grosser Wahrscheinlichkeit auch über Werte gesprochen haben. Egal ob Extreme Programming (Communication, Simplicity, Feedback, Courage,  Respect), Scrum (Courage, Commitment, Focus, Openness, Respect) oder Kanban (Transparency, Balance, Collaboration, Customer Focus, Flow, Leadership, Understanding, Agreement, Respect) - jedes bekannte Framework betont, dass es wertebasiert ist. Aber warum ist das so?

Die Antwort hat mit genau dieser Selbstbezeichnung zu tun. XP, Scrum & Co legen Wert darauf keine Methoden zu sein sondern Frameworks, wohinter sich ein völlig anderes Konzept verbirgt. Während durch Methoden relativ genaue Vorgaben erfolgen wer wann was mit welchem Ziel zu tun hat wollen die agilen Frameworks genau das vermeiden. Die darunterliegende Annahme: je strikter die Vorgaben desto unwahrscheinlicher, dass sie der komplexen Realität gerecht werden. Im Zweifel schaden sie sogar mehr als sie nutzen, da plötzlich der Plan nicht mehr zur Realität passt.

Um derartige Konstellationen zu vermeiden lassen die Frameworks bewusst grosse Lücken, die jeder so füllen kann wie er es für sinnvoll hält. Beispiele dafür sind Anforderungsformate und die Abnahmen fertiger Arbeit: XP, Scrum und Kanban gehen nicht darauf ein wie sie ausgestaltet sein sollen, jedes Team kann das für sich selbst festlegen. Das daraus entstehende Problem - diese Offenheit bringt das Risiko mit sich, dass versehentlich unflexible und bürokratische Strukturen (wieder)eingeführt werden, etwa indem besonders detaillierte Spezifikationen möglichst früh im voraus verfasst werden, die dann zu erfüllen sind.

Die Lösung für dieses Dilemma sind die zu Beginn genannten Werte. Sich im Zweifel an ihnen zu orientieren lässt den Beteiligten genug Freiraum um den Arbeitsprozess nach ihren Bedürfnissen auszugestalten, zeigt ihnen aber auch wo sie sich von der angestrebten Agilität entfernen. Um beim Beispiel der Abnahmen anhand von lange im voraus verfassten Detailspezifikationen zu bleiben - wer ernsthaft Simplicity, Openness und Balance als Werte verfolgt wird sich von diesem Vorgehen schnell verabschieden.

Um zuletzt einen häufigen Einwand aufzugreifen: natürlich bedeutet das auch, dass der Arbeitsprozess weniger stabil ist und häufiger geändert werden muss, nämlich immer dann wenn er sich aufgrund geänderter Realität plötzlich im Widerspruch zu den Werten befindet. Aber das ist etwas Gutes - es verhindert, dass die Menschen durch unnötige Vorgaben eingeengt werden.

Die agile Filterblase

Bild: Flickr / Serge Melki - CC BY 2.0

Eine Frage die beim letzten bonner Scrumtisch intensiv diskutiert wurde war die: "Befindet sich die agile Community in einer Filterblase?" Natürlich lautet die Antwort im Zweifel immer "Kommt darauf an", aber ganz von der Hand zu weisen ist es nicht - eine Abkapselungstendenz ist da. In dem Punkt waren sich die Teilnehmer einig.

Zunächst zur Begrifflichkeit. Filterblasen sind ein Konzept aus der Kommunikationswissenschaft in dem davon ausgegangen wird, dass durch technische Mechanismen (personalisierte Suchmaschinen) bewussten Medienkonsum (Echokammer) oder unbewusste psychologische Vorgänge (Confirmation Bias) vor allem die Informationen wahrgenommen werden die die eigene Meinung bestätigen. Abweichende Ansichten werden ausgeblendet.

Auf die agile Community übertragen erkennt man deutliche Züge von Filterblasenhaftigkeit. Die bekannteren Agilisten gehen auf die gleichen Konferenzen, lesen die gleichen Autoren, hören die gleichen Podcasts, abonnieren die gleichen Youtube-Kanäle, folgen sich gegenseitig auf Twitter und Facebook und kennen sich untereinander schon seit Jahren. Das lässt sich sowohl auf der internationalen als auch auf der nationalen und lokalen Ebene beobachten und zeigt sich daran, dass viele der eigentlich fachlichen Zusammenkünfte mittlerweise einen Klassentreffen-Charakter haben.

Die damit verbundenen Effekte sind bedenklich: bestimmte Glaubenssätze werden kaum noch hinterfragt (z.B. "mittleres Management ist überflüssig"), bestimmte Vorzeigeunternehmen wie Spotify werden gehypt während andere wie Mercadona trotz hochinnovativer Ansätze nahezu unbekannt sind, die Berührungspunkte zu verwandten Disziplinen wie dem klassischen Projektmanagement nehmen ab, wichtige Themenfelder wie Finance oder Legal werden weitgehend ignoriert.

Das zu ändern liegt bei jedem Einzelnen selbst. Warum nicht mal auf eine Projektmanagement-Konferenz gehen, ein BWL-Buch lesen oder sich mit Lean Manufacturing beschäftigen? Und wenn das zu weit ausserhalb der eigenen Komfortzone ist - warum nicht auf dem nächsten Agile Meetup ein ungewohntes Thema einbringen wie Compliance, Budgeting oder Procurement? Das würde nicht nur zur Weitung des eigenen Horizonts führen sondern auch neue Teilnehmer anlocken. Auch so liesse sich die agile Filterblase öffnen.

ScrumBut und ScrumAnd

Bild: Flickr / David Molloy - CC BY 2.0

So schlicht Scrum auch ist, so viel kann man bei seiner Umsetzung falsch machen. Das meiste davon dürfte unbewusst passieren und den Handelnden gar nicht bewusst sein, also in die Kategorie fallen für die sich der schöne Name Cargo Cult eingebürgert hat. Es gibt aber auch Fälle in denen absichtlich am Vorgehen herumgedoktort wurde. Auch für die beiden hierbei möglichen Varianten gibt es mittlerweile Bezeichnungen: ScrumBut und ScrumAnd.

ScrumBut ist abgeleitet von der Aussage "We do Scrum, but ...", also "Wir machen zwar Scrum, aber ...". Hinter diesem "aber" verbergen sich dann die Einschränkungen denen das Vorgehen unterworfen wurde. "Wir machen zwar Scrum, aber nur auf Teamebene.", "Wir machen zwar Scrum, aber ohne Scrum Master." oder "Wir machen zwar Scrum, aber nur für die IT." sind klassische ScrumBut-Aussagen, wie man sie überall dort wiederfinden kann wo vor einer wirklichen Einführung zurückgeschreckt wurde.

Das irritierende an dieser Variante - selbst bei offensichtlich eingeschränktem Umfang bleiben die an Scrum gerichteten Ansprüche meistens unverändert hoch. Dass auch diese proportional zum Rückbau der Methode sinken müssten wird selten eingesehen, und selbst wenn es erkannt wird kann eine überzogene Erwartungshaltung dazu führen, dass eine ernsthafte Organisationsveränderung blockiert wird. "Das soll erstmal auf Teamebene für Verbesserung sorgen bevor wir es woanders einführen" entspricht etwa der Aussage "Die Glühbirne soll erstmal zeigen, dass sie Licht machen kann, bevor sie Strom bekommt." Kann man so sehen, bringt einen aber nicht weiter.

ScrumAnd geht dagegen ist die genau andere Richtung: Scrum wird zwar wie vorgesehen eingeführt (zumindest weitgehend), gleichzeitig aber mit zusätzlichen Inhalten überfrachtet. Ein Beispiel dafür wäre ein Geschäftsführer, der zusätzlich die Rolle eines Product Owners übernimmt (und aus Zeitmangel fast alle damit verbundenen Tätigkeiten ins Team delegiert). Ein anderes Beispiel wäre die Integration so vieler Randaspekte in die Produktentwicklung (Werbekampagnen, First Level Support, etc.), dass das Team kaum noch focussiert arbeiten kann.

Rein formal lässt sich gegen diese Auslegung in vielen Fällen nichts sagen, der Scrum Guide erwähnt zwar nichts Derartiges, untersagt es aber auch nicht. In der Realität führt eine solche Überladung erfahrungsgemäss aber fast immer zu Reibungsverlusten, Zielkonflikten und Motivationsrückgang. Gleichzeitig kann es auch im Fall von ScrumAnd zu unrealistischen Erwartungshaltungen kommen. "Aber in den Regeln steht doch, dass der PO delegieren darf und dass dass Team crossfunktional sein muss." wäre eine klassische Begründung dafür, auch in solchen Konstellationen reibungslose Performance zu erwarten.

Sowohl bei ScrumAnd als auch im Fall von ScrumBut sind die Erwartungshaltungen auch der Punkt an dem angesetzt werden sollte um an Verbesserungen zu arbeiten. Dass stark beschnittene oder überfrachtete Vorgehensweisen ihre positiven Effekte nicht voll entfalten können wird fast jeder nachvollziehen können, wer an diesen Effekten interessiert ist wird daher erkennen, dass er ein Zurückfahren der Missstände zumindest erwägen muss. Und wer von den alten Strukturen und breiten Aufgabenspektren nicht ablassen kann (wofür es gute Gründe geben kann) dem kann man vermitteln, dass Scrum seinen Ansprüchen nicht genügen wird und er einen anderen Ansatz ausprobieren sollte.

Dass auch ein anderer Ansatz mit hoher Wahrscheinlichkeit an diesen Ansprüchen scheitern dürfte steht dann auf einem anderen Blatt, hat aber mit den beiden hier beschriebenen Scrum-Antipattern nichts mehr zu tun.

Die fünf Zeitdiebe

Die Ähnlichkeit zwischen den fünf Zeitdieben und den Mudas des Toyota Production System dürfte kein Zufall sein, beiden ist die Herkunft aus dem Lean Thinking deutlich anzumerken. Dementsprechend präsentiert Dominica DeGrandis hier nichts völlig Neues, betrachtet einige Aspekte aber aus einem neuen Blickwinkel.

Kommentierte Links (LIII)

• Troy Magennis - Story Point Velocity or Throughput Forecasting: Does it matter?

In Bezug auf das in der (IT-)Kanban-Bewegung beliebte statistikbasierte Forecasting bin ich gleichermassen Fan und Skeptiker. Natürlich hat eine auf der Story Point-Velocity beruhende Planung grosse Schwächen, von denen Troy Magennis hier einige aufzählt. Zu beachten ist dabei aber: er geht von nicht-idealen agilen Teams aus, die aufgrund nicht gegebener Crossfunktionalität und fehlender Focussierung starke Abhängigkeiten nach aussen haben. Das ist zwar durchaus realistisch, völlig unabhängige Teams sind selten. Umgekehrt wird aber bei dem als Alternative vorgeschlagenen Durchsatz-Modell nicht erwähnt, dass auch das ideale Rahmenbedingungen braucht, z.B. ein stabiles System, in dem Arbeiten nicht abgebrochen werden und in dem das Leistungsvermögen der Teams nicht schwankt. Auch das ist in der Realität aber selten. Ein bisschen wird hier also mit ungleichem Mass gemessen. Letzten Endes gilt für beide Ansätze, dass sie Unplanbares nicht planbar machen können, weshalb man sich von Anfang an auf Planänderungen einstellen sollte.

• François Knuchel: Why aren’t Lean and Agile Collaborating?

  Mal wieder ein Artikel über die absoluten Basics. Die Unterschiede zwischen Agile und Lean dürften zwar schon oft erörtert worden sein, vermutlich aber selten so ausführlich wie hier von François Knuchel. Neben den offensichtlichen Besonderheiten arbeitet er auch einige heraus die in den meisten Betrachtungen untergehen, z.B. das Agile-Kanban ein eher linearer Prozess einzigartiger Einzelaufgaben ist, während Lean-Kanban aus wiederkehrenden Schleifen gleichartiger Arbeit besteht. Auch die Beobachtung, dass Agile aufgrund der Affinität zu IT und Open Source eine offenere Community hat als Lean ist ein interessanter Gedanke, vor allem in Verbindung mit der Hypothese, dass das eine Ursache der im Vergleich stärkeren Sichtbarkeit und Verbreitung ist. Wirklich zum Nachdenken anregend ist aber die Vermutung, dass die beiden Bewegungen sich kaum austauschen, weil sie sich zu parallelen Silo-Strukturen entwickelt haben. Damit wären sie genau da gelandet wo sie nicht hinwollen.
  

• Mark Lambertz: Matrjoschkas und das Prinzip der losen Kopplung

  Noch mehr zum Nachdenken. Wie oben in anderem Zusammenhang hervorgehoben wurde geht auch Mark Lamberts davon aus, dass Teams mit zu grossen Abhängigkeiten letztendlich nicht agil sein können. Sein Betrachtungsschwerpunkt liegt dabei allerdings nicht auf den "horizontalen Abhängigkeiten" von anderen Teams sondern auf den "vertikalen Abhängigkeiten" von höheren Hierarchiestufen. Konkret geht es um die von dort vorgegebenen globalen Aufgabenschnitte, aus denen die unteren Ebenen ihre lokalen Aufgabenschnitte ableiten müssen. Dass das Selbstorganisation hemmt ist offensichtlich, dass es irgendwie zu einem Zusammenwirken aller beteiligten Einheiten kommen muss aber auch. Mark Lamberts' Idee von "lebensfähigen Systemen, welche in ein übergeordnetes lebensfähiges System eingebettet sind" ist ein interessanter Ansatz um diesen Widerspruch aufzulösen, dürfte aber in der Umsetzung sehr anspruchsvoll sein.

• Stefan Kraus: Selbstorganisation im Arbeitsbereich „Bauhof“ des Amtes für Technik, Umwelt, Grün (TUG) der Stadt Herrenberg

  Den Blog des "Forum agile Verwaltung" mag ich sehr, da sich hier immer wieder Beispiele für Flexibilität und Selbstorganisation finden die weit aus der üblichen IT- und Projektmanagement-Blase herausführen. Alleine der bürokratische Titel der hier vorgestellten Behörde würde normalerweise dafür sorgen, dass es ohne nähere Betrachtung in eine der üblichen Klischee-Schubladen einsortiert wird. Nach der Vorstellung der dort eingeführten Arbeitsweisen sieht man dagegen einmal mehr Agilität dort wo man sie nicht vermutet. Und besonders bemerkenswert: hier wurde nicht irgendein bekanntes Framework eingeführt sondern ein eigenes Vorgehensmodell selbst entwickelt.

• Oliver Staley: Whatever happened to Six Sigma?

  Eine Vorstellung von dem was manche Kritiker der agilen Bewegung voraussagen bietet das Schicksal von Six Sigma. Einst ähnlich gehypt ist mittlerweile nicht mehr viel davon übriggebliebben. Die von Oliver Staley genannten Ursachen sind auch tatsächlich die, die gerade bei Scrum, SAFe & Co zunehmend zu betrachten sind: Kommerzialisierung, Hype-getriebene Anwendung auf unpassende Bereiche, Wahrnehmung als Mode-Erscheinung. Dass Agile den selben Weg gehen wird ist nicht zwangsläufig, ein warnendes Beispiel für das was schlimmstenfalls passieren könnte ist Six Sigma aber auf jeden Fall.

Deine Muda: Langfristige Detailplanung

Grafik: Pxhere / Mohamed Hassan - CC0 1.0

Neunter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: die langfristige Detailplanung.

Warum langfristige Detailplanung eine Muda ist, ist einfach zu erklären: überall dort wo Arbeit in einer komplexen Umgebung stattfindet (→ dort wo sich Menschen uns Systeme unvorhersehbar verhalten und auf unvorhersehbare Art und Weise mit einander interagieren¹) wird die Realität früher oder später zwangsläufig von der Planung abweichen. Sobald das geschieht müssen die Pläne an die geänderte Realität angepasst werden, wodurch die bisherige Planung automatisch obsolet wird.² Die bereits in sie investierten Aufwände waren umsonst.

Die Alternative zu diesem Vorgehen kommt ebenfalls aus dem Toyota Production System: Just in Time Delivery, oder für diesen Verwendungszweck abgewandelt: Just in Time Planning. Detailplanung sollte nur in überschaubarem zeitlichen Abstand zur Umsetzung stattfinden, da proportional zum diesem kürzer werdendem Abstand die Wahrscheinlichkeit sich ändernder Rahmenbedingungen abnimmt. Das Risiko für die Tonne zu arbeiten lässt sich so minimeren (um Missverständnissen vorzubeugen: das bedeutet keine Planlosigkeit, aber an die Stelle der Detailplanung tritt eine Vision).

Das Problem bei der Abschaffung der langfristigen Detailplanung: viele grosse Organisationen haben ihre gesamte Planungs- und Reportingstruktur auf sie ausgerichtet. Noch immer herrscht in ihnen der Glaube vor, dass man nur gut genug vorausdenken müsste um alle Eventualitäten zu berücksichtigen, und ein Abweichen von diesen Glaubenssätzen wird ignoriert oder sanktioniert (siehe auch die Antipattern der scheinbaren Imitation und der scheinbar umfassenden Planung). Für eine Verhaltensänderung ist also viel Überzeugungsarbeit nötig.

Einen Ausweg aus dieser Situation bietet - Ironie der Geschichte - ausgerechnet das meistens mit langfristiger Detailplanung einhergehende langfristige Detailreporting. Überall dort wo jeder einzelne Konzeptions-, Umsetzungs- und Testaufwand erfasst, festgehalten und mit einer Buchungsnummer versehen ist kann man problemlos aufzeigen wie viel Arbeitszeit (und damit Geld) sinnlos ausgegeben wurde, weil die Realität nicht mehr zum Plan passt. Die Muda wird damit sichtbar und messbar - und so zu einem gewichtigen Argument um an Veränderungen zu arbeiten.


¹Es gibt natürlich auch nicht-komplexe Umgebungen, aber um die soll es hier nicht gehen.
²In manchen Organisationen wird stattdessen versucht die Realität an die Planung anzupassen. Ein Thema für sich.