Der agile Knoten - alle aufgelöst? Mit Kommunikation von Kopitzke® gelöst

Was, Wo, Warum einsetzen?

Aus meiner Sicht, die nicht aus der Entwicklung blickt, sondern sehr kommunikativ aus dem Business auf dieselbe, ist es für mich wichtig, einen oder sogar DEN kleinesten gemeinsamen Teiler zu finden. An anderer Stelle schrieb ich bereits darüber. Es ist die Kommunikation (also das Was, Wie, an Wen, Womit, Wofür und Wozu) , wenn nicht sogar noch anteiliger, die Interpretation, also die Auslegung der dargebotenen Informationen. Hier ist es hilfreich, nur 1x richtig in die Trickkiste der Sprachakrobatik (und ganz einfache Psychologie) zu greifen:

Denken Sie bitte NICHT an rote Blaubären.

beliebtes Gedankenexperiment …

Sie haben welche gesehen – oder nicht? Weil Sie daran gedacht haben – und jetzt müssten Sie stolpern: Was für Beeren? Rote Blaubären. Jetzt die doppelte Erkenntnis: Ihre roten Blaubären unterscheidet sich erheblich von meinen zum Zeitpunkt, wo ich diesen Text schreibe. Wir meinen das gleiche und verstehen etwas unterschiedliches. Wichtige Beschreibungen (Größe, Farbnuancen, zottelig oder glatt, Photo oder Grafik, mit oder ohne Hintergrund) fehlen. Und: Falle und Fehler: Ich habe es falsch geschrieben – spätestens jetzt sollte Ihnen der Trick auffallen, in dem ich Sie im Lesefluss habe stolpern lassen.

Und genau darum all das – es geht, wie im Bild (weiter oben) dargestellt, nur um das Fragezeichen und die beiden Pfeile – (Unterschied) bemerkt? Ein einziges Warum in 4 verschiedenen Kontexten ergeben vier oder mehr differente Antworten. Und: Hinterfragen Fragen, fragen Sie und fragen Sie nochmal, bis es eindeutig ist. In einem Satz: Je weniger Interpretationsspielraum in einem Kontext eine Bedeutung hat, desto schärfer wird die Eindeutigkeit der transportierten Informationseinheit in diesem Kontext.

Speziell im Softwarebau (und auch …):

  • Wir merken oft sehr spät (oder erst am Schluss), dass das gebaute Produkt nicht den bestellten Nutzen bringt.
  • Der Kunde möchte eine (spontane) Modifikation. Ist diese auch mit unseren Firmenzielen vereinbar?
  • Fehlende Nachvollziehbarkeit: In welcher Form wirkt der Code/Tests auf das Geschäftsziel?
  • Der Kunde/PL/PO ging von einer anderen Lösung aus, als er die „vage“ Vorgaben vom Lieferant gebaut hat.
  • Die Qualität der User Stories war schlecht (in Bezug auf die Kundenanforderung – und schlecht stimmt auch nicht, sondern ‚daneben‘. Das Ziel ist nicht erreicht.
  • Die Testabdeckung ist gross, deckt aber nicht das Richtige ab (und mehr)

Agile Bereiche

Da sich Agile auch auf andere Bereiche erfolgreich ausgedehnt hat, können Sie selbst entsprechende Ableitungen herstellen (alternativ: Ich helfe gern!) Das Grundproblem nahezu jeder agilen Herausforderungen hat die Wurzel im fehlenden gemeinsamen Verständnis von Kunde, Nutzer, Sachverständigem, Entwickler und/oder Architeken. Interessanterweise sind die häufigsten Problemstellungen das gemeinsame Verstehen für ein Ziel (kurz, mittel- und langfristig) und somit die Erwartungen an die Lösung. Dazu kommt, dass, siehe obiges Bild, auf verschiedenen Ebenen angewendet, eine Anlyse der Ursache-Wirkung, je nach Ebene differente Antworten gibt. Hier ein Beispiel eines Isikawa Diagramms als Vorlage.

Richtig angewendet löst diese Hilfe differente ‚Verstopfungen‘ – auf.

Das Ishikawa-Diagramm kann während des gesamten Zyklus, JA, auch iterativ, benutzt werden, wenn ZU einem Problem (IM Fischkopf rechts) Ursachen gesucht, Ideen bewertet und die schwere des Defekts (Gräten links) beurteilt werden sollen.

Das Ziel ist, alle möglichen Ursachen für ein Problem zu erkennen, zu benennen und den primären Auslöser dafür zu identifizieren. Alles andere ist lustige Pflasterkleberei auf offene Schenkelhalbrüche. Nur so kann eine verlässliche Basis für weitere Planungen (und auch eine Sprint-Planung in Scrum ist eine Planung) skizziert werden. Die größte Kritik an diesem Vorgehen ist, das hier „nur“ Ursache und Wirkung plakatiert werden. Richtig. Versuche der Lösungen (im nächsten Schritt) sind obsolet, wenn Ursache und Wirkung nicht bekannt sind.

Was sagt die Theorie?

Einer, aus meiner Sicht wichtigster Wert der agilen Vorgehensweise ist eine saubere Kommunikation. Ein grosser Teil dessen findet dabei während den Meetings wie Daily Standup, Planning (Grooming) und Produkt-Review statt – gemessen zu lange, gefühlt zu nutzlos und real zu sinnlos – was dort und wie besprochen wird. Ja, erlebt (und Kopf geschüttelt- gerade bei Teams, die schon seit einiger Zeit agile Methoden wie Scrum einsetzen), dass diese Events anstatt für das gemeinsame Verständnis für Rapports, Fortschrittskontrollen und Audits verwendet werden. KPI’s, egal aus welcher Ecke, werden definiert, plakatiert und präsentiert … So wird das nix …

Inhalte und Werte

User Stories hatten oder lieferten keinen echten Businesswert, Epics verkamen zu Management- oder Marketing-Geschwafel und das Vertrauen des Kunden / Stakeholders sinkt stetig.sichtbar bei der Realisierung. Auch wenn das bereits erkannt (aber ein Ishikawa unterlassen) wurde, die folgenden Reaktionen sind Placebos bei der Bekämpfung von Symptomen wie ‚Stories besser schreiben‘ (und wie?), ‚Akzeptanzkriterien noch durch Legal sichern‘ (welche und von wem definiert?), … fällt Ihnen noch mehr ein?

EIN-deutige Ziele

Vereinbart wird das vermeintlich gemeinsame Ziel, Resultat ist ein differentes Verständnis der Lösung und der Erwartungen. Der Anspruch an die Kommunikation, diese schlank und effizient zu halten und dabei zeitgleich das Verbindliche mit transparenter Verständlichkeit zu garantieren, führt zu Stories im Charakter von ‚platten‘ Anforderungen. Der Kunde bestimmt und will es so haben, der Verantwortliche (in Scrum der PO) schreibt (es unreflektiert unkommentiert, unpriorisiert) nieder ‚as it is‘. Schnell wird hier aus einer ‚User Story‘ eine komplette, technische Anforderung – ohne User. Der oder die Umsetzer (z.B. das Team) liefert. Das ist die gefürchtete ‚Kommunikation über Dokumente‚ anstatt von ‚reflect Face-to-Face‘.

Immer mehr Unternehmen durchlaufen die Transformation von einem klassisch agierenden Unternehmen hin zur Annahme agiler Methoden. Angesichts der zahlreichen Vorteile, die eine agile Arbeitsweise bietet, ist das wenig überraschend. Fragt man allerdings in einem Unternehmen herum, warum man zu agilen Methoden übergegangen ist, ist die Antwort oft ernüchternd: viele verstehen nämlich oft die Hintergründe für die Transformation nicht und sind dann umso frustrierter, wenn sie nicht den Erwartungen entspricht. Noch so ein Defekt: Was nützt mir das warten auf eine Er-Wartung, wenn ich diese nicht kund tue?

Die großen Probleme bei agilen Transformationen

Häufig bemerktes Problem bei agilen Transformationen ist das grundlegende Verändern von Abläufen. Während der Umstellung auf agile Methoden erfolgt das dann stufenweise. Nach meiner Wahrnehmung sorgt das oft für Phasen der Verwirrung bis Frustration bis Ablehnung, wenn dieses nicht schnell genug die prospektierten Ergebnisse bringt. Und dieser Satz ist SO wichtig: Es vergessen viele Beteiligte, dass Änderungen nicht über Nacht passieren und auch nicht passieren können. Es ist harte Lern-Arbeit, die darin steckt. Und Lernen lässt sich nicht beschleunigen. Nicht durch Ansagen, nicht durch ‚zupfen‘ und ‚ziehen‘, nicht mit Druck, Milestones oder kollektiver Umerziehung. Nur mit wollen. Blicken Sie in die asiatischen (Kampf- (Kunst-) Schulen. Das Prinzip Shu-Ha-Ri mit KATA (kommt nicht aus der Programmierung!) ist allgegenwärtig.

Sofern ist folgendes Verständnis, das sich durch das ganze Unternehmen ziehen soll(te), für das große Warum sehr wichtig:

Wir sollten uns auf die agile Transformation, bewusst wie eine Reise, mit der Bereitschaft zur Veränderung und dem klaren Verständnis dafür(!) entscheiden, wie diese Reise die Fundamente unseres Unternehmens verändern, neu ermöglichen und unterstützen wird.

Fehlt dieses klare DAFÜR …, ist ein Erfolg zweifelhaft (am besten: Gehe über LOS, lesen Sie den Artikel nochmal oder fragen Sie Ihren agilen Coach und Berater). Es sind meist die Unternehmen, denen dieses gemeinsame Verständnis für die Transformation fehlt, die dann mit allen folgenden Umstellung die größten Schwierigkeiten haben.

DIE Basis – DER Mensch und DAS Projekt

Fragen Sie in solchen Fällen die betroffenen Mitarbeiter, warum die Umstellung (also die Transformation) auf eine agile Arbeitsweise stattfindet, erhält man (zum Teil) haarsträubende Antworten:

  • „weil die Konkurrenz auch so arbeitet“
  • „das Management (Chef? Zentrale?) hat es so entschieden“
  • „weil ohne agile Methoden unser Business nicht mehr aufgeht“
  • „Keine Ahnung, ich mach nur, was man mir sagt“ (Das ist im agilen Kontext ein ‚personeller Brandbeschleuniger‘ …)

Einzeln betrachtet alles valide Antworten – legen Sie jetzt mal die Layer übergeordneter Kontexte darüber – und schon sind diese Antworten wertlos – im wahrsten Sinne des Wortes. Dabei wird auch (krass) deutlich, dass es dieser Firma an einer echten, gemeinsamen und auch verstandenen Basis für die notwendige Veränderungen fehlt.

der Mensch in / für die Transformation

Eine Transformation, die an alt hergebrachtem oder bewährtem rüttelt, ist meist erst kostenintensiv, Dann ist sie auch hinderlich (nur in der ersten Zeit nach Start), wenn die erwarteten Ergebnisse verzögert erreicht werden oder erst mal unsichtbar sind. Jeder gerufene Agilist sollte darum bereits früh mit den Führungskräften damit beginnen, den Ansatz für diesen Prozess klar zu durchdenken und dann eine gemeinsame Basis zu bilden. Für Unternehmen heißt das, zu akzeptieren, dass der Transformationsprozess kein Kinderspiel wird, sondern die Herausforderungen anzunehmen und den Mitarbeitern und dem Unternehmen die Möglichkeit (Ja ich höre die Notwendigkeit einer langfristigen Planung) zu geben, daran zu wachsen – die gemeinsame Basis ist dafür ein unersetzlicher Faktor, der über den Erfolg oder Misserfolg des Unternehmens entscheiden kann. Eine weitere Realität, die nicht verhandelbar ist: Es wird personelle Umbesetzungen geben. Genau so, wie in einem neu angelegtem Blumenbeet (fast) (nicht) alle Setzlinge Lust haben, zu gedeien. Dann muss gehandelt werden. … Was macht der Gärtner? Umsetzen.

©2019 Kopitzke ® Pro | Impressum | Datenschutzerklärung

Log in with your credentials

Forgot your details?

Send this to a friend