• Slider Image

Gescheit scheitern – gescheit?

Agile? Systemisch? Ja, nach diesem Beitrag

Warum die Frage schon systemisch ist

Die agilen Methoden schwappen über den Becherrand (der Softwareentwicklung) hinaus und verbreiten sich in ganz anderen Bereichen der Welt. (Verkrustetes) Silo-Denken verlässt eben diesen, den Becher, - mal sinnvoll, mal muss ich als Agilist genaue Fragen stellen, um eine an mich herangetragene Anforderung in meiner eigenen Landkarte im Kopf richtig zu verorten.
 

Selten wird der Begriff „systemisch“ ins Spiel gebracht - bis ich diesen nenne und mit Substanz versuche, anzureichern. Ich habe mich bewusst, auch mit ShuHaRi, einer Lerntechnik (mehr in der Box), befasst. Agile Methoden sind Modelle eines Soll-Prozesses für komplexe Systeme. Gescheites scheitern inbegriffen. Theoretisch folgen diese demnach der systemischen Weltsicht. Hier höre ich den ersten Aufschrei: "Prozess - igitt!" Später dazu mehr …

Geile Software, Lösungen mit Mehrwert, aber auch Märkte und die darin befindlichen Menschen sind erst kompliziert, später komplex. Die Iteration, ein gedankliches Konstrukt, mit dem ich seit gefühlt 15 Jahren unterwegs bin, hat sich als probates Mittel erwiesen, um in diesen Systemen strategisch zu handeln. Mit Erfahrung, mehr noch Haltung, UM und hinter dem Ausdruck „systemisch“, werden Rahmen, Bedingungen und Möglichkeiten des agilen Vorgehens bewusst - und auch transparent.

Der systemische Ansatz fußt auf einer grundlegenden Überzeugung, der ich folge. Jede Person konstruiert sich seine eigene Wirklichkeit (= Konstruktivismus). Diese(r) ist nicht mehr diskutabel, sondern lern- und hirnwissenschaftlich bewiesen. Dieser Mechanismus ist auch über die Individualebene des Einzelnen hinaus – innerhalb von Gruppen, gut zu sehen. Denken Sie an Arbeitsgruppen oder Meetings, wo nicht das beste, sondern das verträglichste Ergebnis (oft der kleinste, gemeinsame Teiler) postuliert wird - na, klingelt da etwas?

Es wird ein gemeinschaftliches und einheitliches Verständnis 'konstruiert', in dem beispielsweise soziale Regeln aufgestellt werden. Diese soll(t)en dann allen Beteiligten gefallen. Es wird eine Mehrheitsmeinung gelebt und auf die gute Demokratie verwiesen. Andere, bessere oder effektivere Lösungen - verworfen? Die Spitze des Eisberges ist einerseits das Wissen darum und andererseits das konstruierte Unvermögen, es im Gesamtkontext zu plakatieren.

es greift - IN-einander

Die Aus- und Wechselwirkung

Jetzt sind wir bei systemischer Agilität. So kann je nach Kontext das gleiche Verhalten innerhalb und / oder außerhalb von Systemen sehr verschiedene Reaktionen nach sich ziehen. Zwischen-Fazit: Deswegen lohnt sich ein sehr genauer Blick auf das jeweilige System, und nicht nur das, sondern auch auf die Syteme links und rechts (oder oben und unten, je nach Sichtweise) davon. Die Ignoranz dazu kann verheerende Folgen haben.

An mehreren Stellen geben sich agil und systemisch die Hand, genau hinsehen und hinhören ist dabei sehr sinnvoll und im Ergebnis zielführend. Jede Handlung, ganz gleich ob spontan, erprobt oder noch nie dagewesen, hat Folgen (es gilt das Ursache-Wirkung Prinzip, welches gerne in sich verwechselt wird), die man nur bedingt voraus sehen kann. Deshalb sind Planungen im agilen Kontext nur für einen gewissen Zeitraum und mit einer gewissen Heuristik möglich.

Agil ist nicht besser planen, sondern die Planungszeiträume soweit (radikal) zu verkürzen, dass in der Planung (möglichst) valide und belastbare Ergebnisse entstehen (Na, gemerkt?: Die Iteration) Es ist durchaus gewünscht, hierzu auch die Statistik zu befragen. Warum? Und damit sind wir wieder bei der Einleitung: Jede Statistik, insbesondere Verteilungskurven, die mit präzisen Parametern gefahren wurde, zeigt die Anteile an bereits geschehenen Ergebnissen (im Kontext), die in der Vergangenheit gescheitert sind. Wie dumm oder ignorant ist es dann, diese innerhalb des eigenen Konstruktivismus auszublenden? Harter Tobak - es nützt aber nichts (was anderes gibt es nicht …).
 

Kleinteilige Prognosen - helfen

Diese Prognose sind Aussichten, also Annahmen innerhalb des Systems, um dieses zu beschreiben und handlungsfähig zu bleiben. Je weiter diese Prognosen in der Zukunft legen, desto unschärfer werden diese zwangsläufig. Das ist nicht neu - Neu ist ist steigende Volatilität (Bewegungen, Unvorhersehbarkeit) aller aktuellen Entwicklungen (aha: Systeme), die wir seit einigen Jahren nicht nur sehen, sondern auch (selbst) spüren.

Bleiben wir z.B. bei Scrum: PO und Entwickler – sofern sie keinen Kundenkontakt haben (Achtung: Mit Kunde ist hier der wirkliche Endkunde, also der direkter Nutzniesser des Produktes gemeint, nicht (irgendwelche) Stakeholder!) – bilden Annahmen über die Wirklichkeitskonstruktion der Kunden, um deren Anforderungen abzubilden.

Selbst wenn es valide, realistische Daten zur Nutzung der Software oder den Bedürfnissen der Endkunden gibt, sind sie - bitte was? Weniger wahr oder mehr interpretationsbedürftig? Und bei einer Interpretation ist der Konstruktivismus schon wieder der (leise, aber mächtige) Ratgeber. Schnell konstruiert ist besser als aufwändig recherchiert, gell? Relationen, Aufbau und, schon wieder: Ursache und Wirkung(!) können nicht präzise prognostiziert werden, es können nur Annahmen getroffen und diese durch Ausprobieren, Beobachtung und Analyse überprüft werden:

Das ist jetzt wichtig: Schritt für Schritt, die Folgen beobachten und (weise) reagieren. Je kleiner die Schritte, desto valider das Ergebnis genau dieses kleinen Schrittes. Also nichts anderes als das „build – measure – learn“ der agilen Produktentwicklung. Ein Systemiker würde das dann „Aktions-Reaktion-Schleife“ nennen.

Eine Kultur- oder Wissensfrage?

Pfusch lohnt sich nicht!

Agiles Schaffen und Arbeiten wirkte in vielen Firmen als der (moderne), heilige Gral, die Wunderwaffe gegen schlechte Qualität. Und was eine Wunderwaffe, sprich Qualität ist, also als Methapher mit Tiefsinn, sehen Sie hier - als Boomerang. (… aber lesen Sie erst und kehren hier hin zurück.) Illusorische Deadlines und vom Wasserfall geschundene Teams sollen wieder ‘on Track’ gebracht werden. Bekommt das Business Establishment, also die linke Seite der Stakeholder nun von agilen Teams (also die rechte Seite) eine Absage, erscheint Qualität plötzlich in einem anderen Licht. Der Knaller ist: Das Licht hat sich nicht verändert - nur die Wahrnehmung dessen. Wir lassen mal beide Fraktionen gegeneinander antreten: Agile Coaches mussten zu Beginn der agilen Bewegung Teams und einzelne Protagonisten, ja, auch Verweigerer, in monatelanger Arbeit erstmal beibringen, was Qualität (nicht nur im Produkt) und nachhaltiges Arbeiten (um das Produkt) überhaupt ist. Das ist Anfangs eine kaum, dann mehr wahrgenommene Herausforderung. Die Qualität wandelte sich langsam und merkbar in die gewünschte Richtung - Qualität wurde von einer Variablen zusehends zu einer Konstanten. Wird diese Konstante stabil(er), wird sie ein Standard und kann und sollte auch nicht mehr in Frage gestellt werden.

Schnelligkeit vs. Freiheit

Blicken wir auf eine Kernforderung der Wirtschaft: Schneller, höher, weiter und/oder weniger. Leider mit oder auch ohne die Mitarbeiter - das ist ein anderes Thema. Eine der Verheißungen der Agilität ist eine kürzere ‘time-to-market’ – Das scheint ja zu passen. Von der Idee bis zum fertigen Produkt - schnell und bitte mit Qualität, was ja prinzipiell auch stimmt. Zumindest in gut funktionierenden agilen Einheiten (runter bis kleine Teams, rauf bis komplette Organisationen). In weniger gut instruierten tritt vermehrt folgendes Problem auf: Die agilen Werkzeugkoffer – Scrum vorweg – bieten den Entwicklern bewusst die Freiheit, ihre ToDos selbst auszuwählen und die Realisierung entsprechend selbst zu bestimmen. Das kann zu Verwerfungen führen. Auf Sicht kamen wieder Ergebnisse - mehr oder weniger positive, diese aber (quantitativ) stetig steigend. Das ist positiv. Hin zur pragmatischen Schlichtheit und somit weg vom blinden Anspruch auf Vollständigkeit. Der Fokus legt sich auf messbaren Kundennutzen und Nachhaltigkeit ist das Gebot der Stunde. Gut … Und was ist mit der Deadline? Der Zusage aus der übergeordneten Wasserfall-Planung? Was ist mit ‘Sonderlocken’? Warum bekomme ich jetzt (als Stakeholder) von meinem Entwicklerteam eine Absage oder muss/soll meinen (Wasserfall-) Plan ändern? Ist das nicht merkwürdig? … Tatsache ist: Das agile Leben ist weder fair noch gerecht und die Qualität (es ist alles in der Geschichte beschrieben und in Statistiken nachzulesen) stirbt zuerst. Aktuell (Abgas-Skandal, Kartell-Verdacht): Erst Volkswagen, dann Audi, dann Porsche - und Daimler “schwimmt” auch mit …
Alles nur agiles Entertainment?

The business view ...

Die Geschäftswelt hat die steigende Forderung der agilen Teams an ihre eigene Qualität über die Jahre weitestgehend abgenickt - zumal genau diese ja auch ein Nutzniesser davon war. Doch einerseits und eher gezwungenermaßen: Scrum beispielsweise hat durch die postulierte  Selbstbestimmung für das Team eine Art „Notwehrmechanismus“ eingebaut: Das Team, vorzugweise die Devs. bestimmen die Durchlaufgeschwindigkeit und das unbekannte „wie“. Und ist anschliessend – mit Recht – stolz auf das Ergebnis. Der Stakeholder ‘irgendwie’ auch - wird aber damit sein persönliches, ungutes Gefühl des Kontroll- und Machtverlustes nicht wirklich los.

Andererseits liebt das Business Zahlen - natürlich nach oben. Halbgar entwickelte Features und hingeschmiertes Zeugs verschwanden und die über Jahre eingegangenen technischen Schulden (die schmutzige Ecke im Backlog …)  werden nach und nach beseitigt und somit bessere Ergebnisse durch die Agilität erzielt. Doch was hat sich geändert? Ich sage nur: Kontrollverlust ... und die Wahrnehmung (Resistenz) dessen.

Auf der Seite des Stakeholders und von der Businessseite stellt sich die Lage nach abebbenden aber initialen Enthusiasmus nicht mehr so erfreulich dar: Die Teams beginnen, es sich in ihrer agilen Komfortzone einzurichten - sie haben ‘die Hose an’. Die selbstbestimmte, abgeschlossene Trutzburg des Sprints ist, alles schon vorgekommen, mit Kuschelecken, Hängematten und Cocktailbars ausgestattet. Die Kaffeemaschine ‘spricht’ 14 differente Sprachen und produziert unermüdlich in feinster Kaffeehaus-Qualität – und das wirkliche Business wird selbst nach Ausweiskontrolle nicht rein gelassen und steht aussen vor. Fragt der Stakeholder (auch als Sprachrohr des Business) am Burgtor ein zusätzliches Merkmal oder Funktion an, gibt es alle möglichen Liefertermine - nur keinen konkreten, mit dem man arbeiten kann.

Das Guckloch im Burgtor knallt wieder zu, die Party geht weiter. Mit dieser (überspitzten) Darstellung kann ich das Thema um den Kontrollverlust zumindest nachvollziehen. Was lernt das Business und/oder der Stakeholder daraus? (Oberflächlich:) Termine sind in der Agilität nicht vorgesehen. Nach einigen Abfuhren registriert das Business die schmerzhafte Erfahrung, dass ein Termin einhalten nicht möglich und damit Planbarkeit nicht (oder so nicht) gegeben ist. Die Kurzschlussreaktion der Organisation, die ja erst recht ein lebender Organismus ist): Wenn Termine wichtig sind, dann bitte in der Umsetzung "less agile" und wir machen einen Fallback in den Wasserfall. Mit Salto. Was ist das? Pfusch, ein „Bauchklatscher“ - der Agile untergräbt und schmerzt. Und bye-bye, Tschüss, Qualität ...

Shu Ha Ri

1. Nichts für wahr halten, was nicht so klar und deutlich erkannt worden ist, dass es nicht in Zweifel gezogen werden kann.
2. Schwierige Probleme in Teilschritten erledigen
3. Vom Einfachen zum Schwierigen fortschreiten
4. Stets prüfen, ob in der Untersuchung Vollständigkeit erreicht sei

Wenn ich (beim Kunden oder bei seinem Team) agile Methoden etabliere, stellt sich sehr oft die Frage: Wie vorgehen? Nach Schulbuch oder direkte Anpassung an die konkrete Situation? Logisch, das Bestehen auf den Regeln aus Scrum-Guide und Co. fühlt sich an an wie Korinthen kacken - es ist und bleibt ein Prozess. Der gesunde Menschenverstand ‘bockt’ und will sich pragmatisch und sofort den realen Gegebenheiten anpassen. Und hier ist die Keimzelle des Scheiterns - dem nachzugeben ist nicht gescheit. Ist diese (vor-) schnelle Anpassung im langfristigen Sinne des Zieles einer erfolgreichen agilen Transition hier schon sinnvoll?

Die japanische Philosophie, auf der ja große Teile der agilen Gedanken und Methoden beruhen, bietet auch hier eine klare Empfehlung. Die dortige Kampfkunst kennt drei Stufen des Lernens, die ein Schüler von den Anfängen bis zur Meisterschaft seiner Kunst durchläuft. „Shu Ha Ri“ bezeichnet diese Entwicklung und meint: Erst lernen, dann entfernen, dann weiterentwickeln. Und: Nur mal so gefragt: Sie wollen ein Instrument erlernen, sagen wir Klavier. Fangen Sie mit Tönen (das Was), Tonleitern (das Wie) und Fingerfertigkeit (die Technik, dann Geschwindigkeit) an oder mit einem leeren Notenblatt und dem Komponieren einer 4 stimmigen Partitur in Moll?

‚Shu’, die erste Stufe des Lernens, bedeutet sinngemäß „erhalten, gehorchen“. Man lernt, indem nachahmt und den gegebenen Regeln gefolgt wird. Nur, wer die Regeln beherrscht, so die Idee, sei in der Lage, sich später über diese hinweg zu setzen, ohne die Kunst an sich zu verlieren. Hier wird gerne dieser Fehler gemacht: Das machen wir dann mal schnell, so eine Woche ... und es wird mit Bravour gescheitert. Die Lern- und Hirnforschung (also die westliche Welt) hat bereits mehrfach bewiesen, dass Lernen mit einer einhergehenden Veränderung 30 Tage dauert. Können sie gerne mal googeln ...

‚Ha’ als zweite Stufe von Shu Ha Ri lässt sich übersetzen mit „(auf)brechen, frei werden, abschweifen“. Jetzt geht es darum, die gegebenen Regeln und Standards aus 'Shu' zu variieren und auf die eigene Situation anzupassen. Dazu gehört auch, die Hintergründe zu verstehen, um so über das reine Befolgen von Regeln hinaus zu kommen. Gut beraten ist, wer an dieser Stelle sich eine gewisse Objektivität von und zu Theorie (dem Allgemeinen) und der eigenen Anforderung (seinem Speziellen) bewahrt.

‚Ri’ als dritte und höchste Stufe schließlich bedeutet „verlassen, trennen, abschneiden“ und sagt aus, die vorgegebenen Muster bewusst, gezielt und auch gesteuert hinter sich zu lassen um, von eigenen Anforderungen und Situationen gesteuert, eigene Wege zu gehen (heisst: versuchen). Die Erfahrung und das Beherrschen der Regeln ist dabei die Voraussetzung, um sich in dieser fortgeschrittensten Variante unabhängig zu machen von der Lehre und deren Ideen frei anzuwenden. Kurz: Sie verlassen die Regeln, haben aber den Sinn und die Wirkungen der Prinzipien (Eine Regel ist kein Prinzip) verstanden und können diese nutzen.

Für eine agile Transition bedeutet diese Philosophie also tatsächlich zunächst: Folge den Regeln, wie sie im Buche stehen! Nimm die Scrum-Regeln genau oder lerne in Kanban dein System zu verstehen, und handele danach. „Ja, aber…“ (kein guter Argumentationseinstieg) höre ich die Einwände von allen Seiten und mehr noch aus der Linie oder dem konsequent verteidigtem Silo, „… das ist doch albern, sich daran so fest zu krallen. Wir haben in unseren Schulungen gelernt, wie es eigentlich geht, aber in der Praxis können wir ja wohl direkt zum nächsten Schritt übergehen und es so machen, wie es für uns am besten passt.“ Gescheit? Gescheitert! Bitte nochmal lesen: Die Falle ist "eigentlich ..."

Ja, sicher, das kann man. Und es wird auch oft getan, auch in Projekten, an denen ich selbst beteiligt war oder bin. Ich würde solche Projekte bestimmt nicht pauschal als „gescheitert“ bezeichnen! Gut ist, die Fallen zu kennen, diese zu sehen und deutlich darauf hinzuweisen! Das Aufnehmen und benutzen einer gelieferten Information ist, denn so einfach ist es, nicht die Veratwortung des Coaches / Trainers, sondern des Empfängers.

Dennoch legt die Philosophie von Shu Ha Ri eine wichtige Frage nahe: Werde ich jemals in der Lage sein, die Methode, die Kunst wirklich so souverän zu beherrschen, dass ich sie frei verändern und weiter entwickeln kann, wenn ich nicht zu Beginn meiner Lehrzeit die Regeln und deren Auswirkungen am eigenen Leibe kennen gelernt habe? Wer sich die Regeln, die ja irgendwo in Hirn und Verstand gewachsen sind, von Beginn an zurechtbiegt, droht im „ScrumBut“ oder anderen Stilblüten stecken zu bleiben: Es funktioniert irgendwie und augenscheinlich ist es kurzfristig erfolgreicher als die meisten klassischen Wasserfall-Projekte. Aber die eigene Weiterentwicklung ist begrenzt, denn diese erfordert eine Beherrschung der anderen Methode. Und zur Beherrschung einer Methode gehören auch die Grundlagen und zum Können wiederum gehört mehr als das theoretische Wissen.

Das theoretische Wissen kann man tatsächlich in einer Schulung lernen, aber ob man es deswegen beherrscht, verinnerlicht hat, um auch noch Jahre später mit diesen Grundlagen-Regeln souverän umgehen zu können? Ich habe meine berechtigten Zweifel, und die Bestätigung dafür auch schon oft gesehen.

Wer eine Methode, wie etwa Scrum oder Kanban, wirkliche beherrschen lernen will, ist also gut beraten, wenn er die Regeln zunächst ernst nimmt. Für uns als Agilisten bedeutet dies, dass wir in dieser ersten Phase vor allem Lehrer sind oder Trainer, die die Richtung weisen und bei der Umsetzung der Regeln unterstützen. Erst, wenn ein Team oder eine Organisation eigene Erfahrungen gesammelt haben, ist es Zeit für die zweite Stufe des Lernens, die Modifizierung. Die erste Stufe dauert, das ist bewiesen, je nach Größe un Umfang bis zu 90 Tage. Der Trainer wird dann(!) zum Berater, der das Team dabei unterstützt, Varianten zu finden und auszuprobieren, was davon für sie selbst am besten passt. Nur daraus, aus der eigenen Erfahrung von Varianten und Abwandlungen und dem damit einhergehenden Verständnis von Sinn, Zweck und Hintergründen jeder einzelnen Regel, kann sich dann die dritte Stufe der Meisterschaft, das "Ri" entwickeln. In dieser Phase ist ein Team dann selbst am besten in der Lage, seinen Fortschritt zu steuern, und wird agile Berater höchstens als Ideengeber benötigen oder als Coaches, die den Prozess (also die notwendige Mechanik, denn das ist das Werkzeug) steuern, ohne Inhalte vorzugeben. Die Frage also: „Regeln befolgen oder an die Situation anpassen?“ hat unterschiedliche, in jedem Falle aber eindeutige Antworten, je nachdem in welcher Phase sich ein Team befindet. Beides hat seine Notwendigkeit, eines nach dem anderen. Damit nicht der zweite Schritt vor dem ersten kommt und damit oft auch der letzte bleibt. Das ist dann gescheitert. 

Erste Essenz, so einfach ist es ...

Verhalten - lernen?

Und hier drin (zu) gerne vernachlässigt: “learn” - Das ist der Preis und Aufwand, der wirklich erbracht werden soll(te). Somit sind Methoden wie Scrum und Kanban, die bewusst auf kleinschrittiges Vorgehen (die Iteration) und regelmäßige Feedback-Schleifen setzen, NUR Werkzeugkoffer, um in der Unplanbarkeit zum Trotz strategisch zu handeln. Ganz systemisch. Und agil. Die Werkzeugkoffer (als solches) werden (manchmal) überbewertet. Oder?

Qualität vs. Quantität: Unsinn

Der innere Anspruch – Qualität im Team

Jetzt sehen wir uns das aus der genau gegenüberliegenden Perspektive an, aus der Sicht des Teams. Über Jahre haben sie, auch schmerzvoll, gelernt, daß das und die Dinge, die erstellt werden sollen, meist deutlich komplexer sind, als zunächst vermutet (Wobei vermutet auf ein lückenhaftes Grooming hinweist, ein anderes Thema …). Und: Das ein Pfuschen in der Realisierung nicht lohnt. Die Lernkurve und Vorsicht ist: Jedes einzelne, vorschnelle Versprechen, das um einer Deadline willen hingeschmierte technische Provisorium, das zwar irgendwie geht, kommt wieder - wie ein Boomerang. Garantiert. Termine wurden nicht eingehalten. Dafür ist keine Zeit, kein Budget und keine Ressourcen – aus dem Augen, aus dem Sinn (des Business’). Funktioniert ja. Aus „das muss ja nur eine Woche / bei oder bis zur nächsten Präso halten“ wurde ein riesiger und unwartbarer Hefeteig an Provisorien, der schon anfing, unkontrolliert zu leben. Auszuhalten vom Entwicklerteam (die das ja alles wissen), nicht dem Business.

Geplant war das nicht und der Kickback, wenn Waterfall-Zusagen eingehalten wurden, immens. Das tut richtig weh und kann bei autistischen oder labilen Mitgliedern des Teams, die auf Ihrem Gebiet richtige Spezialisten sind, schwere emotionale Verwerfungen auslösen. Pfusch muss im “longterm” nicht nur doppelt sondern oft zehnfach bezahlt werden (JA, er ist exponentiell - denken Sie an Sissa ibn Dahir: das Gleichnis mit dem Korn). In den Währungen Bugs, Geld, Zeit und Schmerzen. Und wehe, wenn es dann knirscht, quietscht oder hängt: die Ausmecker und Vorwürfe vom Stekholder / Business gibt’s kostenlos obendrauf. Willkommen im Hamsterrad, das von innen betrachtet aussieht wie eine Karriereleiter.

Qualität als Anspruch und Grundsatz mit der einhergehenden Nachhaltigkeit ist also kein theoretisches Dogma, sondern konditionierte Selbstverteidigung, ein Überlebensstrategie des Dev. Teams. Ganz agil und mit einigen blauen Flecken wurde diese hart erlernt. Aufgeben ist keine Option, denn nachhaltig zu entwickeln beweist Verantwortung – gegenüber dem wirklichen End-Kunden nach aussen und auch gegenüber der eigenen Organisation (nach innen).

Boomerang + Technik + Geist + Haltung = Qualität (er kommt zurück ...)

Boomerang + Technik + Geist + Haltung = Qualität (er kommt zurück ...)

Aber Fehler machen ist verboten!

Agil macht glücklich! 

Gut, wir arbeiten schon agil. Scrum und so, vielleicht Kanban, und Produktentwicklung nach Lean Startup Prinzipien. Und Ja, die Überschrift ist überspitzt ...

Nochmal: Das Abhaken einer Checkliste mit agilen ToDos und pseudo-agilem Firlefanz als Punkte zum Abhaken bleibt eine schnöde Checkliste. Punkt. Checkliste abgefrühstückt, Sodbrennen (Glück gehabt?) ist ausgeblieben. Und morgen die nächste, gleiche Checkliste. Herr Taylor grüßt nett und freundlich von da hinten. Fehler? Seitens des Herrn Taylor bestimmt nicht.

Und so Privat, also nicht Arbeit? Haben sich agile Philosophien schon in Ihren gut behüteten, privaten Alltag oder gar Freizeit eingeschlichen? Oder Ihr Leben (an welcher Kante auch immer) verändert und euch vielleicht sogar zu einem etwas glücklicheren Menschen gemacht?

„Das geht ja gar nicht!“ höre ich deutlich, „das fehlte ja noch! Bleibt mir weg mit diesem Firlefanz und pseudoreligiösen Gefasel - steckt da nicht diese Kaizen-Sekte dahinter? Alles Manipulation! Arbeit gehört ins Büro und auf die Firma, zu Hause kommt mir sowas nicht hin. Hier mache ich was ich will!“ Auch gut und widerspreche ich nicht. Ich mache auch kein Trello-Board für das Einkaufen (wenn der Prozess des Einkaufens, also der Lust-Anteil (siehe Windowshopping), und das kommt, von der eigentlichen Mittelbeschaffung abgetrennt ist und Amazon macht es vor …); Ich mache privat nur selten eine priorisierte Task-Planung für die nächste Woche (denn es kommt ja doch anders, also spare ich die Zeit), ich führe keine Retros mit meiner Frau durch (nein, auch nicht nach S..!) und an unserem Kühlschrank hängt oder auf Google Notizen steht höchstens ein (Klebe-) Zettel mit der aktuellen Einkaufsliste, aber keine Tasks. Trotzdem hat die agile Philosophie nicht nur mich, sondern auch meine Frau, meine Sicht auf die Welt und die Emergenz dazwischen und damit wohl auch mein Leben verändert. Zum Beispiel im Umgang mit Fehlern.

Kultur: Falsch Entschieden = Misserfolg!

Tot investiert - diese Begriffe sind fragwürdig

Jetzt mal PROvoziert: Wie (genau) Sind Sie zuletzt (mit sich selbst, mit einem Mitarbeiter oder Chef) umgegangen, wo Sie einen Fehler gesehen, bemerkt oder gespürt haben? Alles lästig, dieses Gefasel, aber eben auch alles preußisch normal und doch nicht zu vermeiden - also der Fehler.

Dumm ist: Ärgern, also eigene emotionale Energie aktivieren, dass ich Zeit, Geld und / oder Nerven verschwendet habe, wo es doch so viel einfacher hätte gehen können. Hätte, ist aber nicht. Ich kann mich ärgern, dass ich DIE Chancen verpasst habe, dass ich jetzt mit einer zweitbesten oder suboptimalen Lösung leben muss und mich jedes Mal erneut darüber ärgern - siehe vorheriger Absatz. Addieren Sie bitte mal, was da an Ärger zusammenkommt - alles Energie, die entweder weg oder für etwas besseres verwendbar wäre - ist sie aber nicht. Sie ist weg.

Das ist der andere Weg, der, wie vermutet sich im Kopf abspielt: Ich kann es aber auch einfach akzeptieren. Warum? (Zeitstrahl-Mechanik): Auf dem Stand meines und damaligen Wissens habe ich (rückblickend)  die beste Entscheidung getroffen, die mir möglich war Denn:

Neue Kultur: (Mis(t)-) Erfolg!

 

Ich konnte (= Logik) damals nicht wissen, was ich später, also jetzt weiß, und deshalb konnte ich aufgrund dieser (= lückenhafte Faktenlage) nicht die Entscheidung treffen, die ich heute treffen würde oder zu der ich heute fähig bin. Und das lassen Sie bitte einfach mal wirken.

Jetzt, hier und heute, weiß ich mehr, und heute oder beim nächsten Mal kann und werde (das ist verstehen + agil + lernen + machen) ich es besser machen. Es bleibt ein mittlerweile noch kleineres Risiko, dass ich auch beim nächsten Mal einen kleineren, anderen Fehler mache, und beim übernächsten und darauffolgenden Mal auch. Aber ich habe die bewiesen unstrittige Chance (hört sich etwas komisch an), vielleicht „bessere“ Fehler zu machen, klügere, mit Sicherheit aber geringere Fehler. Für alle (Nicht-)Agilsten: So geht eine Iteration, das ist “verstehen + agil + lernen + machen” Also:

 

Und? Alles neue beim alten?

(Un-) sinniges Spannungsfeld - gelöst

Beide Seiten (links, rechts und die Qualität mitten drin) haben ihre Berechtigung. Zu gerne (und oberflächlich) wird einerseits gesehen und behauptet, dass ein schneller und billiger Prototyp nicht herzustellen ist. Andererseits wird der Erhalt einer verlässliche Planung eines Produktreleases mit einem definierten Set an Eígenschaften (mit diesem klassisch vortrefflich hervorragend Calc-Sheets, Project-Wasserfälle und Power-Folien für den nächsten Q.-Bericht gefüllt werden) gefordert. In pre-agilen Zeiten ging es duch auch - irgendwie? Klare Ansage, Klare Teilung, wenig Probleme, straffe Tagesordnung. Taylor legte und seine Verfechter postulierten damals und heute in ihrem Konstruktivismus eine planerische Dissonanz: Es kann sich nur in eine Richtung verändern: Schneller, höher, weiter, kleiner, … Und das tut es nicht. Es sind Menschen, die das alles machen (auch die Industrie 4.0 wurde von Menschen gemacht, deshalb findet diese ja auch nicht erst statt, sonder ist seit über 10 Jahren schon da - und die wenigsten haben es gemerkt …)

Wie jetzt und kann das so sein? Falsche Frage, es ist bereits so. Oh Schreck: Entwickeln wir uns mit Agilität zurück? Ich sage Nein - aber anders, als die Postulate der letzten Jahrzehnte (Klassische Management Lehre, Universität Pfefferminzia, Hörsaal 08.15, 3. OG) uns weiß machen wollen. Der flächendeckende Change hin zu agilem Vorgehen erfolgte nicht aus Spass and der Freude mit einer Prise (R)Evolution und weil es nur schön ist.

Hinsehen, hinhören hilft

Sehen wir hin, in das Verhalten:

Zuvor wurde ausschließlich das Business in den Fokus gestellt (was nicht sagen soll, dass dies zu Gunsten des zahlenden Kunden, also der Wirtschft geschah). Denken Sie bitte dabei an alle Auswüchse, ob sinnvoll oder nicht, denen Sie schon begegnet sind. Wenn Sie nur 1x das mulmige Gefühl hatten, eins davon ist Unsinn, Humbug oder den latenten Drang verspürten, das mache ich jetzt nicht mit - haben Sie den ersten Keim der Agilität schon in sich. SIE (in Person) sind der Ausführende, mit Ihrem Verhalten. Mit der ersten agilen Welle verschob sich der Blickwinkel recht drastisch auf technisches ‘Zeugs’. Das ist schon (ganz) gut und notgedrungen so, weil heutige Businessmodelle immer techniklastiger werden (Da ist sie wieder, die Industrie 4.0). Doch jetzt ist es Zeit für die nächste Stufe: Alignment.

Diese Gegenüberstellung zeigt klar, dass Probleme auftreten werden, wenn Business, Entwicklung und Technik nicht nahe genug zusammenarbeiten. Die tayloristischen Silos (mit samt dem bildungsbasiertem, aber letztendlich konditionierem Denken und Verhalten) wirken sehr mächtig, das Infragestellen derer fast unmöglich.

Es geht um die gemeinschaftliche Co-Kreation in einem Rahmen exponentiell dynamischer werdenden Rahmenbedingungen, die wir alle selbst geschaffen haben, nicht um das Abarbeiten von Anforderungslisten und dem Bau von Charts, Folien und Quartals-Reporting. Das ist der sogenannte Blick über den Tellerrand. Nur gemeinsam sind wir alle gewappnet für die noch kommende Anforderungen, was gemeinhin (leider auch oberflächlich - Aussnahmen bestätigen die Regel) mit „Digitalisierung“ beschrieben wird.

Mit dieser nächsten Stufe, die schon da ist(!), kommen wir dahin, dass Qualität weder Dogma noch ein Jiu Jitsu (jap. 柔術) Selbstverteidigung sein muss, sondern pragmatisch sein kann oder sein sollte. Pragmatismus, das Fundament jeden agilen Vorgehens, was nicht in unerheblicher Masse auch auf Menschenverstand und jahrelanger Erfahrung basiert und somit auch eine Frage von Vertrauen und Verständnis zwischen Business und Technik ist.

dann das kritische hinterfragen

Also fest Halten

Agilität ist weniger machen, also der mechanische Teil, es ist eine Kulturfrage! Kulturen, quasi als Produkt oder Ergebnis, entstehen aus Geist, Kritik, Einsicht und Lehre, die dafür (erst) investiert werden (müssen). Es ist somit keine Methode - Wie der Bauplan eines Boomerangs (siehe Video: Das Teil fliegt nicht, und kehrt auch nicht zurück, wenn es, schlampig oder verpfuscht in der Ausführung, geworfen wird). Es ist ein Mindset! In der Agilität ist ein gemeinsames Team wichtiger, als das Produkt. In der Emergenz genau dieses Teams ist es zu suchen: Das Produkt, (das ein einzelner (Mensch) so nicht fertigen kann …) Die Happiness des Einzelnen, somit des Teams, ist ein nicht zu unterschätzender Faktor.

Es sind Menschen, die das leisten. Menschen, die sich schlecht fühlen oder oberflächlich behandelt werden, können(!) nicht ihre Höchstleistung bringen. Weil sie mit Ihren eigenen Gefühlen und den eigenen Reaktionen eines oktruierten Verhaltens sich selbst behindern. Ganz einfaches Beispiel: Nehmen Sie Ihr Smartphone, starten Youtube, 2 Messenger und eine Office Suite, dann eine Photobearbeitung und versuchen, Ihre letzten 30 Photos auf dem Gerät in einem Batch mit Kunstfiltern zu bearbeiten. Ja, eine (ungewöhnliche) Situation beim Smartphone.

Und genau das passiert im Kopf eines jeden Menschen, jeden Tag. Dieses Verständnis zu diesem Verhalten ist wichtig(er) als der schnelle, wirtschaftlicher Erfolg. Mal bis zum Ende gedacht: Das Business kann planen so viel wie es will - wenn die Menschen weg sind oder gar nicht erst kommen (antreten, sich einstellen lassen), diese Arbeit zu machen - ist das Business nicht die Folien wert, auf dem es steht. Klingt doof, kann aber im 'longterm' schlau sein. Weil das Erkennen des Verhaltens die Frage, ob ich es behalten will, nachhaltig prägt und weil miteinander und voneinander Lernen der Schlüssel zum Erfolg ist.

Verhalten behalten

Solange ich ein Verhalten behalte, brauche ich mich über folgendes nicht zu wundern: “Tust Du jeden Tag das gleiche, wundere dich nicht. Du bekommst dann jeden Tag die gleichen Ergebnisse.” Und das ist nicht agil. Anders herum wird der Schuh ein Schmuckstück: “Tue jeden Tag etwas (also das, was zu tun ist) etwas besser, und wundere dich zufrieden. Du bekommst dann jeden Tag (im longterm) bessere Ergebnisse.” Und die, nur die, bezahlt der Kunde. Nach hinten raus steht ein hochqualitatives Produkt und ein gemeinsames Team aus Business und (!) Entwickler, die für das nächste Projekt schon(!) gewappnet, ja sogar noch besser geworden sind. Auch wenn es oberflächlich nach draußen wir Party klingt.

Kennen Sie Ying und Yang? Gut, legen Sie das mit diesem Kontext hier noch mal an - und lassen es wirken.

Fehler begrüßen, weil man aus ihnen lernen kann.

Nicht diskutabel!

Jedes 4 jährige Kind, das Fahrrad fahren lernt, schafft das nicht, indem Oma, Opa oder Eltern es dem Kind genau erklären. Es muss auf sein Kinderrad (ob mit oder ohne Stützen) und fahren. Und Hinfallen z.B. in einer Kurve mit Rollsplitt. Das tut weh, im Idealfall aber nur 1 x. Aus Fehlern lernen ist eine sehr agile Philosophie. Eine, die nicht an der Bürotür ein- und ausgeschaltet wird, sondern die, und das ist das schöne, überall schon da ist. Und einem hilft, sich ein bisschen weniger zu ärgern und mehr zu freuen.

Deshalb behaupte ich – das ist psychologisch erwiesen und auch mit bildgebenden Verfahren dokumentiert, agil macht glücklich(er). Nicht nur bei der Arbeit. Aber dort auch.

 

Mögliche Essenz, so einfach ist es ...

Verhalten - behalten - verwalten

Nun ist es an Ihnen. Sie haben ein Verhalten, Sie sehen und spüren es. Das ist die eine Seite. Wie und Wo unsere Entwicklungsfelder sind, in Neu-Deutsch: “da ist noch Potential nach oben …” - das ist die andere Seite. Sie entscheiden, ob Sie dieses Verhalten behalten und weiter verwalten wollen. Entweder machen wir alle es den anderen vor, oder “die” machen es uns vor. Glauben Sie mir, dann werden wir nur noch verwaltet. Wollen Sie das?

Hier.(mit).teilen:

About the author

Kopitzke®, ´64*. Agilist und Resource Manager aus Überzeugung. Erfahrung, PROgressives Denken und positiv PROvokantes Handeln haben einen eigenen Charakter. Eine agile PROfi (An-)(Sichts-) Sache. Frei ist (einseitig) objektiv, gefallen (zweiseitig) subjektiv. Mehr ...

1 comment on “Gescheit scheitern – gescheit?”

  1. kepro_Admin

    via XING, 28.07.2017:
    „Hallo Herr Kopitzke, ich habe Ihren absolut brillanten Artikel zum Thema „Agile“ gelesen, chapeau! …“
    Adrian Taciulescu, Chief Executive Officer
    ReputationCloud / MASTER-SOLUTIONS, S.L., München

Comments are closed.

Projekte für sprechende Menschen ...

Gerne per Mail. Oder: