Warum ich einen Blog schreibe

Natürlich ist es ein wichtiger Teil eines “Personal Branding”, als Coach eine eigene Webseite zu haben. Sicherlich hilft es ein wenig Aufmerksamkeit zu bekommen, die sonst nicht ganz so groß wäre. Damit dies gelingt, dürfen aber natürlich auch ein Auftritt bei XING und LinkedIn nicht fehlen. Je nach Markt, in dem man gebucht werden möchte, auch noch Instagram und Facebook. Je nach geographischer Region, in der der potentielle Auftraggeber lebt, eventuell auch Medium und Twitter. Die Liste ist lang.

Doch darum geht es hier nicht. Darum schreibe ich keinen Blog! Vielmehr würde ich ohnehin darüber schreiben, was mich bewegt, was mich inspiriert, was mich beeindruckt. Ich sammele meine Gedanken und sortiere sie. Es entsteht durch das Schreiben in meinem Gehirn eine sprichwörtliche Mind-Map, in der ich verschiedene Ideen miteinander verbinde. Wie Puzzle-Steine ein Bild formen, so wird aus losen ungeordneten Bruchstücken durch das Schreiben daraus eine geordnete Struktur, die ich mir viel leichter merken kann. Meistens finde ich dabei auch sehr prägnante Formulierungen, welche die für mich wichtigsten Punkte eines Themengebietes mit wenigen Sätzen beschreiben. Im Gespräch mit Kollegen bemerke ich oft, dass ich ihnen als konkreten Rat auf ihre Fragen, mit Formulierungen antworte, die ich mir bereits im Vorfeld für meine persönlichen Notizen zurechtgelegt habe. Sie staunen dann stets wie schnell ich ohne zu stammeln oder lange nach Worten suchen zu müssen, eine, wie sie es nennen, “druckreife” Antwort abliefere. Ich staune dann übrigens meist auch still und leise über mich und realisiere immer wieder, dass eben mein Aufschreiben meiner Gedanken, der Grund dafür ist. Schreiben sortiert meine Gedanken und Erinnerungen!

Wenn ich schließlich der Meinung bin, dass ich etwas besonders hilfreiches, geistreiches oder witziges geschrieben habe, dann landet es eben auch noch in meinem Blog, weil es mir Spaß macht Ideen mitzuteilen und Feedback dafür zu bekommen.

“Less is more” – auch bei Large-Scale Scrum

“Large-Scale Scrum”, kurz LeSS, ist ein möglicher Skalierungsansatz von Scrum. Dabei arbeiten bis zu acht Teams an einem einzigen Produkt. Entsprechend gibt es klarer Weise genau ein Product Backlog und genau einen Product Owner. Wie ist es aber um die Scrum Master bestellt bzw. sind die Teams ein reines “Development Team” oder ein komplettes “Scrum Team” inklusive Product Owner und Scrum Master?
Die Erfinder von LeSS sehen die Teams als Scrum Teams. Folglich gehört der eine Product Owner logisch zu den Teams und jedes Team sollte also auch im besten Fall einen eigenen Scrum Master haben. Die Empfehlung ist, dass ein Scrum Master durchaus bis zu drei Teams in LeSS betreuen kann, optimalerweise aber, wie gesagt, genau nur ein Team.

Angenommen, jedes Team hat tatsächlich seinen eigenen Scrum Master, so ist dieser, und tatsächlich nur dieser, in der jeweiligen Team Retrospective anwesend. Dieses Meeting gibt es in LeSS erwartungsgemäß auch und folgt auch den selben Regeln wie im klassischen Scrum, d.h. das Meeting ist nicht öffentlich und damit auch explizit nur für Mitglieder des jeweiligen Teams da. Das Meeting dient bekanntlich dem “inspect and adapt”, also dem kritischen Hinterfragen des Teams, was gut läuft und beibehalten werden sollte und was verbesserungswürdig ist und wie man es konkret verbessern kann. Entsprechend werden Maßnahmen eingeleitet. Kommt ein Team in LeSS dabei zu dem Punkt, dass es etwas ändern möchte, das nicht nur das Team alleine betrifft sondern auch Auswirkungen auf die anderen LeSS Teams hat, so kann es leider nicht selbst die Umsetzung angehen, sondern muss zunächst irgendwie die Fakten mit den anderen Teams besprechen. LeSS kennt dafür die “Overall Retrospective”. Wie der Name schon sagt, werden dort die Themen angegangen, die alle oder zumindest mehrere Teams betreffen. Genau hier sind wir an einer Achillesverse angelangt.

Zunächst ist als Nachteil schlicht die Verzögerung zu nennen, denn die Overall Retrospective kann natürlich erst nach den Team Retrospectives abgehalten werden. Sie einfach zwischen die Team Retrospectiven und das kommende Sprint Plannning zu quetschen, kann kontraproduktiv sein. Sie findet daher oft erst während des nächsten Sprints statt und entsprechend können Maßnahmen im schlimmsten Fall erst im übernächsten Sprint angegangen werden.
Noch schlimmer wird es, wenn andere Teams eine andere Wahrnehmung oder Meinung zu aufgebrachten Themen in der Overall Retrospective haben. Dann kommt es durch Diskussionen ggf. zu weiteren Verzögerungen oder Maßnahmen müssen so umgesetzt werden, dass es keine Auswirkungen auf andere Teams hat. Letztlich ist dies natürlich kein LeSS-spezifisches Problem sondern eine Konsequenz aus der Größe des Gesamtteams und der damit einhergehenden Gruppendynamik und Meinungsvielfalt, wie sie bei solchen großen Gruppen immer angetroffen werden kann. Dennoch kann dies dazu führen, dass die Overall Retrospectiven sich zu einer Frust-Veranstaltung entwickeln, wenn kein Konsens gefunden wird. Eine Konsequenz daraus kann leider sein, dass die Teams ihre Motivation verlieren, Themen aus den Team Retrospektiven überhaupt in der Overall Retrospective vorzustellen. Sie fangen an die Probleme nur für sich zu lösen und dies dann eben oft nicht optimal, denn es muss ja ggf. so umständlich gemacht werden, dass die anderen Teams davon nicht betroffen sind. Oder, falls dies nicht möglich ist, die Problemlösungen gar nicht mehr anzugehen. Der Scrum Master des jeweiligen Teams bekommt dies natürlich spätestens in der Team Retrospective mit und wird versuchen, dies nicht zu zulassen, aber was, wenn dies nicht gelingt? Entweder trägt er es alleine, also ohne Zustimmung des Teams, in der Overall Retrospective, was sein Team durchaus als Vertrauensbruch werten könnte, oder er muss anfangen, bei jedem dieser Themen irgendwie mit Hilfe der anderen Scrum Master die anderen Teams zur Diskussionsbereitschaft oder bestenfalls zum Einlenken zu bewegen. Dann würde er aber letztlich auch einen Vertrauensbruch begehen und außerdem ist dies sehr sehr aufwendig, manipulativ und letztlich schon politisch. Da sträubt sich jede agile Faser meines Körpers. Umständlich ist einfach das Gegenteil von agil. Es passt nicht. Natürlich ist all dies kein Problem, wenn die Teams transparent, offen und respektvoll miteinander umgehen. Davon wird schlicht ausgegangen denn schließlich sind es Scrum-Werte also auch Werte in LeSS. Dennoch gibt es diese Fälle in der Praxis und meine Meinung ist, dass es auf die folgende Art und Weise gelöst werden kann:

Nur ein einziger Scrum Master für alle LeSS Teams.

In dieser Variante, gibt es das Problem Vertrauensbruch so nicht. Der eine Scrum Master ist in allen Team Retrospectiven. Er muss sich nicht fragen, wie er ein Thema mit anderen Scrum Mastern bespricht. Er kennt es ja einfach. Auch gibt es so keine Indirektionen und damit einhergehende Probleme. Last, but not least, wird er schlicht aus organisatorischen Gründen die Team Retrospectiven nacheinander und nicht parallel abhalten können, wenn er an allen teilnehmen möchte. Dies hat natürlich einen zeitlichen Nachteil für die Teams, aber den ungeheuren Vorteil, dass dadurch auch der Product Owner zeitlich in der Lage ist an allen Team Retrospectiven teilzunehmen. Damit gibt es eine weitere Person, die quasi die Klammer über alle Teams darstellt und die Belange der Teams aus erster Hand hört. Er kann dann dazu beitragen, die Lösungen voranzubringen soweit dies möglich ist.
Ein Scrum Master für alle LeSS Teams hat auch psychologische Vorteile: Die Teams werden schneller zu noch mehr Selbständigkeit und Eigenverantwortlichkeit gebracht, denn sie wissen ja, dass ihr Scrum Master nicht nur für sie da ist. Auch wird ein einziger Scrum Master weniger ein Team Building im Sinne eines einzelnen LeSS Teams vorantreiben, sondern eher das Team Building des gesamten Produktteams im Auge haben. So entstehen erst gar keine Gräben und Abgrenzungen zwischen den Teams, wie sie sonst entstehen können, wenn die Teams sich ihren eigenen Namen geben, sich als eigenes Scrum Team fühlen, das seine eigene Dynamik und Gesetze hat, seine eigene Team Charta, seinen eigenen Raum und am Ende noch gar in einen Konkurrenzkampf zu den anderen Teams tritt. Dies belebt hier nämlich nicht das Geschäft, sondern behindert das gemeinsame Streiten für das eine gemeinsame Produkt. Gerade diese letzten Punkte sind markant, wenn ein unerfahrener LeSS-Coach die Teams gutgläubig nach klassischem Scrum ausbildet und aufstellt und die wenigen zusätzlichen LeSS-Events, wie eben z.B. die Overall Retrospective, einfach als weitere unabhängige Bausteine sieht. Obacht, Falle!

“Kompliziert” und “Komplex”

Komplizierte Maschine

Was bedeutet “kompliziert” und gibt es einen Unterschied zu “komplex”? Viele Menschen verwenden die beiden Ausdrücke synonym. „Kompliziert“ gleich „komplex“ gleich „nicht einfach“. Fertig.
Die Menschen sind einfache Arbeitsabläufe gewohnt. Sei es beim Anbau von Nutzpflanzen oder in der Tierzucht, sei es beim Zubereiten von Essen oder dem Bau von Behausungen für Mensch und Tier, sei es beim Fertigen von Waffen oder einfachen Werkzeugen. Stets sind eine Vielzahl von Arbeitsschritten nötig. Jeder ist einfach. Stets folgt einer auf den anderen. Manchmal ist eine einzige Person nötig, mal mehrere oder gar ein Team. Es sind einfache, wenn auch aus vielen Schritten und eine große Zeitspanne benötigende, Arbeitsabläufe.
Mit dem Beginn der Industrialisierung wurde die Verwendung von immer umfangreicheren Werkzeugen und Maschinen nötig. Ingenieuren und Technikern wurde klar, dass sie es mit einer neuen Art von Arbeitsabläufen zu tun haben: sie sind kompliziert geworden. Es gibt nicht mehr eine einfache Liste von Arbeitsschritten, die in einer wohldefinierten Reihenfolge nacheinander abgearbeitet werden müssen. Stattdessen kann die Reihenfolge variiert werden, manche Arbeitsschritte können oder müssen parallel abgearbeitet werden, die Umsetzung eines Arbeitsschrittes kann in seiner Art und Weise variieren und zwar abhängig von äußeren Randbedingungen oder dem Zustand des Ausgangsmaterials usw. Maschinen übernahmen einfache Arbeitsschritte, wobei der Vorteil darin bestand, eine höhere Geschwindigkeit als ein Mensch zu haben. Auch diese Maschinen waren kompliziert: im Inneren mussten viele mechanische Teil gut aufeinander abgestimmt und angepasst zusammenspielen. Schnell lernten die Konstrukteure solcher Maschinen, dass möglichst jedes Teil nur eine einzige einfache Aufgabe übernehmen sollte. Das Zusammenspiel vieler solcher Teile ergab dann erst die gesamte Maschine, die insgesamt einen komplizierten Vorgang abarbeitete. Der Leitsatz „Keep it simple, stupid!“, war geboren. Er stammt nicht aus der Softwareentwicklung, nur so am Rande erwähnt. Die Feststellung ist, dass jedes einzelne Teil einer Maschine oder eines Arbeitsablaufes, nur eine einfache Aufgabe haben soll. Losgelöst von anderen Teilen bzw. Arbeitsschritten kann dieser Parameter einzeln optimiert werden. Dies wurde zur Definition von „kompliziert“: wenn etwas aus vielen einfachen Schritten aufgebaut ist, die unabhängig voneinander sind und einzeln optimiert werden können. Man kann sich dies wie eine Kette aus vielen einzelnen Gliedern vorstellen. Jedes hängt genau an einem vorangehenden und einem folgenden Glied der Kette. Es hat eine einfache Funktion und ist unabhängig von den anderen Gliedern der Kette. Lediglich eben die zwei Nachbarn sind ggf. noch relevant.

Während des Fortschreitens der Industrialisierung und der wissenschaftlichen Entwicklung, wurde es immer schwieriger Maschinen und Arbeitsabläufe so einfach aufzubauen. Es war und ist nicht trivial, etwas in viele einfache Teilschritte zu zerlegen. Dennoch war und ist es weiter ein elementares Bemühen jedes Ingenieurs und Entwicklers. Man begann sich zu fragen, ob es generell immer möglich ist, solch eine einfache Zerlegung eines Problems zu finden. In der Mathematik hatte man bereits mit Differentialgleichungen Bekanntschaft gemacht und ohne erklären zu wollen, was dies im Detail ist, sei nur soviel erwähnt: es war nicht gelungen diese Gleichungen in völliger Allgemeinheit zu lösen. Die Abhängigkeiten zwischen verschiedenen Gliedern der Gleichungen liesen sich nicht auflösen. Unabhängige Parameter zur Beschreibung des Problems waren nicht in Sicht. Die Anwendung solcher Differentialgleichungen wurde aber immer wichtiger, denn man begegnete ihnen bei der Vorhersage des Wetters und auch im Flugzeugbau. In beiden Fällen hat man es mit Strömungen zu tun und solange sich diese linear verhalten und entsprechend ohne Differentialgleichungen modelliert werden können, war die alte Welt noch in Ordnung. Kamen Verwirbelungen ins Spiel, war es aus damit. Die Wissenschaftler entwickelten die Chaostheorie und beschäftigten sich mit der „fraktalen Geometrie der Natur“. Chaos und die Erkenntnis, dass ein „Flügelschlag eines Schmetterlings in China, bei uns einen Orkan auslösen kann“, waren das Ergebnis. Der Begriff „komplex“ wurde zur letzten Bastion zwischen der komplizierten, aber beherrschbaren, alten Welt und der neuen chaotischen Welt. Ein komplexes System besteht aus Einzelteilen, die sich mehr oder weniger alle gegenseitig beeinflussen können.

In der modernen Softwareentwicklung ist man zu der Erkenntnis gelangt, dass sich Produkt- und Projektentwicklung letztlich wie ein komplexes System verhält. Und nicht mehr wie ein kompliziertes System. Es sind sehr sehr viele Parameter wie Kundenwünsche, technische Randbedingungen, zeitliche Randbedingungen, monetäre Randbedingungen usw. im Spiel und die meisten dieser Parameter beeinflussen mehrere andere Parameter. Die modernen agilen Vorgehensweisen sind genau für diese Art von Problemen gemacht. Sie sind optimal für die Lösung eines komplexen Entwicklungsproblem geeignet … denn dafür wurden sie erschaffen!

Der Ofen ist mittlerweile breit genug

Eine kleine Anekdote kam mir unter, die sich um ein Kochrezept dreht: In einer Familie gab es ein altes Rezept für die Zubereitung eines Fisches. Es wurde von Generation zu Generation weitergegeben. Die jüngsten Sprösslinge sahen zu und halfen mit und erlernten es so ebenfalls. Ein Teil des Rezeptes war, dem Fisch den Kopf und den Schwanz zu entfernen. Niemand wusste, warum das so sein musste, aber es war stets als wichtiges Element der Rezeptur weitererzählt worden. Irgendwann forschte ein Familienmitglied nach und fand heraus, dass früher die Backöfen viel schmaler waren und deshalb der Fisch meist einfach nicht in den Ofen passte! Das war der einzige Grund.

Wenn wir etwas machen, sollten wir vor allem wissen, warum wir es so machen. Die Frage nach dem Grund ist legitim und nötig. Sie ist weder unangebracht noch respektlos.

Dies sah man früher beim Militär nicht so: Ein Befehl ist ein Befehl und darf nicht in Frage gestellt werden. Er muss sofort und bedingungslos ausgeführt werden. Warum war dies beim Militär so? Im 17. Jahrhundert begannen die ersten Staaten ein festes Heer, ein sogenanntes “stehendes Heer”, aufzubauen. Also eine Präsenzarmee, die nie aufgelöst wurde. Damit dies möglich war, wurde nicht groß ausgewählt, sondern man nahm jeden, den man bekommen konnte. Also insbesondere Personen, denen man im Allgemeinen nicht zutraute, selbst Entscheidungen zu treffen und die komplexen geordneten militärischen Abläufe zu verstehen. Es war die Zeit der sog. Linientaktik (auch Lineartaktik genannt), als die Männer der Infanterie in der Breite nebeneinander aufgestellt waren und möglichst schnell ihre Vorderlader nachladen mussten, um dann zeitgleich wieder feuern zu können. Marschieren im Gleichschritt gehörte ebenso dazu, wie das präzise Drehen oder Schwenken der verschiedenen Abteilungen von Fußsoldaten. Um all dies zu ermöglichen, waren ein enormer Drill und eine hohe Disziplin unabdingbar. Das geringste Anzweifeln von Befehlen wurde hart bestraft, um schlicht ein Aufbegehren gegen das harte Exerzieren schon im Keim zu ersticken. Ebenso eingedämmt wurde dadurch das Desertieren, das bis dahin leider häufig vorkam und die Existenz eines stehenden Heeres bedrohen konnte. Last, but not least, kann ein schnelles Befolgen von Befehlen in einem Gefecht, ohne Fragen zu stellen und ohne Zögern, lebensrettend sein.

Für das Militär war diese Herangehensweise also bestimmt sinnvoll. Doch selbst dort beginnt man, nicht mehr in Kategorien wie militärische Ordnung, Kommandokette und blindem Gehorsam zu denken. Gerade auch eine der schlagkräftigsten Armeen der Welt, die US Armee, sah sich spätestens seit ihrem Kampf gegen Al-Kaida und IS im Irak, zum Umdenken gezwungen. Siehe dazu das durchaus inspirierende Buch „Team of Teams: New Rules of Engagement for a Complex World“ von General Stanley McChrystal:

Speed and interdependence had rendered our environment in Iraq incompatible with the vertical and horizontal stratification that had maintained military order for centuries. The distance that carefully regulated information had to travel, and the wickets through which decisions had to pass, made even the most efficient manifestation of our system unacceptably slow. The chains of command that once guaranteed reliability, now constrained our pace; the departmental dividers and security clearances that had kept our data safe, now inhibited the exchanges we needed to fight an agile enemy; the competitive internal culture that used to keep us vigilant, now made us dysfunctional; the rules and limitations that once prevented accidents now prevented creativity.

Wenn die Organisation, die ursprünglich aus gutem Grund die Idee von Befehl und Gehorsam entwickelt und eingeführt hat, zu dem Schluss kommt, dass es komplexe Umgebungen gibt, und dort diese Vorgehensweise nicht funktioniert, wie können dann Unternehmen, blind und ohne nachzufragen, an solch überholten Mechanismen festhalten? Warum ist die Vorstellung, dass es einen Denker und Lenker gibt, der einem Rudel unselbständiger Untergebener ihr Handeln vorgibt, immer noch so populär? Worin liegen die vermeintlichen Vorteile, die alle zu kennen scheinen, die diese Herangehensweise hat?

Wie haben es die alten Preußenkönige nur geschafft, ihre Idee so nachhaltig in die Köpfe einzupflanzen, dass sie anscheinend unausrottbar ist? Als Scrum Master wüsste man dies schon gerne, um nun einen anderen Keim einzupflanzen … der Ofen ist mittlerweile schließlich breit genug!

Nichts macht agiler als eine Küchenrenovierung

Die Idee einer neuen Küche mündet ganz schnell in einer Sprengung eines kompletten Raumes. Zumindest fühlt es sich so an, wenn Spüle und Heizkörper ihre Positionen verändern sollen. Kaltwasser, Warmwasser, Wasserabfluss, Heizungsrohre, alles muss erstmal raus und dann neu verlegt werden. Schlitze hier, Schlitze dort. Die Bohrer dröhnen, der Hydraulikmeisel bringt jede Fliese zur Kapitulation. Manchmal leider auch zur totalen bedingungslosen Kapitulation der gesamten Wand, an der die Fliese hing. Was doll’s. Staub fressen muss jeder Mal und der Boden hinter der Wand, der nun Sprünge hat, sollte doch sowieso erneuert werden. Ach so, nicht jetzt sondern irgendwann mal. Ups. Egal. Weiter geht’s.

Ohnmacht. Ohnmacht. Eine Renovierung wird von so vielen Überraschungen und Unwägbarkeiten heimgesucht, da hilft kein detaillierter Plan. Da hilft ein guter “Grobplan”. Ein Refinement würde man in der agilen Welt sagen. Was soll denn insgesamt erreicht werden? Wo sollen die Spüle und die Spülmaschine hin? Wo der Herd? Wo müssen entsprechend welche Anschlüsse liegen? Welche müssen abgeändert werden? In welcher Reihenfolge müssen die verschiedenen Gewerke an die Arbeit gehen? Wo kommt eine Staubschutzwand hin? Wie lange wird das Wasser ungefähr abgestellt sein und wann? Sollen bei dieser Gelegenheit noch andere Wasserleitungen erneuert werden? Ende. Alles Weitere lässt sich kaum planen bzw. wird vermutlich aufgrund von “Ereignissen” sowieso wieder über den Haufen geworfen. Eine unerwartete Leitung hier, eine überraschend massive Wand dort. Werkzeuge müssen herangeholt werden, die eigentlich nicht eingeplant waren. Da muss sogar mal schnell noch ein Schlosser dazu gerufen werden, um ein Gitter zu entfernen, das eigentlich hätte hängenbleiben sollen. Kurze Absprachen, flexible Reaktionen, das Gesamtwerk im Blick!

Als “Product Owner” kann man sehr leicht die eigenverantwortlichen Handwerker anleiten, um den Kurs zu halten. Diese brauchen kein Nachmessen des ungeduldigen Hausherrn – eben jenem “Product Owner” -, sie brauchen Mindest- und Maximal-Maße, damit die Spüle auch da hin kann, wo sie hin soll. Sie brauchen keine Anleitung für das Anbringen einer Übergangsschraube zwischen zwei Materialien, sie brauchen die Information ob diese Stelle zukünftig für Erweiterungen zugänglich sein muss, oder nicht. Gleiches gilt in Richtung der Stakeholder: Ich kann dir, liebe Frau, nicht sagen, ob am Mittwoch gegen 12:00 Uhr die Arbeiten beendet sind oder erst gegen Abend. Was ich dir aber sagen kann ist, dass ab Donnerstag alles erledigt ist, das Dreck aufwirbeln kann. Insofern kann ab Donnerstag geputzt werden. Ob am Freitag bereits jemand kommt, um die Löcher neu zu verputzen, weiß ich nicht. Ich kann dir aber sagen, dass dem Einbau der neuen Küche am nächsten Dienstag nichts im Wege steht. Stand heute. Ich kann dir nicht genau sagen, ob das Kaltwasserrohr links oder rechts vom Warmwasserrohr verläuft. Ich kann dir nur sagen, dass die Spüle genau dort neben die Spülmaschine passen wird. Gerne zeige ich dir heute Abend auch den Baufortschritt vor Ort. Du wirst sehen, dass es genau in die geplante Richtung geht und dass die Arbeiten schon so weit sind, wie sie ungefähr auch sein sollten: Frischwasser geht bereits wieder und der alte Heizkörper ist schon weg.

Bevor ich es vergesse: Die Handlung und die handelnden Personen sind natürlich frei erfunden. Jede Ähnlichkeit mit toten oder lebenden Personen wäre rein zufällig.

“Agile Minds”

Zuletzt bekam ich viele interessierte Nachfragen, was es denn genau mit dem Logo, und den Buchstaben darin, auf sich hat.

Die Buchstabenfolge steht für “Agile Minds” bzw. “Agile Mindset”, das kann sich jeder aussuchen, und ist das klare Bekenntnis, dass Agilität kein Prozess ist und Scrum oder Agile nicht eine Art Projektmanagement ist, sondern es sich im Wesen vor allem um ein Mindset handelt. Die Grundsätze dieses Mindsets sind der Leitfaden und gewissermaßen das Fundament, auf dem jede Implementierung einer agilen Vorgehensweise fußen sollte. Wenn ihr diesem Link folgt, oder einfach sogar alle meine Einträge der Kategorie “Agile Minds” lest, werdet ihr verstehen, worum es mir geht.

Update 2019:

Mittlerweile bevorzuge ich das folgende Logo, da es skizziert, worauf es am meisten ankommt: Miteinander reden und dabei visualisieren, worum es geht. So geht Wissensweitergabe!

„Dr. Agile“ oder was?

„Agil bis der Arzt kommt“, „Die Götter in Weiß“, „Was macht der Scrum Master, wenn er kein Meeting hat“, „Das Management ist nicht agil“, usw. Dies sind nur ein paar der Phrasen, die man wieder und wieder hört. Manche sind aus der Medizin, manche hört man bei jedem Treffen agiler Experten. Doch was haben sie gemeinsam und welche sind gegensätzlich? Geht es mir um zu viel Agilität? Oder um zu wenig? Ist es ein Hoch auf die „Scrummasterei“ und ein Hohn auf die altmodischen Führungseliten? Oder gerade das Gegenteil. Die Antwort ist: Es geht mir um Extrempositionen, mangelnde Empathie und Selbstgerechtigkeit. Sie sind mir zuwider. Und so wie sich manche Mediziner als die “Götter in Weiß” darstellen, so machen dies auch analog einige meiner agilen Kollegen: “Agile Götter”.

Auslöser für diese Gedanken war ein Scrum Event der Scrum User Group Karlsruhe, bei der ich mich als Scrum Master tummelte und mir einige Kommentare von agilen Kollegen mal wieder sehr befremdlich vorkamen: Selbstgerecht und allwissend inszenierten sich hier sog. Agile Experten. Sie verhöhnten die vermeintlich Unwissenden, die Scrum Master scheinbar nicht wertschätzen, nur weil sie eben jene im Arbeitsalltag nach ihren Aufgaben und Aktivitäten gefragt hatten. Als die „Agilen Götter in Weiß“ stellten sie sich gegenseitig lobend dar, die den Dummen und Unwissenden einfach mal nur die nötige Dosis Agilität injizieren müssten, um die Krankheit zu heilen. Was für eine Arroganz!

Auf der anderen Seite oft auch die leider nicht viel weniger arroganten Führungskräfte, die denken, dass Agilität so ein „Entwicklerdings“ sei und sie nichts angeht. Gerne auch abfällig als Kindergartenpädagogik vermeintlich herabklassifiziert. Doch gerade daran zeigt sich der Denkfehler der selbsternannten agilen Ärzte: Ist es nicht gerade unsere Aufgabe als Scrum Master oder Agile Coach diese Führungskräfte zu informieren und zu coachen und sie als Führungskräfte 3.0 von den Vorteilen der Agilität zu überzeugen? Ja, natürlich, ist die Antwort auf die eigentlich rhetorischen Fragen. Wer, wenn nicht wir, weiß, dass Agil zu sein ein Mindset, eine Einstellung ist. Wer, wenn nicht wir, weiß, dass Agilität nur der Weg, aber nicht das Ziel ist. Natürlich müssen wir undogmatisch gerade die „Führungsetage“ mit ins Boot holen. Wir müssen sie von den Vorteilen überzeugen, die ein Wirken als Unterstützer, Mentor und Coach mit sich bringt und wie überlegen diese Herangehensweise im Vergleich zu dem althergebrachten Verhalten ist, als Entscheider, Arbeitszuweiser und Kontrolleur zu agieren. Dazu hier und hier ein paar anregende Gedanken und Inspirationen.

Die Transformation hin zu einem agilen Unternehmen, ist ein langer, steiniger Weg, der gerade eben mit agilen Werten wie Respekt und Offenheit gegangen werden muss. Es gibt hier kein Platz für Arroganz und Dogmatismus. Vielmehr ist Empathie, Pragmatismus und Weitsicht gefragt. Gepaart mit der oft vergessenen Rittertugend der Milde und dazu noch viel Geduld. Bei Pragmatismus meine ich natürlich auf keinen Fall die Abkehr oder Aufweichung von agilen Ritualen und Werten, sondern Pragmatismus in der Umsetzung eben jener. Und genau an dieser Stelle befindet sich ein Scrum Master in seiner Reifung, wenn er sich fragt, wie denn ein Servant Leader für sein Team aussieht und was damit gemeint ist, als Facilitator sein Team und die Organisation weiterzuentwickeln. Genau an dieser Stelle trennt sich die Spreu vom Weizen: Auf der einen Seite die Herunterbeter des auswendig gelernten Vokabulars auf dem Weg zum Mediziner und auf der anderen Seite die, die kapiert haben, dass es das alleine nicht sein kann. Habt ein „Agile Mind“, aber seid kein Priester. Macht euch auf den Weg und lernt weiter.

Agilität ist nur der Weg, nicht das Ziel

Agil zu sein, ist eine Einstellung, ein Mindset. Es geht nicht um Demokratie oder Mehrheitsentscheidungen. Es geht um Werte wie Mut, Respekt, Focus, Offenheit und Selbstverpflichtung. Es geht um eigenverantwortliche Produktentwicklungsteams. Es geht darum die Dinge zu bauen, die wirklich gebraucht und gewünscht werden.

Agilität ist der Weg. Kundenzufriedenheit, Kundenbindung und letztlich Einnahmen, sind das Ziel! Wer agil ist, denkt und handelt kundenorientiert und unternehmerisch.

“agil” kommt von lateinisch “agilis”

Das lateinische “agilis” leitet sich von “agere” ab. Dies ist ein Verb und steht für bewegen, treiben, tun, machen, ausführen, handeln, hervorbringen, hinarbeiten. Genau, es geht darum zu handeln. Just do it!

Nicht ewig zaudern: “Soll ich, sollte ich nicht, was könnte alles schief gehen”. Mach’ es einfach und schaue dir das Ergebnis an! Wenn es nicht gut war, ändere dein Handeln. Aber handel! Jetzt! Frage dich nicht, ob du es darfst, sondern ergreife Eigeninitiative!

Für viele bedeutet agil zu sein, flexibel zu sein. Natürlich ist man dies bei agilen Methoden auch und das ist auch explizit gewünscht. Allerdings ist dies eine Konsequenz aus der empirischen Prozess Kontrolle, die agilen Methoden zu Grunde liegt und diese beginnt nun mal damit, etwas zu probieren und das Scheitern bewusst in Kauf zu nehmen. Frühe Kontrolle bedeutet frühe Erkenntnis, ob ein Scheitern vorliegt oder nicht. Fail fast! Unmittelbare Anpassung im Fall des Misserfolgs führt schnell zu einer Korrektur.

Warte nicht, fang’ an. Du bestimmst den Fahrplan!

“Tatort Technik”: Der Klempner von heute

Auch in der digitalen Welt greifen Analogien. Ob das umgekehrt auch so ist? Keine Zeit für solche Wortspiele. Zurück zum verstopften Abfluss. Dem Datenabfluss natürlich. Der Zufluss scheint übrigens ebenso gestört bei der Dame. Und schon bin ich mal wieder mitten in dem, was einen modernen Porno ausmachen könnte: Wie der sprichwörtliche Klempner komme ich vorbei, um kurz mal die Rohre zu verlegen oder durchzuspülen. Allerdings nur in meiner Phantasie. Schließlich gehe ich keinen Fremden zur Hand sondern nur Freunden und guten Bekannten. Und auch nur im totalen Notfall. Aber dieser Zustand der totalen unterwürfigen Hilfsbedürftigkeit ist ja schnell erreicht. Eigentlich ja, „blöde unnötige Technik“, aber in Wirklichkeit vielmehr „hoffentlich immer einfach so funktionierende lebensnotwendige Technik“. So sieht´s aus. Das haben diese Obsthersteller aus Kalifornien echt kapiert: Alles muss schön leicht zu bedienen sein. Das einzige Obst, das ich mag. Also ich mag auch noch anderes „Technik Obst“, aber sonst keins. Obst schmeckt meist schlecht und gesund kann das auch gar nicht sein. Viel zu viel Natur und so. Return from Interrupt:

„Was geht denn nicht?“, seufze ich.

„Ich kann Nachrichten empfangen, aber es gehen keine mehr raus.“

Das klingt ja spannend. Endlich mal ein echtes kniffeliges Problem. Das wär ja mal was! Rein aber nicht raus. Lustig, lustig.

„Welches Programm benutzt du denn für E-Mails?“

„Outlook natürlich.“

Natürlich. Was sonst. Es gibt ja praktisch gar keine anderen E-Mail Programme auf der Welt. Wie konnte ich nur fragen.

„Und da sind Mails im Posteingang aber im Postausgang auch?“

„Ja genau und beim Beenden von Outlook bekomme ich auch eine Fehlermeldung samt Frage, ob ich wirklich beenden will, wo doch noch 2 Nachrichten nicht gesendet seien.“

Hmmm, gut informiert die Gute. Sieht ja nach einem echten Fehler aus. Das gibt es ja eigentlich gar nicht. Kurze Kontrolle. Tatsächlich! Die Fehlerbeschreibung war absolut präzise UND korrekt. Was es nicht alles gibt. Ich beglückwünsche mein Gegenüber. Für einen Fehler wurde die wohl noch nie umarmt. So, nun aber rein in den Spaß. Account Einstellungen: Alles prima. Testnachricht senden. Klappt auch!?!? Nochmal, das kann nicht sein. Testnachricht senden. Klappt wieder. Da sind die nun zwei Nachrichten im Eingang. Eine andere neue Mail schnell mal manuell getippt. Senden ….. hängt. Fehler! What the f**k?!?!

„Hast du in letzter Zeit irgendetwas geändert“?

„Ich habe auf Windows 10 gewechselt; als Upgrade der bestehenden Installation“.

Schon wieder so präzise die Kleine. Ist scheinbar ein echter Nerd. Respekt! Ich bin ratlos. Ja, ehrlich, ich geb´s zu! Da muss Freund Google ran: „Windows 10 outlook receive send problem“ tippe ich ein. Und voila, gleich der erste Treffer: „After upgrading to Windows 10, I am unable to send messages in Outlook“. Den nehme ich und da steht die Lösung: Das Upgrade auf Windows 10 zerstört eine Komponente von Outlook, die man einfach nochmal neu installieren muss. Gelesen, gemacht, alles wieder gut. Ein erstauntes Gegenüber: „Du benutzt Google um Problemlösungen zu finden“? Klar, nur zum Shoppen gehen ist es nicht erfunden worden. So weit ist es gekommen. Für echte Fragen benutzt niemand mehr eine Suchmaschine. Zumindest von den normalen Leuten.

Nun gibt es die verdiente Belohnung. Nein, nein, nicht was ihr denkt. Auf gar keinen Fall, nein, sondern geilen schnellen Sex.

Spaß! Genauer gesagt, Erotik des Alters, lecker Essen. Mahlzeit!