Melting-Pot – Agile Defekte thumbnail 1

Verd-(st)ecktes Business Theater – gewinnt

  • Agiles Mimikry: Schmuse-Scrum, Kuschel-Kanban (die Konformität ist der Tod der Agilität … oder Opportunität begünstigt (Business-) Protektionismus bis zum Perfektionismus – aber nicht Agilität)
  • und warum Business Theater gut im im Kurs ist (also halbw(g)ahre Lippenbekenntnisse – vielleicht genau die falsche Hälfte)

„Wer nicht wiederspricht, fliegt raus. (Bitte nochmal lesen …)“ ist kein Illusion, sondern eine Maxime von Ray Dalio, Gründer eines der erfolgreichsten, aber umstrittenen Fonds-Unternehmen – Dalio hat noch weitaus mehr derartiger, teils sehr provokanter Prinzipien aufgestellt. Doch halt (und Warnung): Nicht alle (ein Liste aller 210 habe ich, hehe …) sind grundsätzlich für jeden nutz- und anwendbar – Es ist aber sinnvoll, diese einmal zu hören (und sie dann kritisch zu reflektieren, ob diese für einen selbst oder andere anwendbar sind). Es geht um etwas ganz einfaches und eine anspruchsvolle These: „Mit Schmuse-Scrum und Kuschel-Kanban ist opportune Konformität der Tod der Agilität.“ Tauchen wir tiefer ein, hören und sehen genau hin (Kinder können das besser) – es wird spannend.

Schmuse-Scrum / Kuschel-Kanban im Konformismus

Ich habe in den letzten Jahren etwas beunruhigendes in Teams, mit denen ich gearbeitet habe, bemerkt. Es ist eine rückfällige Tendenz, einen iterativen Wasserfallprozess zu erstellen und ihn dann agil zu nennen. Angeblich soll dann auch „sichtbar“ Agilität drin sein, in dem die Blöcke schneller iterieren – das wird dann auch irgendwie dargestellt und sieht dann (als iterativer Wasserfall) so in etwa aus:

In einem Sprint ermittelt jemand (z.B. ein Business-Analyst, der mit einem Product Owner zusammenarbeitet), was erstellt werden soll. Agilität kann ich weder innerhalb noch ausserhalb sehen. Können Sie mir hier die Stelle zeigen? Nur einen agilen Kringel rein zu malen – ist es wohl nicht.

Alles zusammen ist nicht Scrum – in einem Feld ist es möglich

Der Business-Analyst und der PO versuchen, agil zu sein. Schnell sind die ersten User Stories mit vielen Konjunktiven geschrieben und in ein Backlog gepackt. Aber anstatt die User Stories als kurze Platzhalter für zukünftige Konversationen zu behandeln, wird jede User Story zu einem ausgefeiltem Mini-Spezifikationsdokument, vielleicht drei bis fünf Seiten, auch länger, zusammen fabuliert. Diese Mini-Specs / User Stories dokumentieren nahezu alles, was man sich in und über eine User Story vorstellen kann. Der (End-) Kunde kommt darin kaum vor. Warum? Weil man das doch so macht – und weil Stakeholder immer weniger bereit sind, Ungewissheiten zu akzeptieren. Und wegen der Abhängigkeiten … Und weil der Chef / Projektleiter / Stakeholder das genau so sehen möchte … Konformismus? Cargo-Cult?

Das erfordert dann einen vollständigen Sprint, bis man alles zusammen hat. Der nächste Sprint wird angesetzt, um danach herauszufinden und zu dokumentieren, wie die Gestaltung der Benutzerschnittstelle auszusehen hat. Das Team versucht an dieser Stelle, etwas agiler zu werden (in ihren Köpfen), indem es die Designarbeit ein wenig vor der Fertigstellung der Mini-Specs für die erste User Story beginnt.

Oh, gefährlich – unsicher! Die Spezifikationen sind noch nicht vollständig ausgereift und Mut zur Lücke (mit dem einhergehenden Bewusstsein des Paradigmenwechsels in der Fehlerkultur) wurde vom Chef / Projektleiter / Stakeholder geflissentlich „ausgelassen“. „Nur keine Fehler sind gute Fehler …“ – ist reine Konformität – und der Tod der Agilität.

Kann es sein, dass Stakeholder immer weniger bereits sind, Schätzungen und Ungewissheiten zu akzeptieren? Und: Woran liegt es?? Jeder (Stakeholder) ist gut beraten, das nachstehende Bild zu verinnerlichen.

PDCA – nur anders dargestellt

Das Bild als solches wird ihm noch nicht helfen, aber das genaue lesen und verorten der eigenen Themen in einem der 4 Felder hilft Ihnen weiter.

Machen wir weiter: Die Programmierer erhalten dann ein paar Dokumente. Ein Entwickler zeigt genau, wie die User Story aussehen sollte, wenn sie implementiert wird, und der andere liefert alle Details über das Verhalten der Story. Aber die eigentliche Programmierung kann erst beginnen, bis diese zwei Artefakte bereit sind. In einigen Unternehmen sind es die Programmierer selbst, die diese Art der Arbeit fordern. Sie sagen, dass sie alles bauen werden, was gefragt wird, erwarten aber (vorher) genau, was zu Beginn der Programmierung benötigt wird. Weil: Sie wollen weder Fehler noch Blinleistungen produzieren und dafür noch Schelte bekommen. Einfach mal loslaufen ist somit etwas ganz anderes. Auch hier ist eine geringe Fehlerakzeptanz (neben der Fehlertoleranz) zu erkennen.

Einige Organisationen handhaben und dehnen die Dinge dann noch weiter aus, indem sie die Tester eine Iteration zeitlich hinter den Programmierern anordnen bzw. diese ausführen lassen. Das passiert, weil die User Storys eines Teams immer größer und größer werden, wenn jede Story eine komplette Mini-Spezifikation und ein vollständiges UI-Design enthalten muss, bevor sie codiert werden kann. Es ist also wie ein Krebsgeschwür: es wuchert vor sich hin und erstickt den agilen Ansatz.

Glücklicherweise erkennen die meisten Teams, dass Programmierer und Tester in der gleichen Iteration zusammenarbeiten müssen, aber nicht, dass ein ganzes Team zusammenarbeitet. Dies führt zu dem in dieser obigen Figur gezeigten Prozess.

Die nachstehende Abbildung zeigt eine erste Iteration, die der Analyse gewidmet ist. Eine zweite Iteration (möglicherweise leicht überlappend mit der ersten) wird dem User Experience Design und Definition gewidmet. Und dann ist eine dritte und vierte Iteration dem Entwurf, Codieren und Implementieren und anschliessendem Testen gewidmet. Das ist nicht agil. Es könnte der erste Schritt Ihrer Organisation sein, agil zu werden. Aber es ist nicht agil, sondern ein schöner, iterativer Wasserfall.

Ein klarer, iterativer Wasserfall – nur iterativ verkürzt.

In der traditionellen Entwicklung eines vollständigen Wasserfalls führt ein Team zuerst die gesamte Analyse für das gesamte Projekt durch. Dann machen sie das ganze Design für das gesamte Projekt. Dann machen sie die gesamte Codierung für das gesamte Projekt. Dann machen sie alle Tests für das gesamte Projekt. Und dann stellen Sie fest, dass der Kunde etwas anderes haben wollte oder sich die Welt um das Projekt derart geändert hat, dass die Arbeit vom Ablauf her zwar hochkonform (aus alter Lehre), aber ergebnistechnisch für den Müll war. Hier möchte ich ergänzend und deutlch klarstellen, dass es nach wie vor Projekte gibt, die mit dem Wasserfall-Modell realisiert werden müssen, weil die Lehre noch kein probates (Ersatz-) Mittel (z.B. wenn äußere Sachzwänge das erfordern) gefunden hat.

Im Idealfall würden in einem agilen Prozess alle Arten von Arbeiten genau zur gleichen Zeit beendet. Das Team würde die Analyse des Problems genau zu dem Zeitpunkt abschließen, zu dem sie die Lösung für das Problem entworfen haben. Dies wäre auch gleichzeitig mit der Codierung und dem Testen dieser Lösung. Alle fünf dieser Disziplinen (und alle anderen, die ich in diesem Beispiel nicht verwende) würden alle genau zur selben Zeit enden.

Es ist etwas naiv, anzunehmen, dass ein Team das immer perfekt erreichen kann. (Aber es geht.) Es kann das Ziel bleiben, auf das ein Team hinarbeiten kann. Ein Team sollte immer daran arbeiten, die Arbeit so weit wie möglich zu überlappen. Und vorausschauendes Denken (Analyse, Design und andere Arten von Arbeit) sollte so spät wie möglich und so wenig Details wie möglich erfolgen, während die Arbeit innerhalb der Iteration noch finalisiert werden kann. Wenn Sie also Ihre User Stories als Miniatur- Specs behandeln – hören Sie auf damit! Fangen Sie stattdessen an, darüber nachzudenken, jede Story als ein Versprechen zu sehen, dass hier noch eine eine Unterhaltung geführt werden muss. Denken Sie kleinteiliger und überschaubarer und so werden nicht die Programmierer schneller (mehr Tastenanschläge pro Minute = Irrsinn), sondern die Liefergeschwindigkeit wird kleinteiliger. Tauschen Sie sich kürzer, on Demand, aus.

So könnten die einzelnen Entwicklungsstufen aussehen

Fühlen Sie sich frei, Notizen zu einigen Geschichten hinzuzufügen, über Dinge, die Sie während dieser Konversation aufrufen möchten. Das Hinzufügen dieser Notizen sollte jedoch ein optionaler Schritt und kein obligatorischer Schritt in einem sequenziellen Prozess sein. Ganz wichtig: Nehmen Sie sich Zeit, Ihre „Unterhaltungsversprechen“ regelmässig zu betrachten und immer dann, wenn Sie zielführenden Content zu dieser Story haben, diesen auch gleich hinzuzufügen und auch mit den Programmierern darüber zu sprechen. Wenn Sie das alle und auch die Programmierer optional lassen, wird der Prozess nicht zu einem iterativen Wasserfallprozess und der Prozess bleibt agil. Alles andere ist:

Agiles TTV, also Mimicry

Dieses Verhalten erinnert mich an den Bio-Unterricht. Kennen Sie noch Mimicry und Mimese? Also: „So tun, als ob?“ Beides ausgebuffte Methoden der Natur, um das Überleben von Flora und Fauna durch Täuschen und Tarnen wahrscheinlicher zu machen. (TTV: = täuschen, tarnen und verp….. ) Das ist dann auch der Grund, warum einige Manager immer wieder die Worte Agile, Scrum, Kanban, Lean und Leadership in Präsentationen, Vorträgen und Meetings einpflastern, ohne dabei wirklich verstanden zu haben, worum es geht. So soll vielleicht gezeigt werden, dass sie sich mit der agilen Transition auskennen und am Puls der Zeit agieren. Und da das alles tolle Buzzwords sind (Geiles Business Theater), stimmen alle mit ein (so ein schöner, konformer Cargo-Cult …).

Aus den gleichen Gründen rücken sich vielleicht auch Teams und ganze Firmen (un-)bewusst in die agile Ecke? Agile Arbeitsweisen werden schließlich als Qualitätsmerkmal und von immer mehr Menschen schon als Voraussetzung für ihren Arbeitsplatz angesehen und gelten als Wettbewerbsvorteil auf dem hart umkämpften Markt für Fachkräfte. Das Sprechen wird angepasst, bis zur kommunikativen Körperverletzung, aus verschiedensten Gründen werden Rituale (nur) scheinbar eingehalten und Artefakte ausgehöhlt (siehe Shu-Ha-Ri und ScrumButs). Auf den ersten Blick sieht nach außen alles schön agil aus, der eigentlich Zweck von Agile wird nicht erreicht. In diesem Beispiel die Beweglichkeit. Langfristig stellt die Agile Mimicry also keinen Selektionsvorteil dar.

Fazit: Es ist, so wie immer, mit den Methoden: Allein sind sie eine leere Hülle. Ich habe oft genug gesehen, wie etwas instrumentell angewendet worden ist – ohne Herz, ohne Kopf und JA, auch ohne Verstand. Weil der Druck der Konformität größer (angenommen) war (bzw. als vermutet) Jede Idee, Methode und Intervention kann ins Absurde gezogen werden, oft ohne dass die Personen selbst etwas merken. Um zu den Prinzipien von Dalio (siehe oben) einen Schluss-Satz hinzuzufügen (Und auch er wird sich bei Einstein bedient haben: „Um ein gutes Schaf in der Schafherde zu sein, musst Du eins vor allem sein: Ein Schaf.“) Agilität und Scrum beinhalten die Fähigkeit, den Konformisten mit sinnvollem Handeln einen oder mehrere Schritte voraus zu sein. Was steckt in dem Wort „Konfor-Mist?“ Aha.


1 Kommentar
  1. […] wissenschaftlich und auch in der Agilität schwer zu fassen (mir ist noch keine KPI dafür bekannt). Es durchzieht gleichwohl unser gesamtes soziales Miteinander und: Ohne […]

Einen Kommentar verfassen

©2019 Kopitzke ® Pro | Impressum | Datenschutzerklärung

Log in with your credentials

Forgot your details?

Send this to a friend