Der Begriff „Agilität“ ist in den letzten 20 Jahren für alles Mögliche benutzt worden. Dadurch ist Agilität bedeutungsleer geworden. Andererseits ist es durch den Fokus auf Methoden entkoppelt vom Ziel, was wir über die Werkzeuge erreichen wollen. Das ist in den aktuellen Zeiten umso dramatischer, weil die Resilienz von Organisationen, also ihre Fähigkeit, sich einem dynamischen und komplexen Umfeld anzupassen, Krisen zu überstehen und gleichzeitig zu wachsen, eigentlich nur mit echter Agilität erreichbar ist.

Tanja Friedel und Uwe Vigenschow glauben, dass die Zukunft der Softwareentwicklung in einer Rückbesinnung auf die Werte und Prinzipien liegt, die hinter Agilität ursprünglich standen. Außerdem ist eine Fokussierung auf die Ergebnisse zentral - statt auf Hilfsmittel zur Zielerreichung wie Prozesse oder sinnentleertes Feel Good. Sie ziehen die Lehren aus über 20 Jahren Agilität und zeigen den Einfluss z.B. von KI und Homeoffice auf. Und sie berichten, wie sie Kunden dabei helfen, die Arbeitsweisen anzupassen, Anforderungen anders zu erheben und die Struktur der Software anzupassen.

2025-05-16 Thumbnail

PeerTube Video - no Big Tech!

YouTube Video

Audio als Podcast

MP3 Download
Infos und Feeds zum Audio als Podcast

Hinweis: Die nachfolgenden Texte wurden mit KI erstellt und können somit Fehler enthalten.

Post-Agilität: Eine kritische Betrachtung der agilen Transformation

Die agile Transformation hat in den letzten 15 Jahren einen regelrechten Hype erlebt. Doch mittlerweile mehren sich kritische Stimmen, die von “Post-Agilität” sprechen. Was steckt hinter diesem Begriff und welche Lehren können wir aus der agilen Transformation ziehen?

Der Tod des agilen Hypes

Der Begriff “Agilität” wurde in vielen Organisationen überstrapaziert und missbraucht. Statt die agilen Werte und Prinzipien zu leben, wurde Agilität oft auf reine Rituale und Methoden reduziert. Der “Agile”-Sticker wurde wahllos auf Projekte geklebt, ohne die eigentliche Intention zu verstehen. Dies hat dazu geführt, dass der Begriff heute teilweise verbrannt ist.

Dabei war Agilität ursprünglich als Ansatz gedacht, um komplexe Vorhaben zu bewältigen - also Projekte, die sich nicht im Detail vorausplanen lassen. In solchen Kontexten macht ein agiles Vorgehen durchaus Sinn. Der Fehler lag darin, Agilität als universelles Management-Werkzeug zu betrachten und auch dort einzusetzen, wo traditionelle Ansätze besser geeignet wären.

Von Effizienz zu Effektivität

Ein Kernproblem der agilen Transformation war die übermäßige Fokussierung auf Effizienz statt Effektivität. Während sich Effizienz leicht messen lässt (z.B. durch Story Points oder Lines of Code), ist die Messung der tatsächlichen Wertschöpfung deutlich schwieriger.

Dabei war genau das ursprünglich das Versprechen von Agilität: Durch schnelles Kundenfeedback sicherzustellen, dass man die richtigen Dinge entwickelt. Es geht nicht darum, möglichst viele Features in kurzer Zeit zu produzieren, sondern echten Kundennutzen zu generieren.

Diese Neuausrichtung auf Effektivität erfordert auch neue Formen des Stakeholder-Managements. Statt starrer Reporting-Strukturen braucht es einen kontinuierlichen Dialog mit allen Beteiligten über Ziele und Wertbeiträge. Dafür sind sowohl psychologische Sicherheit als auch passende Kommunikationstechniken essentiell.

Lehren für die Post-Agile Ära

Was können wir aus den Erfahrungen der agilen Transformation lernen? Hier einige zentrale Erkenntnisse:

Die Post-Agile Ära bedeutet nicht das Ende agiler Prinzipien. Vielmehr geht es darum, einen pragmatischeren und zielgerichteteren Ansatz zu finden. Statt dogmatischer Methodentreue braucht es maßgeschneiderte Lösungen, die sich an den spezifischen Herausforderungen und Zielen orientieren.

Ausblick: Neue Wege der Zusammenarbeit

Die Zukunft liegt vermutlich in hybriden Ansätzen, die agile und klassische Elemente intelligent kombinieren. Dabei spielen Themen wie Resilienz und Anpassungsfähigkeit eine wichtige Rolle. Organisationen müssen lernen, mit zunehmender Komplexität und Unsicherheit umzugehen.

Erfolgskritisch wird sein:

Der Weg in die Post-Agile Ära erfordert sowohl von Führungskräften als auch Teams ein Umdenken. Es geht nicht mehr um das sture Befolgen von Frameworks, sondern um eine neue Kultur der Zusammenarbeit. Diese muss Raum für kontinuierliche Verbesserung bieten und gleichzeitig klare Orientierung geben.

Die zentrale Herausforderung wird sein, die positiven Errungenschaften der agilen Bewegung zu bewahren und weiterzuentwickeln - ohne in die Extreme zu verfallen, die zum teilweisen Scheitern der agilen Transformation geführt haben.

Folge 263 - Postagilität - Was kommt jetzt?

Wichtige Keytakeaways:

Behandelte Kernfragen:

Glossar wichtiger Begriffe:

Der Podcast betont die Wichtigkeit, sich von reiner Prozess-Agilität zu lösen und stattdessen den Fokus auf echte Wertschöpfung und angemessene Methoden je nach Kontext zu legen.

Vollständige Transkription

Hinweis: Dieses Transkript wurde mit KI erstellt und kann somit Fehler enthalten.

Folge 263 - Postagilität - Was kommt jetzt? mit Tanja Friedel und Uwe Vigenschow

Tanja, willst du erst mal zwei Worte über dich sagen?

Sehr gern.

Erstmal danke für die Einladung, Eberhard.

Vorstellung der Gäste

Tanja Friedel heiße ich.

Tanja Friedel

Ich lebe in Hamburg und bin Partnerin und Principal Consultant bei Swaglab.

Dort berate ich unsere Kunden im Bereich Produkt- und Projektmanagement, das heißt von der Rolle Product Owner, Produkt Manager, Projektleitung, aber auch Business Analyst ist im Grunde alles dabei.

Und ich habe zudem noch einen Hintergrund im Bereich Customer Experience, das heißt mein Fokus sind immer wieder die Kundenbedürfnisse, die ja letzten Endes auch für den Projekterfolg so ganz wesentlich sind.

Dann gebe ich weiter an Uwe.

Ja, danke schön.

Uwe Vigenschow

Ja, mein Name ist Uwe Vigenschow.

Ich bin ebenfalls bei Swaglab Principal Consultant und in meinen Beratungen greife ich halt auf jahrzehntelange Erfahrung als Entwickler, Führungskraft, Berater, Projektleiter, ja, Durchführer von Workshops zurück und vielleicht ein paar Punkte daraus, die vielleicht ganz interessant sind.

Ich habe langjährige Expertise auch im regulierten Umfeld, Qualitätssicherungsaspekte, Testmanagement ebenfalls ein Schwerpunkt.

Ja, das vielleicht so zu den beruflichen Dingen und weil mich so ein Vollzeitjob ja auch nicht so vollständig auslastet, schreibe ich noch nebenbei, man könnte es auch als therapeutisches Schreiben bezeichnen.

Ich habe mittlerweile sieben Bücher mitgeschrieben oder geschrieben, knapp 50 Artikel und ab und an trifft man mich auch auf Konferenzen, wenn ich versuche, spannende Themen irgendwie darzustellen, also für mich spannende Themen darzustellen.

Ich hoffe, ich finde genug Mitstreiter.

Genau, erstmal vielen Dank dafür und also das Thema ist ja mit Postagilität und Space Federation hat heute Morgen schon im YouTube-Chat gefragt, was denn nun die Post mit Agilität zu tun hat und das möchte ich kurz gerne erklären.

Also, ich habe tatsächlich Latein auf der Schule gehabt und in Lateinisch bedeutet Post so etwas wie nach, das heißt, wir diskutieren also über sowas wie nach der Agilität und das führt irgendwie zu dieser Frage, ist Agilität tot und wenn ja, woran ist sie denn eigentlich gestorben?

Ich mache vielleicht hier einfach mal den Start.

Gestorben ist natürlich ein sehr, sehr starkes Wort, aber man hat die Agilität schon arg überstrapaziert, also so eine Art, vielleicht ist das Buzzword Agilität gestorben.

Also das heißt, man hat Agilität meiner Meinung nach viel zu sehr nur über die Rituale funktionieren lassen, hat sie in Bereiche eingeführt, wo sie vielleicht gar nicht so unbedingt hingehören und da dann wiederum auch so ein bisschen verbrannt, weil das, was eigentlich hinter der Agilität steckt, dort dann gar nicht mit den Werten gelebt wurde.

Uwe, du kannst das bestimmt noch ergänzen.

Ergänzen, auf jeden Fall auch bestätigen, was du sagst.

Es gab ja regelrecht einen Hype über, Größenordnung mäßig, 10, 15 Jahre und da gab es ja richtig so einen Marketingsticker Agil, der auf allem draufgeklebt hat und wenn alles Agil ist, dann ist auch irgendwie nichts Agil und du kannst überhaupt nicht mehr unterschreiben, was eigentlich was ist und das verbrennt natürlich.

Das ist ein Effekt, den man bei vielen Hype-Kurven hat und hier leider auch und genau wie du schon sagst, da ist eine Menge passiert, insbesondere auch durch das Missverständnis, wir haben jetzt hier ein neues Management-Werkzeug und da setzt man jetzt ein, wie man in einem traditionellen Projektmanagement jetzt zum Beispiel eine ganz bestimmte Planungstechnik einsetzt und verändert ansonsten nichts weiter und verspritzt sich davon den Mega-Erfolg und das ist genau gerade das, was mit Agilität nicht wirklich gut funktioniert, weil es halt ein übergreifendes Konzept ist zur Bewältigung komplexer Aufgaben.

Das heißt, ich muss mich ganz grundsätzlich anders aufstellen, als mit der Bewältigung zum Beispiel komplizierter Aufgaben oder werden wir sicherlich noch darauf zurückkommen.

Vielleicht noch zwei Worte zu dem, was vorher passiert, also bei dem LinkedIn-Posting, mit dem wir den Stream angekündigt haben, da hat der Michael Malberg, der auch zum Beispiel mit der Architektur mit organisiert, heruntergeschrieben, dass er total dankbar ist, dass er dieses Thema irgendwie aufgreift, was für mich so ein bisschen zu der Frage führt, ob Post-Agilität so ein richtig fester Begriff ist, also wie Agilität oder ist das jetzt eben tatsächlich nur nach Agilität und nicht, wo man jetzt sagt, das sind exakt diese Prozesse, also es gibt ja auch in der Kunst Postmodernismus und solche Geschichten.

Ist das schon so ein fester Begriff?

Post-Agilität als Begriff

Ob er jetzt so fest definiert ist, würde ich jetzt vielleicht nicht unterstreichen, aber man versteht da meistens zwei Dinge darunter.

Balance in Organisationen

Zum einen halt den Aspekt, dass man versucht, auch ganze Organisationen durchgängig zu agilisieren, was vielleicht auch nur die drittbeste Idee ist, weil es einfach Bereiche gibt, wo das überhaupt nicht sinnvoll ist.

Ich sagte schon, es geht ja um die Bewältigung komplexer Aufgaben und wenn ich jetzt andere Bereiche habe in Organisationen, die sich nur mit komplizierten Themen befassen, dann greift das ins Leere und ich baue eine Bürokratie auf, die ich überhaupt gar nicht brauche.

Das heißt, hier muss man Dinge wieder in die Balance bringen.

Ich sagte schon, so ein Hype, das heißt, irgendwas schiebt hoch und das muss man jetzt wieder in die Balance dahin packen, wo es sinnvoll ist.

Dann kann es Kraft entfalten und dann ist natürlich die zweite Frage daraus, was bedeutet das für die Softwareentwicklung selber, um uns da aufzustellen.

Ich denke, meine persönliche Meinung dazu ist, dass das Ganze auch sehr, sehr stark mit dem Thema der Resilienz im Zusammenhang steht.

Das heißt, wie schaffe ich widerstandsfähige Strukturen in Organisationen, die in der enormen Dynamik, die wir seit etlichen Jahrzehnten, naja, wenigen Jahrzehnten erleben, mit Krise nach Krise nach Krise und 2001, 2002 die erste Finanzkrise, 2008, das beschleunigt sich ja, Corona, Ukraine und jetzt der Wechsel, der in den USA stattfindet.

Da müssen wir wahnsinnig widerstandsfähig werden und darauf angemessen reagieren.

Da spielt das Ganze, glaube ich, mit rein und da kann es auch enorme Wirkung entfalten.

Ich glaube, damit hast du den anderen Punkt auch schon aufgegriffen, der mir auch bei diesem LinkedIn-Ankündigung gerade zu einer Diskussion geführt hat zwischen dem Stefan Trott und dem Alex Thiessen, eben genau über diese Unterscheidung zwischen Business-Agilität und sozusagen Software-Agilität.

Wenn wir gerade bei der Interaktion sind, also der Karl Schmolke auf YouTube hat gerade vor ein paar Minuten geschrieben, bezüglich der Mis-Usage, die Kerngedanken werden nur selten wirklich eingeführt, beziehungsweise als Fortgesetz, geschweige dann gelebt.

Irgendetwas, was ihr dazu sagen wolltet?

Irgendetwas, das da für euch ein Thema wäre?

Das war in Grunde das, was ich vorhin auch schon mal angeteasert habe.

Da werden dann Methoden eingeführt, dass man sagt, man macht irgendwie Dailies und man führt Sprints ein, aber die eigentlichen Werte der Agilität, also sprich, man möchte Individuen und Interaktionen stärken und schnell eine lauffähige Software produzieren und auch in Feedback-Runden mit den Kunden gehen und auch das Team als solches stärken und versuchen, eigenständig agieren zu lassen.

Das sind so die eigenen Werte, die oftmals dann nicht mit reingespült werden in die Teams.

Da schreibt man Agilität drauf, meint aber eigentlich eine Methodik und das ist dann, glaube ich, immer diese Mis-Usage des Wortes Agilität.

Wofür ist Agilität eigentlich gedacht gewesen?

Also warum ist denn überhaupt dieser, also das ist ja irgendwie ein Hype, klar, aber normalerweise haben die Hypes ja irgendwie einen Auslöser.

Welches Problem hat es versucht zu lösen?

Wofür war Agilität gedacht?

Ich hatte ja schon gesagt, es ist eigentlich gedacht gewesen, dafür komplexe Vorhaben zu bewältigen.

Komplexität vs. Kompliziertheit

Komplex heißt, wenn man es mal ganz vereinfacht definiert, ein Vorhaben, was ich nicht vorab planen kann.

Und weil einfach zu viele Aspekte eine Rolle spielen, die sich gegenseitig bedingen und wo ich gar nicht mehr klar Ursache-Wirkungsketten im Vorhinein analysieren kann.

Und wenn ich an so einen Bereich komme, dann ändert sich das Verhalten oder die Art und Weise, wie ich ein solches Vorhaben gestalte und unterscheidet sich von einem zum Beispiel komplizierten Vorhaben.

Weil was jetzt komplex und kompliziert ist, ist natürlich auch immer eine sehr individuelle Sache.

Also wenn bei mir einmal im Jahr der Heizungsinstallateur zur Wartung der Heizungsanlage kommt, dann ist das für ihn bestenfalls kompliziert.

Der kann mir sehr genau sagen, wie lange das dauert und was vielleicht passieren kann anhand der Parameter.

Welche Anlage ist das?

Wie alt ist sie?

Und wie gut ist sie gewartet?

Für mich persönlich wäre das vermutlich eine Aktion über ein ganzes Wochenende.

Und ich wüsste nicht, ob ich damit fertig wäre, weil ich müsste mich erst mal schlau machen, was wie wo da eigentlich zu tun ist und wie das alles zusammenhängt.

Das heißt, zu einem gewissen Grad hängt das auch mit der Erfahrung der Teams, der Leute zusammen, was jetzt wirklich komplex ist und was nicht.

Irgendwann hat man aber immer diese Grenze erreicht, dass man es nicht mehr vorab planen kann.

Und gerade wenn man so viele Außenwirkungen hat oder Abhängigkeit nach außen hat, wirtschaftlicher Natur, inhaltlicher Natur, technischer Natur.

Wenn ich mir jetzt mal angucke, was es alles braucht, um eine ordentliche Pipeline aufzubauen für CI, CD und wie das auch in den 90ern aussah.

Da spielen ganz andere Komponenten eine Rolle und eine ganz andere Vielfalt.

Das kann ich alles gar nicht mehr vorab planen.

Da muss ich vermutlich viel stärker in so zyklische Mechanismen reingehen, die mir auf mindestens zwei verschiedenen Ebenen eine Koppelung geben.

Einmal ganz schnell über das, was ich tue und dann auf einem höheren Level, wie arbeiten wir eigentlich und wie können wir das verbessern?

Also auch in einen kontinuierlichen Verbesserungsprozess reinzugehen.

Und das ist sehr anspruchsvoll und nicht einfach.

Und das lernt man auch nicht an einem Wochenende oder an einem Jahr.

Das wird auch ewig gebraucht, um das zu durchdringen.

Genau.

Der Karl Schmolka hat gerade geschrieben, es hat sich mehr Fake Agile etabliert als wirkliches Agile.

Sobald es als Managementplanungsinstrument eher in Unternehmen gesehen wird, dann verliert diese Methodik seine Mächtigkeit.

Eigentlich habe ich jetzt aus der Aussage mitgenommen, dass so eine Fortsetzung, womit die Arbeit ausgeführt wird, wo man von Azure profitieren wollte.

Irgendwie habe ich jetzt von dir, Uwe, mitgenommen, dass das etwas ist, womit ich komplexe Situationen, also Sachen, wo ich nicht mehr klar sehen kann, wie Dinge nicht mehr klar planen kann, wie ich damit umgehen kann.

Für mich hört sich das so ein bisschen an wie, naja, aber es gibt irgendwie Situationen, in denen ich ein stärkeres Maß an Planbarkeit haben kann.

Das habt ihr jetzt nicht so explizit gesagt, aber der Eindruck ist bei mir entstanden.

Was dann für mich bedeutet, es gibt also diese Nische, in der Agilität sinnvoll ist.

Es gibt diese anderen Sachen.

Eigentlich würde das jetzt bedeuten, dass wir nur Agilität dort benutzen müssen, wo es sinnvoll ist.

An anderen Stellen vielleicht etwas anderes.

Aber wieso dann Post-Agilität?

Also das bedeutet ja eigentlich, dass man sagt, nee, wir brauchen etwas komplett Neues und das mit der Agilität, das ist jetzt vorbei.

Der Begriff sagt das ja.

Oder ist der Begriff irgendwie nicht verbrannt?

Du bringst es auf den Punkt, Uwe.

Der Begriff ist verbrannt und vielleicht ist es jetzt auch einfach der Versuch, sich durch einen neuen Begriff davor zu lösen, zu sagen, wir schließen jetzt die eine Tür und machen eine neue auf.

Vielleicht auch in die Gefahr laufend, dass auch irgendwann die Post-Agilität verbrannt ist, weil man es wieder nicht geschafft hat, bei den Werten zu bleiben und da eine sinnvolle Lösung aufzubauen.

Aber das ist ja auch das Gute an der Agilität.

Wir bleiben da flexibel und stellen uns immer auf die neuen Umstände ein.

Genau.

Das passt, glaube ich, gut zu dieser Tendenz, die wir für der Panzerbranche insgesamt haben, Begriffe hochzuwerfen, die unklar definiert sind oder zumindest nicht verstanden werden.

Dann hat man das Problem, dass sie sogar pervertiert werden.

Was sind die Lehren denn daraus?

Was sind jetzt die Lehren aus Agilität und was machen wir jetzt in Post-Agilität anders oder besser?

Für mich persönlich sind die Lehren daraus, dass so ein Framework oder Mindset auch für jedes Unternehmen individuell sein muss.

Man kann nicht einfach eine Begrifflichkeit oben drüber stülpen.

Agilität als solche ist ja kein Selbstzweck, sondern es geht um die dezidierten Werte dahinter.

Das heißt, nicht jedes Projekt muss agil aufgebaut werden.

Dieser blinde Glaube jetzt da dran, ich mache einen Sticker drauf, steht Agilität drauf und dann wird das schon.

Sondern man muss halt auch wirklich individuell schauen.

Ich hatte auch schon Kunden, da waren die Teams so divers aufgebaut.

Da waren Personen dazwischen, die gesagt haben, das Ganze jetzt agil zu machen, das macht doch überhaupt keinen Sinn.

Ich habe eine ganz klare Vorstellung davon, wie wir hervorgehen müssen.

Wir haben eine klare Timeline.

Was soll ich meine Zeit jetzt damit verschwenden, in irgendwelchen Meetings zu sitzen?

Das heißt, das war auch eine Situation, wo man gemerkt hat, dass genau dieser Sticker obendrauf, da konnten die Leute in dem Team überhaupt nichts mit anfangen.

Deshalb glaube ich, ist eine der großen Lehren, das einfach mal wieder neutral zu betrachten und auch zu schauen, was ist denn zum Beispiel der Wert, der dahinter steckt, dass man Werte für den Kunden schaffen möchte.

Dann muss man halt immer wieder drauf eingehen und einen Abgleich machen.

Also machen wir jetzt hier wirklich Agilität zum Selbstzweck oder schauen wir, dass wir da auf ein Ergebnis einzahlen.

Das ist so mein Gedanke dazu.

Uwe, du hast da sicherlich auch noch so deine Lehre.

Genau, das passt schon.

Also zum Teil habe ich es auch erlebt, dass wirklich Leute dahin wollten in Agilität, ob es wollte oder nicht, weil es einfach der Hype war.

Da muss man auch versuchen, sich wirklich klar abzulehnen.

Zum anderen wurde das aber zum Teil auch von Top-Management aufgezwungen.

Ich habe es auch gesehen in einem Bereich, wo mehrere Teams parallel gearbeitet haben und ein Team sich im Wesentlichen um das Thema Bug-Fixing und kleine Refactorings gekümmert hat.

Der entsprechende Begleiter, Coach, Manager hat das Ganze mit einem sauberen Kannwahn aufgezogen und das war es rein, war wunderbar, hat fantastisch funktioniert, bis dann die Ansage seines Chefs kam, nein, bei uns arbeiten alle nach Scrum.

Nee, das ist es halt eben nicht.

Und dann wurde da ein Scrum draufgesetzt und du hast nur noch Bürokratie-Overhead.

Und der schöne, schlanke, sehr gut funktionierende – das war ja das Verrückte, da wurde was repariert, was gar nicht kaputt war – sehr schön funktionierende Prozess war auf einmal wirklich auch verlangsamt.

Und natürlich gab es dafür einen Grund, weil es dann einfacher wäre, Leute dann wieder zwischen den Teams wechseln zu lassen und so weiter.

Aber ganz im Ernsten, dann hat man immer eine Einarbeitung, wenn man so etwas macht.

Und Teams so aufzubauen, dass man das gut wechseln kann, habe ich auch schon einmal gesehen, ist aber eine sehr, sehr schwere Aufgabe.

Da sind wir in ganz anderen Dimensionen.

Im Großen und Ganzen das Werkzeug auswählen, was für die Aufgabe angemessen ist.

Viele Aufgaben sind komplex, deshalb ist Agilität an der Stelle auch genau richtig.

Aber Bezogenheit auf Wert für den Kunden schaffen, nicht Selbstzweck und wo das nicht sehr sinnvoll ist oder wo wir mit leichteren Methoden auskommen oder leicht gewichtiger Methoden, kann man wunderbar dann auch das anwenden.

Macht Spaß, schafft Ergebnisse.

Ich befürchte, ich komme nicht umhin, zu diesem Austauschwerkzeug zwischen Teams noch etwas zu sagen.

Also wenn das sozusagen ein wichtiges Ziel ist, spannend.

Und insbesondere ist ja die Frage, wenn ich jetzt eine relative Priorisierung durchführen möchte, zwischen Austauschbarkeit zwischen Teams und Effektivität oder Effizienz.

Also ist eben die Frage, ob eben die Austauschbarkeit zwischen den Teams wirklich das Wichtigste ist.

Aber gut.

Der Gromio bei YouTube hat geschrieben, nehmen wir an, Agilität ist tot.

Was wäre die echte Alternative für ein komplexes Umfeld?

Ich spiele den Ball mal zu dir, Uwe, weil ich denke gerade noch, ohne weiter zu beantworten.

Ja, ich denke, das, was du vorhin gesagt hast, Agilität ist tot, ist ja das Thema des Hypes, des Marketingbegriffs Agilität.

Wir können alles damit erschlagen oder was auch gerne immer verkauft wurde im Top-Management.

Ihr seid dann schneller.

Ja, schneller im Vergleich zu was?

Und dann stellt man fest, wenn man das nicht richtig macht, man zieht eine irrsinnige Bürokratie hoch und man ist sogar eher vielleicht sogar langsamer im schlimmsten Fall.

Was wären die echten Alternativen?

Na ja, guckt an, wie kann man Komplexität bearbeiten?

Welche Vorgehen gehen dort?

Eine sehr einfache Strukturierung kann man bei Hinnifin rausfinden, von Dave Snowden.

Und auf der Basis wird man dann auch sofort erkennen, was das Grom aus der ganzen Systemtheorie dort rausgezogen hat und wie es das dort darum aufgebaut hat als Management-Framework.

Das ist ja ein Projekt- Management-Framework, kein Entwicklungs-Framework.

Das wäre die echte Alternative.

Ich denke, es ist einfach richtig machen.

Richtig im Sinne angemessen, fokussiert auf die Ergebnisse, das, was wir eigentlich schaffen wollen, auf die Kommunikation.

Es ist ein kommunikationszentriertes Vorgehen und auf den kontinuierlichen Verbesserungs- und Anpassungsprozess, der dahinter steckt.

Also im Grunde wieder Agilität aus der Kiste holen, aber in richtig, wie es eigentlich gedacht ist.

Also es geht ja auch nicht darum, das ist tot und wir lassen es jetzt im Dreck liegen, sondern es geht ja darum, sich wieder rückzugesiedelt zu machen.

Von dem, was er bisher gesagt hat, hat er im Prinzip gesagt, der Begriff ist halt schwierig.

Das Vorgehen ist für bestimmte Situationen, insbesondere ein komplexes Umfeld, sinnvoll.

Sodass, wenn er diese Frage hat, ist, was ist denn eine Alternative für ein komplexes Umfeld?

Also nicht das, was vorher schon funktioniert hat, nur dass man es vielleicht nicht mehr agieren lernt.

Genau, da sind noch ein paar andere Kommentare oder Themen.

Also der Andy F. hat geschrieben, ich glaube, man müsste sich auf die Ursprünge zurückbesinnen.

Eben nicht Scrum oder Ähnliches im Sinne von, es finden dauernd Meetings statt, die in 90 Prozent der Fälle für mich nicht relevant sind.

Und dann schreibt Jürgen, ich glaube, das ist so ein bisschen, baut da drauf aus.

Leider ist man nicht agil, wenn man nicht Scrum, Kanban, Scrumban etc.

Framework verfolgt.

Für mich reicht Customer Collaboration over Contract Negotiation and Responding to Change over Following a Plan.

Sind die aus dem agilen Manifest, wenn ich es richtig sehe, nicht?

Also Kundenzusammenarbeit und nicht Verträge respektive, dass man eben auf Änderungen reagiert und nicht am Plan festhält, dass das eben so die Basis ist.

Ganz kurz, ich bin jetzt ein bisschen picky, aber da steht mit Absicht over.

Das heißt, das sind Wertepaare, die aufgestellt sind im agilen Manifest.

Das heißt nicht, das eine ja, das andere nicht, sondern das eine fokussieren wir und das andere setzen wir so ein, dass es das Erste unterstützt.

Das heißt also Customer Collaboration over Contract Negotiation.

Ja, aber wenn wir Contract brauchen, ja, aber dann machen wir sie so, dass sie die Customer Collaboration unterstützt.

Das ist halt eben der wichtige Punkt an der Stelle und over Following a Plan.

Ein Plan ist immer sinnvoll und zwar nicht wegen des Planartefakts als Ergebnis, sondern wegen des Planungsprozesses.

Und Responding to Change ist aber das, was wir dadurch haben wollen.

Das heißt, wir reden über bestimmte Aspekte im Planungsprozess, Timebox, versuchen das darzustellen, haben Variationen schon im Kopf und sind deshalb dann in der Realität unter Umständen schon viel besser vorbereitet.

Was wir nicht machen, ist einmal im Plan aufstehen, dem Stuhl folgen.

Das wäre so, als wenn ich Auto fahren würde, indem ich es nach da hinten setze, das Ziel halte, das Lenkrad festmache, die Augen zu und drücke das Gaspedal durch.

Wir wissen, wie das enden würde.

Ich würde gern kurz nochmal auf den Kommentar von Andi eingehen.

90 Prozent der Fälle nicht für mich relevant sind.

Ich glaube, das ist auch ein Problem.

Diese Meetings müssen natürlich eine Relevanz für alle Teammitglieder haben.

Ansonsten hat es ja gar keine Bewandtnis.

Dann sind wir nämlich wieder bei dem Punkt, es wurde drüber gestülpt und hat überhaupt keinen Nutzen für das Team, für das Projekt und dergleichen.

Also man sollte diese Meetings auch wirklich nur halten, wenn es für alle sinnvoll ist und alle auch weiterbringt.

Das ist so ein bisschen der Schmerz, den man an dieser falsch eingesetzten Agilität dann auch spürt.

Und genau das soll nicht sein.

Also ich persönlich finde auch, dass das ein total wichtiger Punkt ist, weil Softwareentwicklung ist im Wesentlichen ein Kommunikationsprozess und deswegen sind Meetings halt wichtig.

Das Problem ist halt nur in Anfangsstrichen, dass die halt irgendwie oft nicht wirklich hilfreich sind.

Entschuldigung, das ist aber genau zum Beispiel in dem Fall jetzt, wenn wir uns Gramm angucken, es gibt ja auch noch Anwälte, wenn wir uns Gramm angucken, wer ist die Verantwortung des Gramm-Masters oder der Gramm-Masterin, hier dafür zu sorgen, dass es wertvoll ist.

Das kann immer mal passieren.

Man kann mit sehr wertvollen Meetings anfangen und nach zwei Jahren sind sie nicht mehr wertvoll, weil sich die Teams weiterentwickelt haben und wir über Dinge sprechen, die eigentlich klar sind oder die Leute langweilen.

Das immer wieder anzupassen und zu challengen, herauszufordern, anzupassen, habe ich schon gesagt, weiterzuentwickeln, das ist das, was ich sagen wollte, das ist das Wichtige, was da passiert.

Man darf nicht an einem Punkt X stehen bleiben, sondern es ist eine permanente Weiterentwicklung.

Nicht nur der Software, auch der Prozesse, die Teams, jeder Entwickler, jede Entwicklerin, alle Manager entwickeln sich weiter, Kunden entwickeln sich weiter.

Das ist ein Moving Target und das ist das Wichtige, das nochmal wieder hinzubekommen und das sind Indikatoren.

Wenn ich ein Meeting habe, was mir keinen Wert mehr bringt, dann heißt das, mache jetzt was, was wieder Wert bringt.

Dann hatten wir den Christoph Keimel auf YouTube.

Postagentität sollte sich wieder stärker auf die Ursprünge agieren, Arbeitensbesinn, auf das Ziel wertschaffend, anpassungsfähig und nutzerzentriert zu arbeiten.

Was ich dabei so lustig finde ist, Postagentität sagt eben nach Agilität und das ist eigentlich mehr die Forderung nach einem Prequel.

Wir kommen wieder zu dem, was er vorher gemeint hat.

Dann schrieb Karl Schmolke noch, dass AM, ich weiß nicht was AM ist, lässt sich leider nur so schlecht verkaufen, die ganze Zeit die verkaufte Bücherschulung.

Weiß ich auch nicht, Klaas ist das, Klaas Schmolke.

Sagt mir jetzt auch nichts, Klaas, kannst du das nochmal kurz?

Wobei man halt sagen muss, es gibt ja diese, wie soll ich sagen, achso, ich, Stefan hat es gewählt, das Agile Manifest.

Das hatte ich schon mal gehört.

Danke, da stand ich auch auf der Leitung.

Ja, man darf aber auch nicht vergessen, das Ganze ist auch schon fast 25 Jahre alt und was hat sich seitdem getan?

Und wenn wir uns zurück besinnen auf die Werte, stellen wir fest, dass das eigentlich immer noch ganz gut funktioniert.

Prinzipien, ja, aber es sind so ein paar Punkte, wo man auch wirklich genau gucken muss, kann das überhaupt noch funktionieren?

Also ein ganz wichtiger Punkt in der Agilität, wenn wir uns das angucken im Jahr 2000, 2005 oder so oder 2010 ist Co-Location.

Das heißt also ein Team, ein Ort, alle zusammen.

Da gab es Kommunikationskonzepte, osmotische Kommunikation und so weiter, einfach, dass ich mitkriege, was um mich herum passiert und deshalb immer gut auf Stand bin.

Tolle Idee, aber heutzutage stehen wir vor ganz anderen Voraussetzungen.

Wir haben einen ganz anderen Grad von Verteilung erreicht, wo wir Alternativen dafür schaffen müssen.

Und deshalb kann ein solches Framework als diese Manifestation dieser Prinzipien auch nicht mehr so aussehen, wie es das Framework 2005 aussah.

Also eine Sache noch, der MD42Martin bei Twitch hat gesagt, this meeting could have been an email chat.

Also manchmal können in Meetings ein E-Mail oder ein Chat gewesen sein.

Und er schreibt halt weiter, manchmal werden zu viele eingeladen, statt Mut zur Lücke und zu gute knackige Meetings zu machen.

Das ist aber auch ganz oft so eine Unternehmenskulturgeschichte.

Also das hat auch meiner Meinung nach immer viel mit der Fehlerkultur in einem Unternehmen zu tun.

Dann wird oftmals gesagt, ja, lad alle ein und dann kann sich hinterher niemand beschweren, sonst kriegen wir wieder Ärger.

Und da gibt es ja manchmal auch so eingefahrene Muster in Unternehmen, die dann immer weiter gefolgt wird, um sich selber abzusichern.

Und da würde ich mir halt auch häufiger mal wünschen, dass Unternehmen auch ein größeres Vertrauen in ihre Teams haben und in das, was sie tun.

Das ist aber leider auch nicht überall gegeben.

Gut.

Wir hatten jetzt gleich so ein…

Achso, genau.

Vielleicht ganz kurz.

Free Glide.

Jude schreibt gerade, da kann ich nur zustimmen, Tanja.

Ja, definitiv.

Wichtig ist dabei aber auch, dass die Teams sich nochmal vergegenwärtigen.

Du hattest es vorhin gesagt, den Wert für den Kunden zu schaffen.

Und im Endeffekt kann man das ja, muss man einfach sagen, wir müssen in einem Monat mit einem Team, durchschnittlichem Team, einfach auch ein gewissen, gewisse Einnahmen machen, gewissen Umsatz machen.

Sonst trägt sich das einfach nicht.

Und wenn man sich das mal vergegenwärtigt, sind das ganz schön hohe Zahlen.

Das heißt, ein Scrum Team jetzt nicht plus minus 10.000 Euro jetzt einfach nur, damit man knackige Zahlen hat.

Ein Scrum Team 100.000 pro Monat.

Das heißt, wir brauchen mit einem Scrum Team einen Umsatz von einer Million plus, einfach nur, damit es sich plus minus null trägt.

Und das heißt wirklich, wir müssen sehen, dass wir in engem Kontakt mit dem Kunden die Sachen machen, die die meiste Wirkung schaffen, so dass wir wirklich auch dieses Ziel erreichen und auch gleichzeitig durchaus Spaß dabei haben.

Weil Ergebnisse, die benutzt werden, wo die Kunden wirklich Wert von rausziehen können, sowas macht ja auch Spaß.

Deshalb machen wir ja auch unseren Job in der ursprünglichen Motivation hin.

Das gehört nämlich auch zu dieser Rückbesendung.

Genau das, was du gerade sagst, Uwe, das ist ja auch das Dilemma.

Also da entstehen enorm hohe Kosten.

Diese Kosten müssen von einem Menschen freigegeben werden im Management.

Und das heißt, diese Person steht ja auch gerade für das, was in diesen Projekten passiert, die so wahnsinnig hohe Kosten verursachen.

Das heißt, da ist auch immer ein gewisser Grad an Überwachungswunsch auf der Seite vorhanden.

Und da ist ja auch Vertrauen gefordert von Seiten des Managements oder der Stakeholder an der Stelle.

Was aber auf der anderen Seite natürlich auch dahingehend bedient wird, dass man auch durch das iterative Vorgehen immer schnell auch schon Ergebnisse produzieren kann.

Die aber leider nicht immer eine feste Roadmap haben, dass man sagen kann, heute in zwölf Monaten ist dieses Projekt abgeschlossen.

Da steht ja immer noch dieses kleine Fragezeichen dahinter, weil wir es ja nun mal mit einem komplexen Umfeld, mit komplexen Anforderungen zu tun haben.

Und das ist einfach so ein Geben und Nehmen zwischen dem Projektteam und dem Management.

Und das ist auch etwas, was uns häufiger begegnet im Alltag, in unseren Rollen.

Uwe, du betreibst ja auch vergleichbare Rollen wie ich.

Das heißt, man ist dann immer so ein bisschen in dieser Rolle wie zwischen Baum und Borke.

Man hat sein Projektteam, man hat ein Management und man muss dazwischen vermitteln und da auch die Brücken schlagen.

Und da ist halt auch immer wieder das Stakeholder-Management ein sehr, sehr großer Part, indem man da Transparenz schafft in alle Richtungen auch.

Also so die gleiche Transparenz, die ich dem Management gegenüberbringe, möchte ich aber auch in mein Entwicklungsteam übertragen.

Das ist mir persönlich immer ganz wichtig, dass auch jeder weiß, was sind die Ziele, was sind die Probleme und wie können zum Beispiel wir als Entwicklungsteam zu diesen Zielen beitragen und umgekehrt aber auch Ausrichtung des Management, was braucht ihr, damit ich euch hier freie Wege schaffen kann.

Und das ist auch wirklich immer eine große Herausforderung, weil es auch leider manchmal in den Unternehmen heißt, wir gegen die.

Also da sind halt, eigentlich haben ja alle das gleiche Interesse.

Man möchte ein erfolgreiches Produkt in den Markt bringen, was einen hohen Kundennutzen hat, aber die Sicht auf die Dinge sind oftmals leider andere.

Und da ist es halt immer ganz, ganz wichtig, da gut zu vermitteln.

Exakt, 100 Prozent d’accord.

Genau, ich will noch einen Punkt kurz sozusagen unterstreichen, weil ich das halt auch tatsächlich persönlich wichtig finde.

Das war dieser Hinweis auf den Wert, der halt geschaffen wird.

Ich glaube, das ist so eines der Grundprobleme, was wir halt haben.

Es ist halt irgendwie easy, die Kosten zu messen, nicht?

Also Tagessätze mal an zwei gearbeiteter Tage fertig.

Es ist, glaube ich, irgendwie super schwierig, diesen Wert zu messen.

Und das ist aber eigentlich der Punkt, nicht?

Das würde ich gerne nochmal unterstreichen.

Und das ist irgendwie genau eine von den Sachen, wo ich glaube, wir ein Problem haben, weil eben die Kosten einfach messbar sind.

Man ist, glaube ich, sehr stark dazu verleitet, irgendwie genau die zu managen.

Und das ist halt falsch, nicht?

Also wenn wir halt irgendwie anfangen und die Kosten reduzieren, aber vernachlässigen, dass wir eigentlich Werte produzieren müssen, dann geht es halt irgendwie schief, nicht?

Weil wenn wir halt Mist produzieren, aber wir produzieren den billiger, dann ist das halt immer noch Mist.

Das bringt uns nichts.

Tatsächlich wieder ein paar Sachen aus dem Chat.

Also Karl Schmolke hat geschrieben.

Sorry.

Ich lachte nur, weil er die Abkürzung gleich hätte.

Aber KVP hätte ich jetzt erkannt.

Genau.

AM, also Agiles Manifesto und KVP, kontinuierlicher Verbesserungsprozess, sind meiner Erfahrung nach die beste Kombination, um sich auf die Wertschöpfung fokussieren zu können.

Fake-Adult-Business-Theater leider, finde ich.

Also diese Theater-Metapher hatte ich vor kurzem auch für ein Architektur-Theater.

Hat der Kevin Henney sich irgendwie überlegt.

Und das, finde ich, passt sehr gut, nicht?

Also man spielt was vor.

Dann hat der Marco Wesselmann geschrieben.

Es gibt natürlich auch einen Markt für Coaching.

HR verkauft sich beim Management nun mal gut.

War selbst in einem Projekt, wo agile Religion mit allen Meetings und man nicht aufs Team hörte.

Und Jutro hat noch geschrieben.

Meiner Meinung nach sind Team-Topologies auch entstanden, um Punkte, die nicht mit dem bewährten AGM-Frameworks auch gebildet werden können, zu lösen.

Das führt auch zu besserer, gezielter Kommunikation.

Okay, dann haben wir das einmal diskutiert.

Jetzt ist die Frage, was machen wir mit der Situation, so wie sie ist?

Und wo setzen wir das an?

Und er hatte jetzt im Vorgespräch gesagt, dass wir ein Thema die Schnittstellen des Teams sind.

Also dass man sagt, das Team agiert nach draußen.

Und da gibt es verschiedene Dimensionen, die da eine Rolle spielen.

So sagt er jedenfalls.

Und eines dieser Themen ist halt Stakeholder-Management.

Warum ist das wichtig?

Und warum bringt uns das sozusagen weiter?

Dass man in einem Projekt Stakeholder-Management muss, hat sich, glaube ich, so weit herumgesprochen.

Jetzt ist die Frage, warum ist das etwas, wo man jetzt sagen kann, okay, das hilft uns in dieser postagierenden Welt, da wo wir mit Agilität vielleicht nicht weiterkommen oder wo der Begriff verbrannt ist.

Warum hilft uns da so etwas wie Stakeholder-Management weiter?

Stakeholder-Management

Das ist vielleicht sogar ein sehr traditionelles Ding.

Das ist auch tatsächlich so ein Leidenschaftsthema von mir.

Bedeutung und Ziele

Also grundsätzlich ist Stakeholder-Management ja allein schon mal deshalb wichtig, um die ganzen Erwartungen und Bedürfnisse aller relevanten Personen abzuholen, was die sich von diesem Projekt oder Produkt wünschen.

Das heißt, man muss die identifizieren, analysieren und dann im Grunde auch überführen.

Und das können natürlich zum einen das Management sein, aber auch das sind die Entwicklungsteams selber und andere Abteilungen, Fachbereiche und nicht zuletzt auch die Kunden.

Also das heißt, Ziel ist es ja auch mit unserem Projekt oder Produkt eine Zufriedenheit bei den Stakeholdern zu schaffen.

Also unterm Strich gehört zu unseren Stakeholdern ja auch, wie eben schon gesagt, jemand aus dem Management, der halt seine Freigabe für diese enormen Kosten auch gegeben hat.

Das heißt, das ist natürlich auch der Wunsch, diese Personen oder Personen entsprechend abzuholen.

Also grundsätzlich wollen wir natürlich auch Missverständnisse vermeiden und auch die Unterstützung von diesen Personen gewinnen.

Wir wollen Risiken frühzeitig erkennen.

Das tun wir darüber hinaus ja auch noch über Risikomanagement idealerweise.

Und so können wir dann sicherstellen, dass auch alle an einem Strang ziehen.

Und ich finde auch gerade diesen Fokus auf die Ziele, Wünsche, Erwartungen von den Stakeholdern so wichtig, weil das Entwicklungsteam die ja auch braucht, um an den richtigen Dingen zu arbeiten.

Also was auch nochmal zusätzlich darauf einzahlt, an einem Strang zu ziehen.

Das heißt, da den Austausch schaffen, die Klarheit schaffen und die Transparenz schaffen, dass das Entwicklungsteam die richtigen Dinge tun kann und über alle Anforderungen auch Bescheid weiß und dann entsprechend auch selbstorganisiert mitwirken zu können.

Also nichts ist ja schlimmer, als ein Entwicklungsteam zu haben, die sagen, ich brauche nur Tickets, die arbeite ich dann von oben bis unten ab.

Ich möchte ja auch Personen in meinem Entwicklungsteam haben, die sagen, Mensch, pass mal auf, hier hast du eine Story geschrieben.

So wie ich das jetzt verstanden habe, zahlt es auf das und das Ziel ein.

Aber ich glaube, das können wir viel besser erreichen, indem wir dieses oder jenes machen.

Solche Menschen möchte ich ja in meinem Entwicklungsteam haben, die mitdenken und auch die Vorgaben hinterfragen, weil sie das Ziel darüber kennen.

Und deshalb finde ich es halt so wichtig, dass frühzeitig auch alle mit einbezogen werden.

Bei den Stakeholdern ist ja vielleicht auch nochmal immer ein spannender Punkt in der Diskussion.

Jeder sieht ja auch nur einen Ausschnitt des Ganzen.

Nicht technische Stakeholder können die Technik in der Regel schlecht beurteilen.

Technische Stakeholder können die Konsequenzen bestimmter Anforderungen nicht abschließend beurteilen, weil ihnen das fachliche Wissen oder andere Zusammenhänge vielleicht fehlen und, und, und.

Und Manager, die jetzt das Ganze eher von der finanziellen Seite betrachten, haben noch mal wieder einen anderen Blickwinkel da drauf.

Und jeder denkt natürlich, seins ist das Wichtigste, was ja logisch ist, würde ich ja genauso denken.

Und das in den Ausgleich zu bringen und auch in eine Priorität zu bringen, mit der wir dann wirklich erfolgreich sind, weil hier ist ja nachher auch die schwierige Aufgabe von einer Product Ownerin wie von dir, Tanja, oder wenn du Portfolio Management machst, das in eine Balance zu bringen und dann trotzdem auch entscheidungsfähig zu sein.

Okay, wir fangen jetzt damit an, weil es aus bestimmten Gründen, dass so und so jetzt vielleicht sinnvoll ist.

Und das dann auch zu verkaufen, Erwartungsmanagement zu betreiben und Erfolg, entsteht ja tatsächlich im Auge des Betrachters.

Das Business Cases Vorabrechnen ist ja genauso wie einen großen Plan Vorab machen.

Kann passen, passt aber meistens nicht.

Genau, da haben wir, glaube ich, irgendwie dieses Thema, warum also Stakeholder Management ist, so ein bisschen geklärt.

Ihr habt ja auch ein bisschen eingegangen auf das Thema Risikomanagement.

Und ich wollte jetzt etwas aufnehmen, was auch wieder zu den Erfolgskriterien oder wichtigen Themen bei Projekten passt.

Und was der MD42Martin gerade eben bei Twitch angesprochen hat, nämlich diese Aussage, oft wird mehr Wert auf Effizienz statt auf Effektivität gelegt, auch ein Kostentreiber.

Das ist ja offensichtlich, tatsächlich ist das eben interessanterweise eines von den Themen, von denen wir auch reden, wie gesagt, dass das halt sozusagen für sowas wie PostAgil wichtig ist.

Möchtet ihr dazu was sagen?

Was ist denn überhaupt Effizienz und Effektivität?

Und warum sollte das eine wichtiger sein als das andere?

Ja.

Möchtest du, Tanja?

Tu an, Uwe.

Ach, danke.

Ja, also, ## Effizienz vs. Effektivität

Effizienz bezieht sich ja auf die Art und Weise, wie ich etwas mache.

Und die Effizienz…

Und ursprünglich, und das ist eben auch nochmal ganz wichtig von der Grundintention, zählt Agilität darauf ab, diesen Effekt zu maximieren, also das Ergebnis für den Kunden, hatte Tanja vorhin ungefähr formuliert.

Und da die Maximale, den maximalen Wert zu schaffen, das heißt, dass Kernprobleme gelöst werden, dass die Kunden ihre Prozesse möglichst schmerzfrei durchführen können mit der Software, bei Inhouse-Software ist es immer relativ schnell, aber auch bei Produkten, dass wir unsere Kunden, die wir primär adressieren, hier gut abholen und damit auch ein erfolgreiches Produkt haben.

Und das ist aber sehr, sehr schwierig zu messen und zum Teil auch erst sehr spät wirklich gut zu beurteilen.

Effizienz ist natürlich vom klassischen Projektmanagement her sehr einfach zu beurteilen.

Wie viel Zeit habe ich reingesteckt, was ist rausgekommen?

So klassiker ist ja, wie viele Lines of Code hast du pro Tag gemacht?

Und ja, das hat vielleicht irgendwo auch seinen Wert in der Aussage, aber doch sehr, sehr stark begrenzt.

Und genauso auch Velocity-Betrachtungen, die dann gerne hergenommen werden, auch um Teams gegeneinander abzulegen, sondern die sind aber viel schneller, die fassen fünf Punkte mehr, ohne aber zu hinterfragen, was sind eigentlich die Maßstäbe, die dort dahinter liegen oder wofür haben wir das Ganze eigentlich?

Und das ist aber so dieses typische betriebswirtschaftliche Management-Denken, wenn wir mehr so MBA-mäßig an die ganze Sache rangehen.

Aber da gibt es ein sehr schönes Buch, MBA is not Management, das schafft eine sehr, sehr schöne Unterscheidung, was es eigentlich ist.

Es kommt auf das Ergebnis an, was tatsächlich dabei rauskommt.

Und das gilt es zu maximieren.

Und das sind jetzt auch wieder gerade so Diskussionen, die rumkommen.

Ah ja, wie viel Zeit verbringe ich jetzt hier eigentlich wirklich?

Muss ich die Zeiten messen, die jemand arbeitet?

Ist das aussagekräftig oder muss ich nicht eigentlich gucken, was kam am Ende des Tages dabei raus?

Habe ich eine neue Prozedur geschaffen, die automatisiert getestet ist, das macht, was es ist, ist sie in den Bildprozess eingebaut, sodass ich am nächsten Tag sehen kann, wie das Ganze im kompletten Kontext funktioniert und passt oder eben nicht.

Und das ist das Einzige, was zählt, ob einer da jetzt drei Stunden angesessen hat oder zwei Stunden, ist tatsächlich dann sekundär.

Das Problem ist aber hier wiederum, glaube ich, und das ist auch mein letzter Satz dazu, das eine kann ich leicht messen und zwar sofort und das andere sehr, sehr schwierig, auch erst hinterher beziehungsweise währenddessen, aber mit deutlich mehr Aufwand und deutlich mehr Grauzone.

Und das schafft Unsicherheit.

Und das ist, wieder sind wir beim Stakeholder-Management als Manager und die Rolle kenne ich ja selber auch, so enorm viel mit Unsicherheiten zu tun.

Du bist von Menschen abhängig, von denen du einfach nicht mehr verstehst, was sie genau machen.

Und selbst mit dem Techie-Background konnte ich auch nicht mehr alles verstehen, was die Leute machen, die ich da geführt habe, erst recht nicht, wenn sie auch noch an meinem Standort waren.

Das gibt erstmal ein ganz schönes Unsicherheitsgefühl.

Da muss man umgehen, lernen, umgehen können und eben nicht dann verfallen in Muster, dann halt eben Effizienz in den Vordergrund zu stellen.

Ohne Ziel kann ich wahnsinnig schnell sein, aber ich renne halt immer nur die Runde im Stadion, bringt mich auch nicht wirklich weiter.

Ich nick gerade so viel, Uwe, weil sich da auch meine Meinung komplett deckt mit dem, was du gesagt hast.

Vielleicht noch einmal so eine kurze Beobachtung von meiner Seite aus.

Man sieht es auch bei manchen Teams ganz schön in einem Review nach einem Sprint.

Da gibt es Personen oder Teams, die zeigen, was sie in den letzten zwei Wochen getan haben, anstatt den Kundennutzen davon zu zeigen.

Und dabei beobachte ich das halt immer wieder.

Also unterm Strich geht es ja auch wirklich darum, die richtigen Dinge zu tun.

Und die richtigen Dinge sind halt die, die einen echten Nutzen, einen echten Mehrwert für das Produkt bieten und nicht halt, wie viel Zeit habe ich da rein investiert, wie viel Mühe hat das gekostet.

Genau.

Also MD42 hat was gesagt, was, glaube ich, ganz gut dazu passt.

Ich glaube, Effektivität war eigentlich das Versprechen von Agile.

Schnelles Feedback vom Kunden bekommen, ob die Richtung stimmt.

Das ist, glaube ich, zu dem, was ihr gesagt habt.

Und ich wollte nochmal, genau, wir können nochmal gucken, was sonst irgendwie sozusagen so aufgelaufen ist.

The Travelling IT Consultant of YouTube hat gesagt, ich bin im englischen Umfeld unterwegs.

Hier gibt es auch Phrasen wie Adopt Agile, Do Agile, also nicht adaptiere oder nimm Agile auf oder mache Agile.

Die fallen aus allen Wolken, wenn ich sage, Agile ist ein Adjective, you can only be Agile.

Also Agile ist ein Adjektiv und man kann irgendwie nur Agile sein.

Und zu dem Stakeholder Management hat der BSH Tour geschrieben, Stakeholder Management gleich RACI Matrix, also R-A-C-I.

Ja, RACI, ja.

Okay.

Ja, sorry.

Magst du es kurz erläutern?

Wenn du einmal eine gemacht hast.

Das ist eine Matrix, wo du versuchst, wer ist responsible, wer ist accountable, wer ist verantwortlich, wer muss informiert werden und so weiter.

Da gibt es noch ein paar mehr Buchstaben, die man ergänzen kann.

Das Spannende ist, das klingt erstmal total altbacken, kann aber wahnsinnig hilfreich sein, wenn man versucht, Stakeholder Management dort wirklich zu betreiben und zu gucken, okay, wem muss ich reporten, was muss ich machen, wem muss ich nur informieren.

Da sind wir wieder beim Thema, auch Meetings gestalten und so weiter.

Das wäre da der Punkt.

Okay, gut, danke für die Erklärung.

Also er schrieb halt Stakeholder Management gleich diese RACI Matrix plus psychologische Sicherheit, also dass man sich irgendwie wagt, etwas zu sagen und sich da sozusagen sicher fühlt.

Gutes Anforderungsmanagement und alle kennen und verwenden die korrekten Begriffe, eine Sprache und simple Priorisierung.

Dann läuft es halt.

Und dann schrieb halt irgendwie The Travelling IT Consultant, wie oft kriegt man das hin.

Das sollte die Projektvision sein.

Dann in ganz kleinen Schritten.

Wir hatten genauso mit psychologischer Sicherheit sind wir vielleicht in diesem Thema mit den Kommunikationstechniken.

Also das ist ja nochmal so etwas, was ein bisschen quirligt.

Also wie sage ich das, was eigentlich gesagt werden muss?

Das ist glaube ich auch noch etwas, was ihr da irgendwie wichtig findet.

Genau.

Also in den Workshops, ich fange ja mal ganz kurz an.

Kommunikationstechniken

Da geht es halt eben auch darum, über die Hintergründe von Kommunikation etwas mehr zu lernen.

Und das ganze Thema zum Beispiel auch der Arbeit mit Frage, Fragetechniken, ganz bestimmte Strukturen dort zu nutzen.

Empfängerorientierte Kommunikation

Genauso aber auch wirklich ein sehr stark empfängerorientierte Kommunikation zu werden, also beim Anderen zu sein.

Oder auch das Thema des Zuhörens wirklich verstehen wollen.

Und das ist auch ganz wichtig.

Verstehen, etwas verstehen zu wollen, heißt nicht damit einverstanden zu sein.

Das wird immer gerne vermischt und wir sind dann immer sofort gleich auf Zille.

Oder der Ebert jetzt wieder gerade das sagt, wo ich ganz anderer Meinung bin.

Nee, erst mal verstehen, was er denn wirklich meint.

Und dann hinterher sich das anzugucken und zu bewerten.

Das sind einfache kleine Bausteine, aber in der Summe macht das eine ganze Menge an Veränderung und Wirkung in unserer Kommunikation.

Und auch zum Beispiel zu gucken, was braucht jetzt mein Gegenüber?

Braucht er jetzt engen Kontakt?

Braucht er jetzt Erklärungen, Informationen?

Braucht er jetzt eine stelle Entscheidung?

Reden wir jetzt über etwas Optionen und Möglichkeiten?

Das sind auch so Punkte, wo wir dann unserem Gegenüber erst mal ganz gut in einen guten Kontakt kommen wollen.

Das ist eigentlich der Punkt, einen guten Kontakt kommen wollen, ihn da abholen, wo er ist und ihn dann ranbringen.

Also das typische Beispiel kennt jeder, der mal im Service gearbeitet hat.

Der empörte Benutzer ruft an und ist völlig auf Zille.

Und das Erste, was der völlig sachliche Supporter sagt, ist, haben Sie denn überprüft, ob Sie das Gerät eingeschaltet haben?

Die Reaktion ist dann typischerweise, dass der Anrufer noch mehr auf Zille ist.

Halten Sie mich für einen Idioten, selbst wenn er das Gerät nicht eingeschaltet hat.

Man muss immer erst mal ein bisschen mitleiden, verstehen, was das Ganze ist, nachvollziehen, warum das für ihn gerade so ein großes Problem ist.

Und dann kann man irgendwann seinen methodischen Fragebogen durchgehen, was jeder gute Supporter lernt, bevor er so etwas macht.

Um solche Themen geht es dort.

Ich komme nicht umhin, diese Geschichte zu erzählen von der Support-Hotline, wo dann irgendjemand auf die Idee gekommen ist, den Menschen, der angerufen hat, nach der Seriennummer des Geräts zu fragen.

Und zwar deswegen, weil die hinten in der Nähe des Netzteils untergebracht ist.

Und dadurch hat der Mensch, der angerufen hatte, klar geworden, dass das Ding einfach nicht mit dem Stromnetz verbunden war.

Und dann war der Call beendet, ohne dass man sagen musste, haben Sie mal nachgeguckt, ob das Ding mit Strom versorgt war.

Das ist auch gute Fragen stellen.

Wie ich schon sagte, können Sie mir Ihre Seriennummer nennen.

Genial, gutes Beispiel.

Diese Themen, Stakeholder-Management, Risikomanagement, Kommunikationstechniken und Effektivität, Effizienz, macht ihr einen Workshop, womit man das auf das Projekt runterbrechen kann?

Möchtet ihr dazu etwas sagen?

Oder wie funktioniert das?

Gerne.

Wir machen das in einem Ein-Tages-Workshop.

Da geht es uns darum, zum einen den Eindruck zu kriegen, was in dem Unternehmen gerade der Status quo ist oder in dem Team.

Und das gemeinsam mit den Teilnehmern zu bewerten und am Ende des Tages, also vielleicht erst mal zum grundsätzlichen Rahmen, dann auch mit Tipps und Anregungen die Leute aus dem Workshop zu schaffen.

Also wir haben da zum einen den Workshop, der heißt Gemeinsam wirksamen Kommunikations- und Stakeholder-Strategien für agile Teams.

Das heißt, da geht es um genau die Themen, die du gerade genannt hast, Eberhard.

Also beim Stakeholder-Management schauen wir uns an.

Was habt ihr denn überhaupt bisher getan?

Und was kann da verbessert werden?

Gleiches beim Risikomanagement, dass man sich das auch gemeinsam betrachtet.

Und dann zu schauen, wie können wir dahin kommen, das zu verbessern, an den Kommunikationstechniken so ein bisschen zu schrauben.

Und dann schauen wir auch immer noch darauf, wie können wir denn die Teams noch mehr optimieren?

Also wie können wir dann genau dieses Effektivität versus Effizienz, wie kommen wir denn zu einem hochwirksamen Team?

Also bewusst nicht hochproduktiven Team, sondern ein hochwirksames Team.

Das heißt, wie können wir schauen, was da für Hindernisse im Weg sind und wie können wir die beseitigen?

Und das ist sportlich in einem Tag.

Aber wir sind da völlig überzeugt, dass wir da auf jeden Fall schon einen Mehrwert schaffen können, was den Teams dann weiterhilft.

Also da muss man natürlich immer schauen, wo ist da gerade der Schmerz am größten und dann individuell darauf eingehen.

Und Uwe, willst du vielleicht was zu dem zweiten Workshop sagen?

Ja, gerne.

Da geht es wirklich dann um das Thema Effektivität.

Also da heißt PostAgilis Vorgehen, wie effektiv sind wir wirklich?

Ausgangspunkt ist eigentlich, dass wir einen Fragebogen abarbeiten.

Wir gucken uns ganz bestimmte Aspekte an, aber nicht, um jetzt irgendein Scoring oder so zu ermitteln, das geht mit dem Fragebogen gar nicht, sondern einfach, um sicherzustellen, dass wir über wichtige Punkte gesprochen haben und wir gucken uns an, okay, was macht ihr da denn eigentlich und wie wirksam ist das denn?

Funktioniert das?

Habt ihr die Effekte, die ihr euch davon versprecht?

Und gleichzeitig können wir anhand dessen auch nochmal genau reflektieren, was sind eigentlich die Ziele des Projekts?

Nochmal genau herausarbeiten, was ist denn da?

Häufig haben sich ja auch Dinge verändert, ohne dass es nochmal ganz klar herausgearbeitet wurde.

Und dann kann man auf jeden Fall auch nochmal gucken, was sind die Komplexitätsfaktoren, die wir hier haben?

Ich sagte ja schon, es geht um komplexe Projekte.

Die haben wir sehr häufig.

Das ist nicht der Punkt.

Ich stelle aber immer wieder fest, dass es häufig auch überkomplex ist, weil man zu viele Dinge parallel macht, die man besser vielleicht nacheinander machen sollte.

Und das gucken wir uns da zum Beispiel auch nochmal genauer an und versuchen anhand der Erkenntnisse, die wir daraus gewinnen, auch nochmal Fragen aufzubauen.

Wie können wir jetzt die Komplexität hier vielleicht reduzieren, indem wir Dinge anders machen, Dinge rauslassen, entsprechend dort handhaben?

Also Komplexität kannst du ja nicht handhaben oder nicht beherrschen.

Du kannst sie nur entweder reduzieren, indem du Parameter rausnimmst.

Das wären so Themen, die wir uns da angucken.

Und dann geht es halt darum, nochmal zu schauen, wie können wir das Team, da sind ja haufenweise helle Köpfe drin.

Da sind Männer, Frauen drin, die wirklich wissen, worum es geht, die jahrzehntelange Erfahrung haben und zusammengenommen auch viel, viel mehr Erfahrung, was eine einzelne Person überhaupt mitbringen kann.

Wie kann ich die auch noch mit einbinden, zumindestens soweit, dass ich es schaffe, dass sie selber reaktions- und aktionsfähig werden, Dinge auch noch selber zu steuern, selbst leicht zu übernehmen und daran auch Lernprozesse aufzubauen und dann zu erkennen, hier stellen wir fest, da läuft etwas aus dem Ruder, weil zum Beispiel bestimmte Tests immer wieder brechen und dann zumindestens die Frage aufwerfen, wie lösen wir das Problem?

Häufig kommen sie auch schon mit Vorschlägen dann.

Und dann gucken, was lernen wir daraus, wie gehen wir weiter vor oder was für Maßnahmen kann man ableiten?

Das wäre so grob umrissen.

Ich habe jetzt nochmal den Link zu den beiden Workshops zum einen in den Chat getan, zum anderen packe ich das nochmal in die Show Notes.

Und ihr steht ja auch gerne zur Verfügung, zu diesen virtualen Cafes, wo man sich einfach mal eine Stunde buchen kann und dann mit jemandem von euch sprechen kann.

Ich biete das auch an, aber ich bin für diese Sachen sicherlich nicht der richtige Ansprechpartner, wo man nochmal mit uns reden kann über irgendwelche Themen, die relevant sind.

Da ist, genau, der Jürgen hat sich gerade bedankt.

Ich weiß gar nicht, ob er sozusagen schon das Gefühl hat, dass die Frage beantwortet ist, die er gestellt hat.

Ich fand die irgendwie total spannend.

Also das ist diese Frage, wie soll Effektivität gegenüber Kosten im Management, das kostengetrieben geführt wird, vermittelt werden?

Also eine Antwort ist, glaube ich, sicherlich der Workshop und das, was da irgendwie ist.

Aber habt ihr noch andere Tipps oder andere Hinweise?

Das ist ja tatsächlich, finde ich, eine total fundamentale Frage.

Das ist ja genau diese Geschichte mit, ich kriege halt sehr easy raus, was das Team kostet.

Das ist irgendwie super trivial.

Ich kriege, wie ihr ja gesagt habt, erst im Nachhinein raus, was eigentlich der Effekt von dem ganzen Zeug war.

Und eigentlich muss ich das aber in erster Linie betrachten.

Also ich würde sagen, grundsätzlich einfach nochmal auf die ursprünglichen Ziele schauen.

Wozu ist dieses Projektprodukt ins Leben gerufen?

Man hat sich das ja sicherlich nicht irgendwie von Bäumen gepflückt, sondern das ist entstanden, weil man damit was erreichen wollte.

In der Regel ja natürlich ein Produkt zu produzieren, was auch Umsatz generiert oder mehr Umsatz generiert.

Das heißt auch, das, was bisher im Backlog ist, was erarbeitet wurde, das soll ja auf dieses Ziel einzahlen.

Also das heißt, da auch einfach ganz transparent sagen.

Und das hat auch wieder ein bisschen was mit Marketing und Show & Tell zu tun.

Auch einfach zu zeigen, was hat man erreicht, welchen Nutzen haben die Kundinnen damit.

Und dann unterm Strich halt, oder beziehungsweise vielleicht nochmal ein bisschen kurz zurückspulen, eigentlich auch schon bei den Anforderungen, die ja erfasst wird.

Vielleicht auch schon mal eine mentale Notiz machen.

Manche machen es ja auch wirklich so, dass sie den Wert davon schon erfassen.

Also wenn sie schon in etwa wissen, wenn ich dieses oder jenes Feature umgesetzt habe, dann kann ich dem Kunden ein Paket XY verkaufen, was mir monatlich voraussichtlich so und so viel, 1.000 Euro in die Kasse spielt.

Und auch danach einfach auch ein bisschen den Produkt Backlog aufzubauen und zu sagen, man versucht halt so schnell einen Wert zu schaffen, der dann auch wieder Geld in die Kasse reinspielt.

Also man baut ja nicht an einem Produkt einfach nur, weil man es gerne so hätte, sondern ja auch mit dem Ziel, Geld zu verdienen.

So ist es ja zumindest in der Regel.

Vielleicht müssen wir hier auch noch unterscheiden zwischen Produktentwicklung im klassischen Sinne oder einer Inhouse-Entwicklung.

Aber nichtsdestotrotz arbeiten wir immer gegen irgendwelche Budgets oder eine Rechnung, was uns das Ganze bringt.

Und da sollten wir gucken, dass wir das maximieren und Perfektion ist nicht erreicht, wenn wir alles reingepackt haben, was irgendwie geht.

Nee, da haben wir irgendeine Software, die wir auch nicht mehr im Griff haben, nicht mehr warten können, sondern die müssen wir schon flank halten dabei und das maximieren, dass wir damit den maximalen Kundennutzen ausüben.

Der Christoph Keimel hat bei YouTube noch eine Antwort auf die Urdruth gegeben und zwar schrieb er, hier also in Bezug auf Effektivität, hier helfen regelmäßige Priorisierungsworkshops mit den Stakeholdern, da hier der Business-Value der Maßnahmen in den Fokus rückt, im Nachhinein Data Analytics, wenn passende KPIs da sind.

Selten, aber ja.

Was selten?

Die passenden KPIs.

Aber wenn man die hat, klasse ja.

Was also bedeutet, und das war auch so ein bisschen das, was sich in meinem Gehirn gebildet hat als Wahrnehmung, dass nicht das Ziel ist, zu sagen, dieser Sprint hat uns 100.000 oder 200.000 Euro Wert generiert, sondern eigentlich eher, auch wenn man es nicht quantifizieren kann, das einfach in die Diskussion sehr stark darauf zu fokussieren.

Das hatte ich jetzt so ein bisschen das Gefühl, war so ein bisschen der Hinweis an der Stelle.

Genau, das ist das Minimum, was man erreichen muss.

Was kann der Kunde jetzt damit machen?

Was für einen Vorteil hat er dadurch?

Welche alten Prozesse sind dadurch abgelöst?

Welches Problem ist dadurch gelöst?

Wenn man das nicht beantworten kann, dann ist das vielleicht etwas, was man nicht machen muss.

Genau, exakt.

Dann haben wir es, glaube ich, soweit.

Wir sind so ein bisschen am Ende der Zeit.

Ich weiß nicht, ob es aus eurer Sicht noch Sachen sind, die wir diskutieren müssen, die wir vergessen haben zu erwähnen.

Dann soll es.

Vielen Dank.

Ich danke für die Zeit und ich möchte mich auch bedanken für die vielen Fragen und die intensive Diskussion.

Dann sehen wir uns nächste Woche wahrscheinlich wieder.

Wir sehen uns nächste Woche.

Ja, genau, wir sehen uns sowieso.

Ja, aber vielen Dank.

Ich muss auch sagen, die Fragen und Anmerkungen fand ich wirklich absolut hochklassig.

Ja, genau.

Das hat richtig Spaß gemacht.

Vielen Dank.

Danke dafür und schönes Wochenende und dann bis nächste Woche, würde ich sagen.

Tschüss.

Tschüss.