Die zwei Fehler beim Dokumentieren

Photo by Aaron Burden on Unsplash

Egal ob beim Dokumentieren von Design oder Architektur von Software, interner Prozesse oder, ganz Allgemein, beim Dokumentieren von Entscheidungen, meistens werden zwei gravierende Fehler gemacht:

1. Die Frage nach dem Adressaten der Dokumentation wird nicht gestellt
2. Es wird nur das Endergebnis festgehalten

Der erste Fehler führt potentiell dazu, dass die Dokumentation nie ernsthaft herangezogen wird: Für den Einen fehlen wichtige Details, der Andere vermisst die Einführung bzw. das Gesamtbild, für den Einen ist die Sprache zu technisch, dem Anderen nicht technisch genug, der Entwickler hat weiterhin noch viele offenen Fragen, als Endkundendokumentation taugt sie aber auch nicht. Im schlimmsten Fall ist es eine „Eierlegendewollmilchsau-Doku“, die irrsinnig viel Zeit erfordert hat, um sie zu erstellen, und die nun so fett ist, dass sie niemand ansehen möchte. In allen Fällen ist nutzlos Zeit investiert worden. Sehr gut erkennen kann man Fehler 1, wenn die Dokumentation mit den Worten „natürlich braucht man eine Doku, ist doch klar“ eingefordert wird.

Der Fehler Nummer zwei ist aus meiner Erfahrung oft völlig unentdeckt. Jeder denkt, dass das Festhalten des Endergebnisses das einzig relevante ist. Niemand stellt dies in Frage. In meinen Augen ist das aber komplett falsch: es ist viel wichtiger alle Ideen zu dokumentieren, die entstanden sind, und auch zu dokumentieren, warum welche Idee verworfen wurde. So kann zu einem späteren Zeitpunkt, wenn ein Problem wieder auf der Tagesordnung ist, einfach und schnell analysiert werden, ob eine vormals ersonnene und verworfene Lösung nun doch eine Chance bekommt. Z.B. weil einer der verhindernden Faktoren sich geändert hat. Weiterhin ist es für die Motivation und dadurch für die Umsetzung einer Lösung sehr hilfreich, wenn alle Mitarbeiter durch die Kommunikation der Details der Entscheidung mitgenommen werden.

Unbedingt neben der gewählten Lösung auch alle anderen Ideen festhalten; inklusive der Gründe dafür und der Gründe dagegen.

Better call Heisenberg!

Alex Holyoake, Unsplash

Walter White, alias Heisenberg, und James McGill, alias Saul Goodman, sind die Hauptcharaktere aus „Breaking Bad“ und deren Spin-Off Serie „Better Call Saul“. Kaum eine Serie hat mich so begeistert, wie diese beiden. Ihre enge Verwandtschaft zeigt sich nicht nur im Drehbuch sondern auch in der gesamten Aufmachung.

So wie sich in „Breaking Bad“ Walter White von einem durchschnittlichen Familienvater zum Drogenboss mit dem Namen „Heisenberg“ entwickelt, so verwandelt sich James McGill aus dem Schatten des übermächtigen Bruders und Anwaltes zu einem gerissenen juristischen Taktiker, der schließlich als Saul Goodman firmierend, juristischen Rat für Kriminelle aller Art erschwinglich macht.

In beiden Charakteren schlummern clevere Instinkte und Erfindungsreichtum. So erkennt Walter White in Jesse Pinkman bei dessen Flucht vor der DEA sofort den erpressbaren Drogendealer in ihm, der beim Vertrieb seines Produktes von unschätzbarem Wert sein würde. Durch seine wissenschaftlichen Wurzeln fällt es Walter leicht, Crystal Meth herzustellen und durch dessen Verkauf seine kostspielige Lungenkrebstherapie zu finanzieren. James McGill ist bereits als junger Erwachsener ein trickreicher Betrüger, der durch fingierte und arrangierte Zusammenstöße zwischen von ihm engagierten Skateboardfahrern und Autos, deren Nichts ahnenden Fahrern Geld als Entschädigung in Cash noch am Unfallort abschwätzt. Etwas gereifter, eifert er seinem Anwaltsbruder nach und absolviert unbemerkt von ihm ein Jura Fernstudium parallel zu seiner Arbeit in der Poststelle der Anwaltskanzlei seines Bruders.

Was beide Charaktere weiterhin eint, und was der Grund für die Einordnung dieses Posts in die Kategorie „Agile Minds“ darstellt, ist dieser unwiderstehliche Wille, das eigene Produkt zum Erfolg zu bringen. So wie Walter zu einem Zeitpunkt, als er längst genug Drogendollars verdient hat, einfach nicht davon lassen kann, sein „Crystal Meth Spezial in blau mit 99% Reinheit“ wieder herzustellen, da Nachahmer minderwertige Plagiate in Umlauf bringen, so ist Saul Goodman einfach nicht unterzukriegen und sich für nichts zu schade, um auch die 12 Monate zu überbrücken, in denen er seine Anwaltslizenz verloren hatte. Er entdeckt durch einen Dialog mit einem Hehler, dass Prepaid Handys als „Einmal-Telefone“ einen Markt für Kleinkriminelle bedienen und wirbt mit dem Slogan „Privacy Sold Here!“ unter dem Pseudonym „Better Call Saul!“ für seinen Verkauf besagter Billighandys aus dem Kofferraum seines schrottreifen Autos heraus.

Beiden ist gemein, dass sie sich nicht auf ihr Spezialgebiet zurückziehen und wie ein Zuschauer den Erfolg oder Misserfolg ihres Produktes abwarten: Sie greifen in jeder erdenklichen und notwendigen Form ein, um den Markt zu bedienen. Walter White unterstützt selbst den Vertrieb und scheut auch nicht die Drecksarbeit zu machen, wenn Jesse es nicht mehr alleine schafft. Dafür wird dann auch das Pseudonym „Heisenberg“ von ihm ins Leben gerufen und befriedigt nicht nur seine intellektuelle Eitelkeit, sondern dient auch der Geheimhaltung seiner eigentlichen Identität in einem naiven Versuch, sein Privatleben und insbesondere seine Familie, aus seinen Drogengeschäften herauszuhalten. James wiederrum, steht persönlich nachts auf einem ziemlich verlassenen Parkplatz eines Hot Dog Imbiss, um seine Handys an den Mann zu bringen, obwohl die Gegend gefährlich ist und zwiespältige Gesellschaft in dunklen Ecken potentiell nur darauf wartet, ihm seinen Gewinn zu rauben. In Jogginganzug und mit Goldkette ist der Anblick ein herrlicher Kontrast zu dem top angezogenen Rechtsanwalt, den er eigentlich darstellt.

Weder Heisenberg noch Saul Goodman, hätten einen solchen großen Erfolg gehabt, wenn sie sich nur auf das Kochen des Crystal Meth bzw. die Pflicht-Verteidigung zurückgezogen hätten. Ein stoisches Beharren auf den eigenen Spezialitäten, ist von Zeit zu Zeit nicht ausreichend. Es muss getan werden, was getan werden muss. Immer die eigene Vision vor Augen und den unwiderstehlichen Drang, sie zu realisieren. Bei Heisenberg geht es so weit, dass seine Frau, die für die Geldwäsche und die Aufbewahrung des angehäuften Drogengeldes verantwortlich ist, ihrem Mann in einem Aufbewahrungscontainer eine Palette mit gestapelten Dollarscheinen zeigt und fragt, wozu er noch weiter macht. Schon lange geht es nicht mehr um das Geld, sondern darum, dass beste Produkt am Markt zu haben.

Loslassen!

Loslassen! Ein neuer Aufguss des Themas „wie führe ich?“. Am besten beginnt man mit Loslassen und rückt davon nie wieder ab. Loslassen bei der Umsetzung einer Aufgabe. Die Aufgabe schlüssig von Angesicht zu Angesicht vermitteln, so dass die Intention allen Beteiligten glasklar wird. Dabei nicht über die Umsetzung reden oder zumindest nicht einmischen, wenn die Mitarbeiter in Details der Umsetzung einsteigen. Loslassen! In der Umsetzungsphase die Mitarbeiter unterstützen, coachen und ihnen als Mentor begegnen. Sie sind die Spezialisten, die die Probleme lösen sollen und können. Daher wurden sie eingestellt!

It doesn’t make sense to hire smart people and then tell them what to to. We hire smart people so they can tell us what to do.

Steve Jobs

Einer der wichtigsten Momente sich an diese Regel zu erinnern ist der Augenblick, in dem ein Mitarbeiter eine Frage stellt: Nicht inhaltlich auf die Frage reagieren, ist das erste Gebot. Es ist zunächst viel wichtiger zu ergründen, warum die Frage gestellt wird:

  • Betrifft die Frage Inhalte und wäre daher naheliegenderweise an einen Team-Kollegen zu stellen? Das Team sollte dies alleine für sich beantworten können.
  • Klingt die Frage so, als wollte der Mitarbeiter sich die Vorgehensweise oder das Ergebnis absegnen lassen? An Eigenverantwortung des Teams erinnern.
  • Ist es eine organisatorische Frage, die lediglich das Team betrifft? Das Team sollte zusammen selbst organisatorische Maßnahmen abstimmen.

Dies sind nur ein paar Beispiele oft wiederkehrender Fragen. Nicht antworten! Den Grund finden, warum die Frage gestellt wird, ist der entscheidende Punkt und die Aufgabe des Vorgesetzten. Die Gelegenheit nutzen und den Mitarbeiter durch Gegenfragen selbst zur Antwort führen. Dies macht den Mitarbeiter selbständiger und dadurch viel wertvoller: Er kann zukünftig eine gleichartige Frage alleine klären.

Dies gilt übrigens für alle Führungsebenen! Sofern ein Unternehmen mehrere Hierarchien hat, so ist diese Vorgehensweise nicht nur zwischen Teamleitern und deren Mitarbeitern anzuwenden sondern auch zwischen Abteilungsleitern und Teamleitern usw.

Fühlt sich dieses Loslassen am Anfang etwas mulmig an? Nach Kontrollverlust vielleicht? Klar! Das gehört am Anfang dazu. Da muss man durch. Als Faustregel gilt dies:

Wenn du dich nicht unwohl fühlst, wenn du Aufgaben delegiert hast und sie nicht kontrollierst, dann hast du noch nicht genug Kontrolle abgegeben!

Probieren geht über studieren

Me, myself and I

„Probieren geht über studieren“, das wussten schon unsere Großeltern. Recht kühn, naiv und eigentlich auch unreif, fand ich dieses Sprichwort immer. Es widersprach aber vor allem meiner sicheren Überzeugung, die ich als Teenager hatte, dass man immer einen Plan braucht. Natürlich sogar einen sehr guten Plan und nicht nur irgendeinen.
Woher hatte ich diese Überzeugung? Als Jugendlicher habe ich mir viele Bücher über die Pharaonen und das alte Ägypten reingezogen. Ebenso über die Schifffahrt bzw. vor allem eigentlich über Schiffswracks und wo sie gefunden wurden und wie sie gesucht wurden und was man aus ihnen über den Unglückshergang erfahren konnte. Das war irgendwie einfach spannend und ich kann nicht sagen, woher es genau kam, aber vermutlich einfach von meinen Eltern, die Ägypten bereist hatten und herrlich schaurige Geschichten über Mumien erzählt hatten. Außerdem waren sie gerne mit Kreuzfahrtschiffen unterwegs und so wusste ich mit 12 schon mehr über den Untergang der Titanic als über wirklich wichtige Dinge des Lebens.
Letztlich brachten mich die beiden Themen, so verschieden sie auch erscheinen mögen, immer insbesondere zum Thema PLANUNG. Die Pyramiden und wie der Bau organisiert gewesen sein musste und wie akribisch und detailliert die Titanic und ihre wasserdichten Kammern erdacht und umgesetzt worden waren. Faszinierend! Oder dass die Grabmäler im Tal des Todes so trickreich versteckt und geschützt worden waren oder das Schlachtschiff Bismarck trotz schwerer Treffer immer noch schwimmfähig war. Überall schien für mich eine gute Planung von super Ingenieuren dahinter zu stecken.
Letztlich ist der Untergang der Titanic und das, in Summe, klägliche Scheitern der wasserdichten Abteilungen, doch eigentlich genau das Argument, dass auch ein noch so guter Plan buchstäblich untergehen kann. Eine geradezu tolle Ironie, die mir früher irgendwie entgangen sein muss. Oder ich bin vielleicht sogar dem größten Denkfehler verfallen gewesen: Der Plan war eben nicht gut genug. Er hätte noch besser sein müssen!
Irgendwie auch sehr passend zu den Debatten in der Gesellschaft, damals in den 80er Jahren, als ich Teenager war, nämlich ob Atomkraft sicher sei. Klar, sehr sicher. Ganz sicher? Never ever! So ist das halt. Es gibt keinen perfekten Plan. Per Definition, fast schon, wenn man die lustige englische Redensart kennt, dass

„No plan survives contact with the enemy“

Und nun? Die agile Herangehensweise und Denke ist diese: Mache dir einen Plan, aber keinen sehr detaillierten, sondern gerade so genau, wie du denkst, dass es grob gehen müsste. Dann fange an, den Plan umzusetzen und bereite dich darauf vor, ihn anpassen oder gar ganz verwerfen zu müssen. Gehe dabei ganz bewusst schnell die risikobehafteten Aufgaben an, um schnell Klarheit zu bekommen, ob der Plan aufgehen könnte oder nicht. „Fail fast!“

Heute war ein toller Urlaubstag und die Idee für diesen Artikel kam mir, als meine Tochter in einer Bucht versuchte, langsam, über teils nasse Felsen, vorsichtig in das eiskalte Wasser eines Sees zu gelangen. Viele andere rutschten ab und lagen viel schneller als ihnen lieb war, im Wasser. Meine Tochter nicht. Sie hatte Flip-Flops an. Man sollte meinen, dass man auf schrägen Felsen leicht aus ihnen herausrutscht und daher auch schnell im Wasser liegt, aber wir dachten uns: Erstens ist es dann auch nicht schlechter als ohne Schuhe, zweitens rutscht man beim Abwärtsgehen nach vorne und damit in die Halterung der Flip-Flops, was also gerade gut ist, und drittens haben die eine gute Sohle, die nicht rutschen sollte. Was soll ich sagen: Probieren geht über studieren!

Mitarbeiter motivieren? Es gibt Wichtigeres!

Mitarbeiter motivieren ist eigentlich eine gute Sache. Motivierte Mitarbeiter sind in vielen Belangen den unmotivierten Kollegen Meilen voraus: Quantitativ und meist auch Qualitativ.

Wie verhält es sich nun aber mit den demotivierten Mitarbeitern: Lassen sie sich wieder motivieren? Und wenn nicht, wie viele motivierte Mitarbeiter brauche ich, um einen einzigen demotivierten Mitarbeiter zu „kompensieren“? Aus Erfahrung kann ich sagen, dass ein einziger demotivierter Mitarbeiter ein ganzes Team nach unten reißen kann. Gerne suchen sie Bestätigung in dem Sinne, dass sie andere auf die Gründe ihrer Demotivation aufmerksam machen und aufwiegeln, diese „Demotivatoren“ auch als solche wahrzunehmen und dann dadurch auch beginnen, demotivierend einzuwirken. Wenn es so weit gekommen ist, ist das Kind schon lange in den Brunnen gefallen und nötig, die demotivierten Teammitglieder aus dem Team zu entfernen. Dies ist das letzte Mittel in einer unerfreulichen Situation und um fast jeden Preis zu vermeiden.

Aus diesem Grund ist die oberste Priorität nicht das Motivieren von Mitarbeitern sondern vielmehr das Entstehen von Demotivation zu verhindern. Doch wodurch werden Mitarbeiter demotiviert? Oft sind es hausgemachte Abläufe und Umgangsformen, die leicht geändert werden können. Die folgenden Dinge sind mir als die häufigsten Faktoren über den Weg gelaufen: übertriebene Kontrollmaßnahmen, komplizierte und unnötig aufwendige Bürokratie, mangelnde Vermittlung von Intention anstehender Aufgaben und mangelnde Erteilung von Autorität für die Lösung einer Aufgabe.
Das Resultat ist immer, dass Mitarbeiter den Eindruck haben, dass ihnen kein Vertrauen entgegen gebracht wird, dass ihre Kompetenz und Rat nicht erkannt oder erwünscht ist und sie dadurch als ein kleines Rad in einer riesigen Maschine stur und dumpf ihre Arbeit klaglos verrichten sollen. Ihre Meinung und ihr Know-How erscheint unwichtig, uninteressant und wertlos.

Motiviert eure Mitarbeiter nicht, entfernt erst alle Demotivatoren!

Gut gemeint ist das Gegenteil von gut

Viele von euch werden sich bestimmt noch an eine Großmutter erinnern, die es immer gut gemeint hat: „Zieh‘ dir eine dickere Jacke an, es ist kalt! Du wirst dich sonst noch erkälten. Trink‘ noch etwas, du wirst noch austrocknen! Ich geb‘ dir mal noch etwas mehr von dem Braten, Fleisch ist wichtig für die Muskeln!“.
Ja, sie mag es gut gemeint haben, aber es hat vor allem genervt. Sie wusste immer alles besser, dachte sie. Es war besser, aber nur in ihren Augen.

Das Gegenteil von gut ist gut gemeint, hat mir mal jemand gesagt und diese banale Erkenntnis, dass gut gemeint tatsächlich sogar das glatte Gegenteil von gut ist, war mir in dieser Deutlichkeit vorher nicht klar geworden. Aber als ich diesen Satz hörte, fiel es mir wie Schuppen von den Augen: Ja, gut gemeint führt manchmal sogar zu Trotzreaktionen, die dann etwas tatsächlich Gutes sogar endgültig und vorsätzlich in Schlechtes verkehren können.
Was Großmütter, und vermutlich auch Großväter, und bestimmt auch Eltern, eigentlich erreichen möchten, ist doch, dass ihre Schützlinge gute, weil sinnvolle, Verhaltensmuster anwenden, weil sie von den Vorteilen überzeugt sind. Dies setzt natürlich voraus, die Vorteile zu kennen. Die Gründe, die Absicht, das Ziel muss man vermitteln, nicht die Umsetzung. Erkläre das warum und nicht das wie!

Euch ist bestimmt schon aufgefallen, dass dieser Blog Post inhaltlich eng verwandt ist mit diesem hier: „Der Ofen ist mittlerweile breit genug“. Der Grund dieses Thema nochmal aufzuwärmen ist, dass mir immer wieder auffällt, dass Führungspersonen in dieses Muster verfallen, auf die Schnelle zwischen Tür und Angel einem Mitarbeiter direkte Arbeitsanweisungen zu geben. „Auf die Schnelle“ ist dabei vermutlich der Hauptgrund für das Vorgesetztenverhalten: Eine ausführlichere Hinführung durch Darstellung des warums, ist in Hektik oft nicht möglich, da es aufwändiger ist.

Stattdessen ist es nötig, mit seinen Mitarbeitern im Dialog nachhaltig und regelmäßig die Ziele und Absichten und ggf. Kursänderungen zu besprechen. Herrschaftswissen und Zurückhalten von Information ist tödlich. Transparenz ist König! Missverständnisse werden vermieden. Die Mitarbeiter können am besten selbst entscheiden, wie sie das Ziel erreichen können. Sie sind die Spezialisten. Eine falsche Umsetzung aufgrund mangelnder Informationen ist dann fast ausgeschlossen.
Und ganz nebenbei fühlen sich die Mitarbeiter ernstgenommen und als kompetenter Spezialist anerkannt.

Nur ein einziges scharfes Messer

Photo by Manki Kim on Unsplash

Ein kurzer Ausflug in die Physik des frühen 20. Jahrhunderts: Man dachte, dass die Energie eines Lichtstrahls zur Lichtintensität proportional ist. Bestrahlt man eine Metallplatte mit Licht, so kann man die Lichtintensität aber erhöhen wie man will, man bekommt keine Elektronen aus dem Metall herausgelöst, sofern das Licht nicht mindestens eine bestimmte Frequenz hat. Einstein gelangte zu der Hypothese, dass:

Licht besteht aus Lichtquanten, auch „Photonen“ genannt. Trifft ein Photon auf eine Metalloberfläche auf, so gibt es seine gesamte Energie komplett an ein Metallelektron ab. Ist diese Energie ausreichend zur Überwindung der sog. Austrittsarbeit, so verläßt das Elektron die Metalloberfläche.

Es ist also nicht die Anzahl der Photonen entscheidend (was der Intensität entspricht), sondern, dass das eingestrahlte Photon ausreichend Energie hat.

An diesen Effekt musste ich neulich wieder denken, als es bei mir in der Firma etwas stressige Tage gab: Es hilft oft Null, immer mehr Personen auf ein Thema anzusetzen. Die Reibungsverluste werden höher, der Koordinationsaufwand steigt und die klare Priorisierung wird nur schwerer. Gerade bei komplizierten, oder gar komplexen Problemen, ist dies absolut kontraproduktiv. Ein kleines Team mit fähigen Experten kann solche Probleme lösen. Größere Teams mit weniger fähigen Fachleuten dagegen, hat keine Chance. Es helfen nicht viele Photonen mit kleiner Energie, es braucht eines mit dem richtigen Bums. Für manche Probleme braucht es nur ein einziges richtig scharfes Messer, das auch wirklich schneidet!

Seine Mitarbeiter zu solchen scharfen Messern zu machen ist daher eine deutlich wichtigere Maßnahmen, als das eigene Team durch weitere Zuwächse immer weiter aufzubauen. Je größer es wird, umso weniger Zeit bleibt meistens für das Coaching und die Weiterentwicklung jedes Einzelnen, obwohl genau dies doch so wichtig ist. Qualität statt Quantität!

Ganz gute Teams können Berge erklimmen, ein Mini-Team „scharfer Messer“ kann Berge versetzen.

 

The CORe Skills

Von den fünf Scrum Werten, stechen für mich immer wieder drei Werte heraus: Courage, Openness und Respect. Sie sind die tragenden Säulen, die gerade auch ein junges unerfahrenes Team die ersten wichtigen Schritten gemeinsam gehen lässt. Die „CORe Skills“, wie ich sie deshalb gerne nenne.

So oft habe ich erlebt, wie fehlender Mut wichtige Unterhaltungen verhindert. Scham, Unwissenheit offen einzugestehen, Angst die eigenen Fähigkeiten oder eben vermeintliche Defizite preiszugeben und Verunsicherung darüber, welche Wege in der Kommunikation im Unternehmen aufgrund von Hierarchien gewünscht und erlaubt sind, ersticken Gespräche zwischen Mitarbeitern, die so wichtige inhaltliche Klärung hätte bringen können.

Es ist seltsam und erhellend, wenn man neu zu einem Team stößt und an verschiedenen Arbeitspaketen bereits gearbeitet wird, die dann beim nächsten Sprint Planning, da sie nicht fertiggestellt wurden, fortgeführt werden müssen und schließlich ein beteiligter Entwickler offen eingesteht, dass ihm eigentlich nicht so recht klar ist, was das gewünschte Ergebnis sein soll. Ihm war eine offene Kommunikation fremd, aber er nahm meine Aufforderung dazu gerne an. So brach der Damm und andere fragten auf ähnliche Weise. Vorher waren sie verunsichert gewesen, wen und in welchem Rahmen, sie ihre Antworten bekommen sollten. Der bisherige Projekt Manager hatte natürlich darauf geachtet, dass alle genug Arbeit haben. Irgendeine, die irgendwie zum Projekt passt. „Resource Utilization“ und Micro-Management vom Feinsten. Leider ohne gemeinsam besprochene Inhalte, ohne klare Absprachen zwischen beteiligten Entwicklern und Testern, mit Meetings ohne klare Ziele, dafür aber mit einer ausgeprägten Reporting-Kultur.

Letztlich hatte jeder nur eine sehr grobe Vorstellung vom zu erreichenden Gesamtziel. Das ganze noch unter dem Deckmantel von Scrum. Allerdings völliger Cargo-Kult und ohne Kenntnis des Zweckes der verschiedenen Events, ohne Kenntnis der Aufgabenverteilung zwischen den Rollen und ohne ein Grundverständnis für empirische Prozesskontrolle. Zeit für einen erfahrenen Scrum Master!

Letzteres ist in besagtem Fall unfaires Bashing, denn alle Beteiligten hatten außer einem ca. 2-stündigem Frontalunterricht nicht viel über Scrum erfahren, sollten es aber nun anwenden. Wahnsinn ist das. Blanker Unsinn, um ehrlich zu sein. Die drei CORe Skills hätten hier allerdings auch bereits essentiell geholfen. Auch wenn zunächst überhaupt kein Scrum zum Einsatz gekommen wäre. Jede Firma sollte diese Werte zu ihrer Firmenkultur machen. Auch bei einem Wasserfall, V-Modell, Kanban oder welchem Schema auch immer, helfen die CORe Skills, schneller auf ein gemeinsames Ziel hinzuarbeiten. Dies ist einfach gesunder Menschenverstand. Bitte, einfach dort anfangen. Mitdenken und miteinander kommunizieren. Offen, respektvoll und mutig. Bitte!

Warum ich einen Blog schreibe

Photo by Aaron Burden on Unsplash

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”

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!

Der unerfahrene Scrum Master wird zur Sekretärin

Scrum Master mit Erfahrung gibt es nicht viele. Daher werden oft Mitarbeiter zu Scrum Mastern umgeschult, wenn Scrum eingeführt wird. Meist durch einen Coach, der das gesamte Unternehmen bei der Einführung berät. Dies kann gelingen, wenn der Coach dafür genug Zeit hat und es nicht nebenbei macht. Die noch schlechtere Alternative sind die Scrum Master Trainings: sie gehen oft nur ein oder zwei Tage und vermitteln zwar die Grundlagen, aber dies reicht einfach nicht aus, um ohne weitere Anleitung erfolgreich zu sein. Nach meiner Einschätzung liegt dies daran, dass man sich unter der Rolle Scrum Master nur sehr wenig vorstellen kann und Vergleiche zu bekannten Stellen, die es in der klassischen Softwareentwicklung gibt, nicht möglich sind. Wer sie gar als Projektmanager oder Teamleiter ansieht, hat sowieso nichts verstanden.

Typischerweise erhält ein neuer Scrum Master einen Appell, die Scrum Werte zu verinnerlichen und eine ausgedruckte Kopie des offiziellen Scrum Guide. Dies ist ein guter Anfang aber reicht einfach nicht!! Was genau ist denn bitte „Servant Leadership“? Was bedeutet dies im Arbeitsalltag? Wie soll man dem Product Owner helfen, sein Product Backlog effizient zu managen? Der weiß dies ja selber meist noch nicht, denn er oder sie ist ja gerade erst Product Owner geworden! Wie hilft man dem Entwicklungsteam, hochwertige Produkte zu erstellen?

Letztlich bleibt der Scrum Guide und viele Quellen im Internet nur im Ungefähren. Auf das Einhalten der Scrum Events zu achten und diese zu organisieren (das noch nicht so selbständige Team wird dies gerade zu Beginn der Umstellung auf Scrum noch nicht machen) und Impediments, also Hindernisse für das Team, beseitigen, sind die einzigen etwas klareren Aufgaben. Und deshalb stürzt sich ein unerfahrener Scrum Master natürlich darauf. Da weiß er wenigstens ziemlich genau, was es zu machen gilt. Und so hält sich der neue Scrum Master ganz schnell an den Aufgaben fest, die letztlich auch eine klassische Teamassistentin machen würde. Dieser Effekt verstärkt sich tendenziell so gar noch selbst: Bei der Einführung von Scrum in einem Unternehmen, sind die typischen Impediments Unterbrechungen durch Personen anderer Abteilungen, die in den Team Space kommen und Fragen haben. Der Scrum Master bittet dann höflich aber bestimmt dies zu unterlassen. Entsprechend sind diese Mitarbeiter verunsichert und wissen nicht, wie und wann sie mit dem Team kommunizieren dürfen. Klärt hier der Scrum Master nicht auf, wird es darauf hinauslaufen, dass er dann die Anfragen stattdessen per E-Mail bekommt und zwar mit der Bitte diese an das Team zum geeigneten Zeitpunkt weiterzuleiten. So wird der Scrum Master zum E-Mail Router. Das Entwicklungsteam denkt mit der Zeit dann deshalb auch noch irrigerweise, dass der Scrum Master der „Universal Organisator“ für das Team ist und es so laufen muss.

Mein Tipp für „frische“ Scrum Master: lernt so schnell wie möglich erfahrene Scrum Master kennen und tauscht euch mit ihnen aus! Begreift sehr genau, wie die Aufgabenteilung zwischen Product Owner und Entwicklungsteam aussehen soll und coacht sie genau in diesem Punkt. Je schneller die Refinement Meetings kollaborativ verlaufen, desto schneller fühlt sich das gesamte Team wohl und wird selbstsicherer in der Anwendung von Scrum. Dies verschafft Ruhe und damit Zeit, Zeit dich als Scrum Master weiterzuentwickeln!

Minimalismus in der Softwareentwicklung

Die neue „Minimalismus-Welle“, die The Minimalists ausgelöst haben, erfreut mich sehr. Unter dem Slogan „Simplify your life!“ ist mir dies bereits in den 90er Jahren untergekommen. Obwohl dieses Mindset, diese Idee, also nicht neu ist, ist sie es wert wieder und wieder erzählt zu werden: Weniger ist mehr und dies beginnt bereits bei den Dingen des alltäglichen Lebens, die wir uns anschaffen. Oder eben gerade nicht! Eindrucksvoll schildern The Minimalists bei ihren Auftritten, wie ihr Leben lebenswerter wurde durch die Dinge, die sie abgeschafft haben, durch die Dinge, die sie sich nicht gekauft haben, durch wenige ideell wertvolle Dinge, die als einziges in ihrem Zuhause bleiben durften.

Kurzum: Unser Leben ist zu “voll”. Viele Dinge, die wir uns anschaffen oder die wir tun, sind eigentlich unnötig. Unnötig weil wir sie entweder überhaupt nicht wirklich brauchen oder weil wir sie durch das Benutzen von einfachen anderen Dingen oder durch einfache andere Herangehensweisen auch erreichen können. Wer braucht schon die vielen speziellen Spezialküchengeräte: der „Super-Zerkleinerer“, den „So-gut-rührt-kein-anderer-Mixer“, die „Nur-so-kann-man-Rühreier-wirklich-rühren-Schüssel“ usw. Wie wäre es stattdessen mit einem Schneidebrett, einem Messer, einer Schüssel und einem Rührlöffel? Diese Werkzeuge sind universeller! Und brauchen insgesamt weniger Platz. Und das Beste, sie können auch noch für die Zubereitung von Gerichten benutzt werden, die noch gar nicht erfunden wurden! Wer braucht schon die halb-dicke Übergangsjacke? Oder die dreiviertel hohen halbgefütterten Spätherbsthalbwinterstiefel? Braucht jemand wirklich auch noch das dritte halbhohe Low-Board für die noch ungenutzten 80 cm freie Wand direkt neben der Tür? Was ist mit dem extra Ausdruck der Eintrittskarte für das Kino, der neben dem Screenshot der Reservierungsbestätigungs-E-Mail und der Reservierungsbestätigungs-E-Mail selbst und dem Ticket in der „Wallet“ App des iPhone mitgenommen wird? Das Fahrrad für den Weg zum Bahnhof, dazu noch das Touring Fahrrad und auch noch eines für echtes Downhill Fahren und natürlich noch ein „normales“ für sonst?

Ich wiederhole mich: Unser Leben ist zu „voll“. Unser Leben als Softwareentwickler auch!

Wie viele IDEs braucht der Mensch? Für jede Programmiersprache einen eigenen Editor? Für das Erstellen von UML Diagrammen ein anderes Tool als für Ablauf-Diagramme? Wirklich? Richtig gut ist nur der Handwerker, der seine Werkzeuge sehr gut beherrscht! Für einen Softwareentwickler gilt dies genauso. Bei 100 Tools, wird das schwierig. Bei ein paar Wenigen, ist es aber möglich. Meine Empfehlung ist also schlicht, sich auf wirklich wenige wichtige Tools zu konzentrieren und diese perfekt bedienen zu lernen. Es ist kein Zufall, dass viele Entwickler, die VI und EMACS als Editoren auserkoren haben, sehr sehr schnell kodieren. Meistens jedoch nicht, weil diese Editoren Fähigkeiten haben, die kein anderer hat, sondern weil sie meistens von Entwicklern benutzt werden, die sie seit Jahren benutzen und liebgewonnen haben. Sie kennen jeden Kniff und jede Abkürzung, jede Keyboard Shortcut und jede Eigenart. Dadurch können sie die Editoren optimal ausnutzen.

Genauso ist es bei allen Teildisziplinen der Softwareentwicklung bzgl. dem Tooling: Jenkins, Bamboo, svn, git, Maven, ant, nuget, NetBeans, IntelliJ, Eclipse usw.: Evaluieren, entscheiden, benutzen und dann weiter Erfahrung sammeln. Und dabeibleiben! Natürlich dies bitte nicht als Aufforderung zum Stillstand missverstehen: Von Zeit zu Zeit gibt es neue Werkzeuge, die ihren alten vergleichbaren Vorgängern überlegen sind. Und dann macht es Sinn, diese zu erlernen und zu benutzen. Aber bitte statt der alten Versionen und nicht dauerhaft parallel! Und, so ganz nebenbei, allzu oft kommen solche neuen „Wunder-Tools“ nun auch wieder nicht heraus.

Die besten Entwickler sind nicht die, die die neuste Version von Visual Studio verwenden, sondern meist die, die etwas von Test-Driven Development und Clean Code verstehen, die besten Projektmanager sind nicht die, die MS Projekt in der neuesten Version verwenden, sondern meist die, die wissen, ob bei ihrem Projekt besser PRINCE2 oder das V-Modell zum Einsatz kommen sollte. Und, in eigener Sache, wie wichtig ist mir wohl für einen Scrum Master oder Product Owner, Jira zu beherrschen?

Aus meiner Erfahrung entstehen die meisten Rufe nach neuen Tools aus der Hoffnung, dass das neue Tool Arbeit abnimmt und alles einfacher wird. Wirklich wahr ist dies oft nicht. In der Regel bleibt natürlich noch schwierige Arbeit übrig. Und diese zu machen, ist unser Job. Das ist unser Handwerk. Darin sind wir Meister. Froh und zufrieden sollten wir darüber sein und Arbeit abliefern, auf die wir stolz sein können.

Soweit bisher nur zu den Tools. Wie steht es mit „weniger ist mehr“ beim Sourcecode? Da sage ich zur Inspiration lediglich KISS, YAGNI und DRY! Mehr würde hier den Rahmen deutlich sprengen. ENDE. Weniger ist mehr!