Wenn es sich leicht anfühlt, machst du etwas falsch!

Das Agile Manifest [1] ist jetzt über 20 Jahre alt. Da sollte man doch denken, dass alle Missverständnisse mittlerweile geklärt und diskutiert sind. Doch weit gefehlt. Wertebasierte Management-Frameworks wie Scrum zum Leben zu erwecken ist und bleibt eine anspruchsvolle Aufgabe, bei deren Umsetzung es keinen einfachen Weg gibt, dem nur zu folgen wäre.Bei meiner Arbeit als Führungskraft mit einem Fokus auf das Lernen in Organisationen nehme ich ein bewusstes werte­basiertes Arbeiten und Handeln als immer wichtiger und wertvoller wahr. Ich denke, es fällt jeder Person besonders dann auf, wenn ein Handeln gewünscht ist, das mit den eigenen Werten im Widerspruch steht. Aber so scharf lässt sich das leider nur in extremen Situationen erkennen. Meist befinden wir uns doch eher in verschiedenen Grauzonen ­ohne ein klares und einfaches Schwarz-Weiß-Muster.Liefert etwa ein Mitarbeiter eher schwache Ergebnisse, dann verspüre ich wie viele Manager den Drang, diese Person stärker zu kontrollieren. „Vertrauen ist gut, Kontrolle ist besser“ ist ein Leitspruch, den wohl jeder kennt. Meine Erfahrung sagt mir aber auch, dass das eher nicht zu einer stabilen Verbesserung führt. Doch was mache ich ­stattdessen?

Werte als Paare betrachten

Bevor ich diese Frage beantworte, möchte ich einen Schritt zurücktreten und einen genaueren Blick auf die Art der Formulierungen im Agilen Manifest werfen. Die Autoren haben dabei eine interessante Form gewählt: das Wertepaar. So heißt es dort zum Beispiel: „Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: Individuen und Interaktionen mehr als Prozesse und Werkzeuge [...] Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein“ [1].Bei einem Wertepaar geht es also nicht um ein Entweder-oder, sondern um ein Sowohl-als-auch. Beide Werte sind konstruktiv und werden nebeneinander gelebt. Es gibt jedoch eine Gewichtung, die den Grad der Agilität ausmacht. Der jeweils erstgenannte Wert ist für Agilität wichtiger als der zweitgenannte. Man könnte auch sagen, der zweitgenannte Wert wird so umgesetzt, dass er den erstgenannten fördert und unterstützt. Für das obige Beispiel lautet die Frage damit: Mit welchen möglichst schlanken Prozessen und einfachen Werkzeugen kann ich die Interaktion und die einzelnen Personen stärken und unterstützen?Warum sind Wertepaare so bedeutsam? Ein einzelner Wert liefert nur wenig Orientierung. Erst im Zusammenspiel mit einem zweiten, konstruktiven Wert können wir praktische Handlungsoptionen ableiten. Der bekannte Kommunikationspsychologe Friedemann Schulz von Thun beschreibt die zugrunde liegende These folgendermaßen: Jeder positive Wert kann nur dann seine konstruktive Wirkung entfalten, wenn er sich in einer Spannung zu einem anderen positiven Wert, dem Gegenwert, befindet [2]. Wert und Gegenwert schaffen eine Balance, ohne die ein Wert in seine entwertende Übertreibung entarten würde [3].

Werte im Quadrat

Nehmen wir die entwertenden Übertreibungen von Wert und Gegenwert mit in das Wertepaar auf, so erhalten wir ein Werte­quadrat. Damit kann ich mir die abstrakten Zusammenhänge zwischen einzelnen Werten besser bewusst machen und habe einen Ausgangspunkt, um konkrete Lösungen zu entwickeln. Wie kann das für das Eingangsbeispiel Vertrauen versus Kontrolle aussehen?Vertrauen und Kontrolle stehen in einem positiven Spannungsverhältnis. Die entwertende Übertreibung von Vertrauen wäre ein Laissez-faire-Führungsstil, also der völlige Verzicht auf Regularien, Grenzen oder Vorgaben. Der entwertenden Übertreibung der Kontrolle entspricht das Mikromanagement, vergleiche Bild 1 [4].

Mit Kontrolle ist die Überwachung eines Sachverhalts oder einer Handlung gemeint. Wie kann uns das beim Thema Vertrauen helfen? Wenn die Informationen aus einem Überwachungsprozess den Personen, die den überwachten Prozess durchführen, direkt, sofort und transparent zur Verfügung stehen, so können sie den eigenen Prozess selbst kontrollieren. Ein Mitarbeiter oder ein Team erreichen so den Prozessreifegrad der Selbststeuerung. Selbststeuerung wiederum ist eine notwendige und wertvolle Etappe auf dem Weg zu selbst organisierten Teams.Wir benötigen zur Selbststeuerung aktuelle Informationen aus dem laufenden Entwicklungsprozess, anhand derer jedes Teammitglied selbst erkennen kann, ob alles im Lot ist oder ob Probleme aufgetaucht sind. Die Ergebnisse aus den permanent laufenden Unit-Tests oder die Statuszustände aus einer automatisierten Continuous Integration/Continuous Delivery sind Beispiele dafür. So kann ein Team seine Verantwortung für seine Entwicklungsarbeit wahrnehmen.Das klappt selten von alleine, und hier kommt dann der ­Scrum Master oder Agile Coach zum Einsatz, um mit dem Team an der Selbststeuerung zu arbeiten. Der Ausgangspunkt dafür liegt jedoch in den Werten, ihrer Umsetzung in die alltägliche Praxis und den weiterführenden Fragen, die wir uns stellen und im Sinne der Werte beantworten.

Die richtigen Fragen stellen

Wie können Fragen aussehen, mit denen ein Scrum Master oder Coach die einzelnen Mitglieder einer Gruppe im Sinne einer Selbststeuerung weiterentwickeln kann und so eine noch stärker auf Vertrauen basierende Führung ermöglicht? Anregende Fragen könnten zum Beispiel folgendermaßen lauten:

• Woran erkennst du, dass du mit der Bearbeitung deiner Aufgabe im Plan bist?
• Was machst du, wenn du erkennst, dass du nicht mehr im Plan bist?
• Wie erkennst du frühzeitig, dass dir Informationen fehlen?
• Wie erkennst du, was die wertvollste oder wichtigste Aufgabe ist, die du als Nächstes anpacken solltest?
• Wer sind die Personen, von denen du zu Beginn einer Aufgabe weißt, dass sie dir bei Problemen helfen können?
• Welche Hilfsmittel können dir bei der Problemlösung helfen?
• Oder als allgemeiner Einstieg: Was brauchst du, um deine Aufgaben besser bearbeiten zu können?

Führung ist keine Einbahnstraße. Deshalb arbeitet ein Scrum Master oder Coach ebenso wie mit den Teammitgliedern auch mit den verantwortlichen Führungskräften. Auch hier bilden Fragen das zentrale Element der Informationsbeschaffung, wie zum Beispiel:

• Woran erkennst du, dass dein Team an den richtigen Aufgaben arbeitet?
• Wie kannst du den Projektfortschritt ermitteln?
• Wie bemerkst du, dass es Probleme bei der Aufgabenbearbeitung gibt?
• Oder als allgemeiner Einstieg: Was gibt dir ausreichende Sicherheit, dass alles im Plan läuft?

Aus den Antworten können Prinzipien, Regeln und Praktiken abgeleitet werden, mit denen die Gruppe ein hohes Maß an Selbststeuerung erreicht und die Führungskräfte ausreichend Sicherheit haben, dass alles in den richtigen Bahnen läuft.

Das Kernthema finden

So weit, so gut … Haben wir mit diesen konkreten Fragen und deren Antworten eine Basis, um unsere Aufgabenstellung zu erfüllen? Auf den ersten Blick sicherlich. Woran kann ein Coach oder Scrum Master erkennen, dass die Gruppe wirklich einen hohen Grad an Selbststeuerung erreicht hat? Meist lässt sich das daraus ableiten, dass die eingeführten Prozesse „von alleine“ durch die Gruppe selbst am Leben gehalten werden und eigenständig zum Beispiel über Retrospektiven weiterentwickelt werden.Manchmal kann es dabei hilfreich sein, das Kernthema hinter einem Wertequadrat herauszuarbeiten. In unserem Beispiel ist das der Planungsprozess selbst. Wer plant wie was ein? Wie stark ist die Gruppe beziehungsweise jedes einzelne Mitglied in den Planungsprozess eingebunden? Wie können aus dem Planungsprozess beziehungsweise seinem Ergebnis (Plan) Parameter für die Selbststeuerung abgeleitet werden (KPI)? Mit den Antworten auf diese Fragen kann dann die auf dem Wertequadrat ba­sierende Selbststeuerung im Team erfolgen.Doch auch hier dürfen wir bezüglich der KPI nicht zu stark in die Extreme gehen. „If you can’t measure it, you can’t manage it” ist ein weit verbreitetes Zitat, das sowohl auf Edward Deming als auch Peter Drucker zurückgeht. Beide sind renommierte Management-Gurus. Deming selbst warnte auch davor, ein Unternehmen nur nach den Zahlen und Businessgrafiken steuern zu wollen. Ein einzelner Fakt wird ja nicht dadurch relevanter, dass wir ihn leicht messen können. Auch wird es immer wieder Aspekte geben, die wir managen, ohne dass wir sie gut messen können. Selbst­steuerung benötigt KPI ebenso wie Augenmaß und ein „Gefühl“ für die Situation. Diese Intui­tion gilt es bewusst zu entwickeln, indem wir uns immer wieder klarmachen, wie die sichtbaren Zusammenhänge zu unserer gefühlsmäßigen Bewertung einer Situation stehen. Wenn wir das greifbar und damit besprechbar machen, ist im Team schon viel gewonnen. Oder andersherum gesagt: Wenn mir ein erfahrener Mitarbeiter von einem bestimmten Bauchgefühl berichtet, ziehe ich das gleichermaßen (wenn nicht sogar stärker) bei meiner Bewertung in Betracht als die Trendanalysen aus einer KPI.

Werte zum Leben erwecken

Werte sind und bleiben eher abstrakte Orientierungspunkte. Daher werden sie zum Beispiel auch im bereits erwähnten Agilen Manifest [1] durch eine Reihe von Prinzipien ergänzt und erläutert. Daraus können konkrete Praktiken abgeleitet werden, über die wir dann die Werte in unserer täglichen Arbeit zum Leben erwecken. Das klingt logisch und zielführend. Doch auch hier lohnt ein genauerer Blick.Im Agilen Manifest werden die vier Wertepaare durch zwölf Prinzipien ergänzt. Alleine daraus lassen sich bereits Dutzende von agilen Praktiken ableiten. Und natürlich gibt es noch weitere agile Werte mit zusätzlichen Prinzipien mit wohl Hunderten agilen Praktiken. Alleine das ist schon recht unübersichtlich.In meiner Arbeit zu lernenden Organisationen habe ich fünf Wertequadrate mit ebenfalls zwölf Prinzipien entwickelt und nenne 15 zentrale Praktiken [4]. Wir finden hier ebenfalls vergleichbare Mengengerüste. Auch hier bleibt die Frage, warum die Umsetzung auch für Experten stets schwierig ist.

Und warum ist das so schwierig?

Werte sind und bleiben eher abstrakt. Wie sieht es mit den Prinzipien aus? Die sollen uns doch bei der Umsetzung helfen. Leider sind Prinzipien immer noch abstrakter als konkrete Praktiken und zusätzlich können sie sich auch noch widersprechen. Wir kennen das in der Softwareentwicklung aus Pattern beziehungsweise von Architekturprinzipien. Martin Fowler hat ein ganzes Buch über Refactoring geschrieben [5] und zeigt darin, wie man aus einem Pattern A schrittweise zu einem Pattern B kommt. Und ein paar Seiten später zeigt er den Weg von Pattern B nach Pattern A. Stets leitet er ein Refactoring mit einem Beispiel ein, warum dieses Refactoring wichtig und richtig ist. Es gibt also kein allgemeingültiges Pattern.„Uncle“ Bob Martin hat das Open-Closed-Prinzip, das auf Bertrand Meyer zurückgeht, beschrieben, das den Widerspruch bereits im Namen trägt [6] [7] [8]. Es geht dabei um die Erweiterbarkeit bestehender Software. Sie soll gleichzeitig offen für Erweiterungen und geschlossen gegenüber Modifikationen sein.Im Agilen Manifest finden wir zum Beispiel einen Widerspruch gleich zwischen den ersten beiden Prinzipien [1]: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“Wir sollen also bereits in frühen Projektphasen regelmäßig „wertvolle, also nutzbare Software“ ausliefern. Dieses Prinzip fordert eine inkrementelle Entwicklung mit klar vonei­nander getrennten Funktionen und Modulen. Das klingt logisch. Wie können wir aber dann auch noch auf späte Änderungswünsche, die sich vielleicht bis in die Architektur auswirken, reagieren? Anpassungen mit solchen Auswirkungen sind in späten Projektphasen oft kaum noch oder nur sehr teuer möglich. Oder positiv formuliert: In späten Projektphasen sind meist nur noch Anpassungen der Anforderungen möglich, die keine Auswirkungen auf die grundlegende Architektur haben. Prinzipien können sich also widersprechen, wenn wir versuchen, sie anzuwenden.Wie können wir die Widersprüche auflösen? Durch Ausprobieren und das Sammeln von Erfahrungen. Als Programmierer entwickeln wir auf diese Weise ein Gefühl dafür, wann das Pendel in die eine und wann in die andere Richtung ausschlagen sollte. Dieser Prozess ist also ein individueller Lernprozess. Genau das macht die Diskussionen unter Kollegen jedoch auch schwierig. Jeder Mensch sammelt seine eigenen Erfahrungen. Die Vorschläge und Argumente werden aus diesen Erfahrungen heraus entwickelt und vorgebracht. Wenn zwei Entwickler über die Umsetzung eines zustandsbehafteten Systems diskutieren und die eine Person gute Erfahrungen in der Implementierung von State Charts gemacht hat und die andere mit der Umsetzung des State Patterns, wird das Gespräch entsprechend den individuellen Erfahrungen laufen und einen starken Bezug zu Problemen und Lösungen aus der Vergangenheit haben.Was dabei jedoch vernachlässigt wird, ist die neutrale Beurteilung der Aufgabe und der zukünftigen Situation. Doch genau das wäre notwendig. Aus den beiden erlernten, jedoch unterschiedlichen Erfolgsmustern braucht eine erfolgreiche Diskussion entweder sehr reife Beteiligte oder einen erfahrenen Moderator beziehungsweise Architekten, der nicht die Lösung vorgibt, sondern sie anhand der konkreten Aufgabe gemeinsam mit den beiden und ihrer Erfahrungen entwickelt. Eine wichtige Frage ist dabei, was mit der alten Lösung nicht (gut) möglich war.

Lösungen für komplexe Probleme sind individuell

Eine solche Design-Diskussion lässt sich meist konstruktiv klären. Jedoch haben wir es dabei bereits zumindest manchmal mit komplexen Aufgaben zu tun. Wenn wir nach diesem kleinen Ausflug zu dem Thema der wertebasierten Frameworks zurückkommen, haben wir es dabei stets mit einer hohen Komplexität zu tun. Das bedeutet wiederum, dass eine solche Aufgabe nicht vollständig vorab planbar ist [4]. Unsere Er­fahrung hilft uns bei der Bewältigung daher nur begrenzt. Die Erfahrung ist hilfreich bei der Auswahl und Umsetzung von begleitenden Methoden und grundlegenden Einführungsprozessen, nicht jedoch, was die konkrete spätere Lösung anbelangt.Die Lösung ist, nein, sie muss, um zu funktionieren, ebenso komplex sein wie die Aufgabe, die wir bewältigen wollen. Damit ist die Lösung auch so individuell, wie es die Aufgabe ist [4]. So darf zum Beispiel ein externer Berater keine Lösung, die bei einem ähnlichen Problem bei Kunde X funktioniert hat, dem Kunden Y überstülpen. Die Lösung ist stets individuell zu entwickeln.Es ist sogar noch komplexer, wenn wir die Zeit mitbetrachten. Die Menschen in einer Organisation entwickeln sich mit der Zeit weiter. Damit entwickeln sich auch Gruppen weiter. Das bedeutet, dass eine Lösung A, die jetzt passt und trägt, in zwei Jahren nicht mehr angemessen sein muss. Oder dass eine Lösung B, die jetzt die Beteiligten überfordern würde, in zwei Jahren genau das Richtige sein kann.Wertebasierte Frameworks können uns bei der Weiterentwicklung von Personen, Teams und Organisationen grundlegend helfen und Orientierung geben. Was sie aber nicht leisten können, ist, sich selbst einzuführen und weiterzuentwickeln. Dieser Meta-Prozess, der um ein wertebasiertes Framework herumläuft, ist ebenso wie die konkrete Umsetzung des Frameworks individuell.

Fazit

Lösungen für komplexe Aufgaben sind individuelle Lösungen. Die Einführung und Weiterentwicklung eines wertebasierten Management-Frameworks wie Scrum für Agilität oder eines wertebasierten Modells für lernende Organisation ist eine hochkomplexe Aufgabe. Die Erfahrungen der beteiligten Personen können bei der Auswahl des begleitenden Einführungsprozesses und den dabei angewendeten Methoden helfen. Die Lösung ist jedoch in jedem Umfeld und zu jedem Zeitpunkt eine individuelle. Damit können andere konkrete Lösungen nicht erfolgreich wie Blaupausen übernommen werden. Es gibt dabei keine Abkürzungen. Solche Aufgaben sind und bleiben anspruchsvoll. Das ist nicht schlimm, sondern spannend und reizvoll. 

Fussnoten

1. Kent Beck et al., Manifest für Agile Softwareentwicklung, http://www.dotnetpro.de/SL2110Agilitaet1
2. Friedemann Schulz von Thun, Miteinander reden 2 – Stile, Werte und Persönlichkeitsentwicklung, Rowohlt, 38. Auflage, 2003 ISBN 978-3-499-18496-3,
3. Friedemann Schulz von Thun, Johannes Ruppel, Roswitha Stratmann, Miteinander reden: Kommunika­tionspsychologie für Führungskräfte, Rowohlt, 2005, ISBN 978-3-499-61531-3,
4. Uwe Vigenschow, Lernende Organisationen, dpunkt.verlag, 2021, ISBN 978-3-86490-798-2,
5. Martin Fowler, Refactoring – Wie Sie das Design bestehender Software verbessern, mitp, 2. Auflage, 2020, ISBN 978-3-95845-942-7,
6. Robert C. Martin, Agile Software Development – ­Principles, Patterns, and Practices, Pearson, 2003, ISBN 978-1-292-02594-0,
7. Robert C. Martin, The Open-Closed Principle, in C++ Report, Januar 1996, http://www.dotnetpro.de/SL2110Agilität2
8. Bertrand Meyer, Object-oriented Software Construction, Prentice Hall, 1988, ISBN 978-0-13-629031-5,