Modern Agile Principles: Agiler arbeiten einfach gemacht

Gastbeitrag von | 13.02.2020

Agilität ist in aller Munde. Und unter uns: das Thema ist ziemlich unübersichtlich geworden, oder nicht? Vor kurzem hat Felix Stein auf seinem Blog ganze 240 agile Zertifizierungen zusammengetragen, in einer sicher nicht vollständigen Liste.1 Und um die Übersichtsdarstellung agiler Methoden von Deloitte noch zu durchblicken, braucht man fast schon ein eigenes Hochschulstudium.2

Vielleicht lohnt es sich an dieser Stelle, all diese Methoden, Prozesse, Frameworks und Zertifizierungen mal beiseite zu schieben, und sich auf das zu besinnen, worauf es letztlich wirklich ankommt – gewissermaßen die Axiome agilen Arbeitens, also die Grundüberzeugungen, an denen sich alles weitere Denken und Handeln orientiert. Und wie es Simon Sinek schon so prägnant zusammengefasst hat: wir sollten mit dem “Wozu” beginnen.3 Also – wozu agil(er) arbeiten?

Selbst wenn Begriffe wie “Marktführer” oder Unternehmens-Rankinglisten etwas anderes suggerieren, kann man Wirtschaft ja nicht “gewinnen”. Gewinnen setzt ja ein Ende voraus, welches bei Wirtschaft offensichtlich nicht gegeben ist – da geht das Spiel nämlich weiter. Ob wir letztes Jahr erster oder letzter in der Tabelle waren, interessiert für das kommende Jahr überhaupt nicht. Das bestmögliche Ergebnis für jedes Unternehmen kann dann nur sein, langfristig zu überleben, in einem Umfeld, das sich laufend ändert und neue Anforderungen an sie stellt.

Diesen externen Veränderungen dauerhaft nicht gerecht zu werden, bedeutet das Ende der Organisation, üblicherweise durch Insolvenz und/oder Zerschlagung. Eine der wichtigsten Eigenschaften einer langfristig erfolgreichen Organisation ist also Anpassungsfähigkeit.

Prinzip schlägt Regel

Wenn Anpassungsfähigkeit unser Ziel ist, sind Regeln (im Sinne von “Wenn-Dann”-Anweisungen), Vorschriften und Prozesse grundsätzlich mit Vorsicht zu betrachten. Schließlich können wir nur reglementieren, was wir uns vorstellen können – die wenigsten Unternehmen sind aber an vorhersehbaren Ereignissen zugrunde gegangen. Stattdessen zwingen wir durch übermäßige Reglementierung Menschen bei jeder größeren Überraschung in ein Dilemma – ignorieren sie die Änderung, und riskieren, den Anschluss an den Markt zu verlieren? Oder ignorieren sie die Regeln und riskieren disziplinarische Konsequenzen?

Etwas schärfer formuliert: Allein dass Mitarbeiter täglich unter Umgehung der Regeln und Strukturen des Unternehmens Dinge tun, hält Unternehmen überhaupt handlungs- und damit überlebensfähig. Eine Organisation, in der jeder Arbeitsschritt und jede Kommunikation vordefinierten Abläufen folgt, ist weder realisierbar noch erstrebenswert.

Regeln sind also schon aufgrund ihrer Natur ungeeignet, mit Veränderungen im Markt umzugehen. An ihre Stelle treten handlungsleitende Prinzipien. Ein Prinzip verlangt Interpretation, um genutzt zu werden, es muss also immer die Frage gestellt werden, was das Prinzip in der gegebenen Situation bedeutet und wie es anzuwenden ist.

Anstatt alle möglichen Abläufe in unflexiblen Prozessen zu regeln und damit die Menschen weitgehend austauschbar zu machen, gehen wir genau andersherum vor: der intelligent denkende, situativ handelnde Mensch rückt ins Zentrum des Geschehens, Entscheidungen werden individuell, lokal, und je nach Bedarf getroffen. In unterschiedlichen Situationen wird also auch unterschiedlich gehandelt, die Machtverhältnisse im Unternehmen verschieben sich zugunsten kundennaher, dezentraler Bereiche. Das nehmen wir nicht nur in Kauf, sondern es ist sogar die logische Folge eines konsequenten Situations- und Kundenfokus.

Vor diesem Hintergrund wirkt eine ideologische Debatte über konkrete Methoden dann etwas albern. Agile Methoden wie Scrum sind Werkzeuge, und wie andere Werkzeuge auch, werden sie situationsbezogen eingesetzt, um ein konkretes Problem zu lösen. Alle Teams auf Scrum “umzustellen” ist da genauso wenig sinnvoll, wie alle Schreiner nur noch mit der Stichsäge arbeiten zu lassen. Die Methode muss zum Problem passen, also von den Menschen ausgewählt und angewendet werden, die das lokal zu lösende Problem am besten verstehen. Stattdessen ist es wichtig, gemeinsam handlungsleitende Prinzipien zu vereinbaren, die in unerwarteten Situationen eine Orientierung in Richtung Kunden- und Ergebnisfokus bieten – und dann den Teams die konkrete Umsetzung der Prinzipien zu überlassen.

Modern Agile

Betrachten wir mal ein Beispiel: Bei der Gründung meines aktuellen Teams vor etwa zwei Jahren, haben wir gemeinsam die vier “Modern Agile”-Prinzipien4 als Arbeitsgrundsätze ausgewählt. Wer es nicht kennt: Modern Agile ist eine offene, von Joshua Kerievsky Ende 2015 ins Leben gerufene Community, die erfrischenderweise ohne Zertifizierungen und Consultants auskommt. Die vier Prinzipien der Community beschreiben Eckpfeiler agilen Arbeitens auf persönlicher und Teamebene, und haben unsere Arbeit seither entscheidend geprägt. Als Grundlage kompletter agiler Organisationen sind sie in meinen Augen allerdings nicht ausreichend, hier würde ich auf Ideen wie z.B. den BetaCodex5 verweisen.

Modern Agile Principles

Prinzip 1: Mache Menschen großartig

Der zentrale Faktor für wirtschaftlichen Erfolg ist der Mensch. Vor allem in einer von zwei entscheidenden Rollen: Menschen, die unsere Produkte und Services kaufen, wenn diese ihre Probleme lösen – diese nennen wir Kunden. Und Menschen, die diese Produkte und Services entwickeln und anbieten, wenn sie ein geeignetes Arbeitsumfeld vorfinden – diese nennen wir Mitarbeiter oder Kollegen.

Kunden begeistern wir, indem wir ihre Probleme treffsicher und elegant lösen – Mitarbeiter machen wir großartig, indem wir ein Arbeitsumfeld schaffen, in dem sie sich auf das gemeinsame Lösen von Kundenproblemen fokussieren können. Ich wage mal die These in den Raum zu stellen: wer begeisterte Kunden und großartige Mitarbeiter hat, für den wird Geld verdienen ein lösbares Problem sein.

Das klingt jetzt alles banal, ist in der Praxis aber eine anspruchsvolle Aufgabe. Unter anderem gilt es herauszufinden, welches Problem unser Kunde genau hat. Wer das trivial findet, der überlege mal, wozu ein Mensch z. B. eine Bohrmaschine kauft – in der Regel nämlich nicht, weil er gerne Löcher bohren möchte. Genauso wenig buchen Menschen Flugtickets, um zu fliegen, oder kaufen einen Milchshake, weil sie etwas trinken wollen.6 Kunden großartig zu machen, bedeutet ihr Problem tief und umfassend zu verstehen, und es auf eine Weise zu lösen, die sich mühelos in den Alltag der Kunden einfügt.

Damit Mitarbeiter des Unternehmens in der Lage sind, Kundenprobleme auf großartige Weise zu lösen, ist es wichtig, ihnen alles dazu Nötige schnell und unkompliziert zur Verfügung zu stellen – sei es Arbeitsmaterial, Informationen, Zeit, Geld, Entscheidungsbefugnisse, Unterstützung oder Rahmenbedingungen. Jede Behinderung ihrer Arbeit, etwa in Form von Bürokratie, Vorschriften und Prozessen, will gefunden und entfernt, oder zumindest auf das rechtlich notwendige Mindestmaß reduziert werden. Ein einfacher Weg ist hier, Mitarbeiter als “Kunden” der zentralen Verwaltung zu betrachten – typischerweise wissen diese sehr genau, welche Produkte und Services der Organisation sie als wertvolle Unterstützung in Anspruch nehmen wollen und welche nicht, wenn man ihnen die Nutzung freistellt.

Wer hier noch nicht aufhören will, findet im ersten Prinzip noch genügend Futter für weitere Verbesserungen:

  • Was kann man etwa selbst tun, um die eigenen Kollegen großartig zu machen?
  • Wie kann die Organisation ihre Partner und Zulieferer in ihrer Arbeit unterstützen?
  • Kann es eventuell sogar von Vorteil sein, die Mitbewerber zu unterstützen, um etwa einen gemeinsamen Markt aufzubauen, wovon wiederum alle profitieren würden?

Ellbogenmentalität ist hier nicht gefragt, das Ziel ist vielmehr, um sich herum ein prosperierendes Ökosystem zu entwickeln. “Willst du weit reisen, dann reise gemeinsam”.

Prinzip 2: Liefere kontinuierlich Wertvolles

Egal wie gut eine Lösung für ein Kunden- oder Mitarbeiterproblem sein mag, sie kann erst mit der Inbetriebnahme überhaupt beginnen, Nutzen zu schaffen. Ein neues Produkt oder Service ist bis zum Moment der ersten Nutzung also weitgehend wertlos. Mein Freund und Kollege Tom Strube bringt es leicht anders auf den Punkt: “Business-Wert ist solange nur Hypothese, bis er vom Markt bestätigt wird.” Das bedeutet, dass nicht nutzbare Produkte und Services ein erhebliches unternehmerisches Risiko darstellen, welches umso größer wird, je länger und aufwändiger die Arbeitsphase vor dem ersten Kundenkontakt ist.

Um dieses Risiko zu reduzieren, brauchen neue Ideen also so bald wie möglich den Kontakt mit der “echten” Welt, um früh und fortlaufend durch Kundenkontakt weiterentwickelt werden zu können. Ein einfaches Produkt im Markt ist also einem mächtigen Produkt auf dem Papier vorzuziehen. Oder noch anders betrachtet: Produkte können und sollen zeitgleich in Entwicklung und im Livebetrieb sein. Hier zeigen sich offensichtliche Parallelen zu Ideen wie Scrum (“Software in 30 Days”) und Konzepten aus dem Lean Startup (“Minimum Viable Product”) und New Work (“Permanent Beta”), auch wenn diese Methoden vielerorts noch dazu missbraucht werden, viel zu große Vorhaben ohne Kundenkontakt, aber dafür scheibchenweise umzusetzen.

Prinzip 3: Experimentiere und lerne zügig

An dieser Stelle sollten wir nun nicht in die Falle tappen, zu glauben, wir würden die Probleme der Kunden besser kennen als diese selbst. Aller Wahrscheinlichkeit nach haben wir nicht einmal genau verstanden, welches Problem Kunden gelöst bekommen wollen, geschweige denn, wie sich die Lösung in den Alltag unserer Kunden einfügen muss. Das dritte Prinzip soll uns also erinnern, unsere Annahmen und Vorgehensweisen ständig zu überprüfen, unser Denken und Handeln zu reflektieren, und laufend an der eigenen Verbesserung zu arbeiten.

Um gemeinsames Lernen zu fördern, hilft es, Vermutungen und Hypothesen mit kleinen, überschaubaren Tests zu validieren – nicht im Sinne eines unreflektierten “einfach mal machen” – Aktionismus, sondern bewusst, absichtsvoll und wohlüberlegt. Frühes und kontinuierliches Einbeziehen der Nutzer in die Produktentwicklung ist eine sinnvolle Anwendung dieses Prinzips, genauso wie regelmäßige, gemeinsame Retrospektiven zur Verbesserung der Zusammenarbeit. Nutzer und Entwicklungsteams treten in direkte Interaktion miteinander – die Zeiten der Projekt- und Accountmanager als “Schnittstelle” zum Kunden sind vorbei.

Prinzip 4: Mache Sicherheit zur Grundvoraussetzung

Um sich in komplexen, volatilen Umgebungen langfristig erfolgreich zu bewegen, sind umfangreiche Planung, festgeschriebene Abläufe und detaillierte Rollenbeschreibungen nicht geeignet. Eine Abkehr von diesen Werkzeugen bedeutet aber für die Beteiligten steigende Ungewissheit: Entscheidungen werden möglichst spät getroffen, nichts ist je final, alles muss individuell ausgehandelt werden. Fragen nach dem Umgang mit Risiken stellen sich vollkommen neu: Ist unser Geld beim neuen Partner wirklich gut investiert, auch wenn das Lieferobjekt nicht präzise definiert ist? Wie gut versteht das Projektteam die Kundenanforderungen? Können wir uns darauf verlassen, dass unser Handeln auch ohne langfristigen Plan zielorientiert sein wird?

Umso wichtiger ist es, aus Ungewissheit nicht Unsicherheit werden zu lassen. Im Gegenteil: um überhaupt die übrigen drei Prinzipien einhalten zu können, ist es entscheidend, dass das Umfeld für die beteiligten Menschen möglichst frei von Gefahren ist, also dass sich Menschen um ihr Geld, ihre Lebenszeit, ihre Gesundheit und ihre Reputation keine Sorgen machen müssen.

Sicherheit bedeutet also psychologische Sicherheit7 im Arbeiten, etwa im Sinne einer Prime Directive.8 Genauso bedeutet es aber, nicht einfach nach mehr Mut und “Fehlerkultur” zu rufen, sondern grundsätzlich davon auszugehen, dass Fehler passieren werden, und das Umfeld aktiv so zu gestalten, dass diese früh auffallen und nur geringen Schaden anrichten können. Niemand von uns möchte das nächste Knight Capital9 werden, egal wie wertschätzend intern mit einer Katastrophe dieser Art umgegangen wird.

Praktiken aus dem eXtreme Programming, wie z.B. Code Reviews, Pair Programming, Test- und Deployment-Automatisierung oder testgetriebene Entwicklung zeigen, wie man Softwareentwicklung sicherer gestalten kann – für andere Organisationsbereiche lässt sich hier sicher ebenfalls etwas lernen.

Die vier Prinzipien funktionieren nur im Verbund. Ohne Sicherheit kann kein zügiger gemeinsamer Lernprozess stattfinden. Ohne Lernprozess wird es uns schwer fallen, regelmäßig wertvolles zu liefern. Ohne wertvolles zu liefern, werden wir Kunden nicht großartig machen können. Ohne Sicherheit als Grundvoraussetzung fallen die Prinzipien also wie ein Kartenhaus in sich zusammen.

Fazit

Warum prinzipiengeleitetes Handeln? Gerade angesichts der gegenwärtigen Popularität von Methoden, Beratern und Zertifizierungen möchte ich an dieser Stelle eine Lanze für das Selbst-Denken brechen.

In einem Umfeld, in dem gemeinsam konsequent nach den vier genannten Prinzipien gehandelt wird, ist die Auswahl der “richtigen” agilen Methode nebensächlich. Für ein Team, welches sicher agiert, zügig lernt, und Kunden durch fortlaufende Lieferung von wertvollen Ergebnissen großartig macht, sind Detailfragen wie Schätzpoker, User Story-Formate und Sprintlängen doch geradezu uninteressant. Und dass uns umgekehrt diese Werkzeuge allein nicht automatisch ins wirtschaftliche Eldorado führen, sehen wir ja in der Praxis deutlich.

Am charmantesten am prinzipienbasierten Ansatz finde ich persönlich aber, dass er keine Vorbedingungen hat. Niemand von uns braucht Freigaben oder Ressourcen, um nach eigenen Prinzipien handeln zu können – und ob unsere Organisation oder auch die des Kunden, “bereit für agil” ist, spielt ebenfalls keine Rolle. Alles, was wir tun müssen, ist unser Handeln laufend mit den Prinzipien abzugleichen:

  • Hilft es Menschen, großartig zu sein?
  • Trägt es dazu bei, fortlaufend Wert zu liefern?
  • Unterstützt es unseren gemeinsamen Lernprozess?
  • Ist es für alle Beteiligten sicher?

Gemeinsames Handeln, das diese vier Bedingungen erfüllt, kann uns auf Dauer nur erfolgreicher machen. Und Erfolg ist ja, um den Kreis zu schließen, letztendlich der Grund, wozu wir das mit der Agilität überhaupt tun.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Weitere Artikel von Kai-Marian Pukall sind u. a. bei Inspect & Adapt und auf LinkedIn zu finden.

[1] 240 agile Zertifizierungen im Blog bei Felix Stein
[2] Übersichtsdarstellung agiler Methoden von Deloitte
[3] Simon Sinek, Start with Why
[4] Modern Agile Prinzipien von Joshua Kerievsky
[5] BetaCodex
[6] Understanding the job: Milkshake
[7] Psychologische Sicherheit
[8] Prime Directive
[9] Knight Capital

Top 2020 Blogbeitrag - einer der am meisten gelesenen Beiträge in 2020
Dies ist ein Best of Blog 2020 Beitrag. Hier können Sie sich die besten Beiträge aus 2020 herunterladen.

Kai-Marian Pukall hat weitere Beiträge im t2informatik Blog veröffentlicht:

t2informatik Blog: Agiles Risikomanagement - braucht man das?

Agiles Risikomanagement – braucht man das?

t2informatik Blog: Rollenklärung im Team

Rollenklärung im Team

t2informatik Blog: Entscheidungsfähigkeit - der Erfolgsfaktor eingespielter Teams

Entscheidungsfähigkeit – der Erfolgsfaktor eingespielter Teams

Kai-Marian Pukall
Kai-Marian Pukall

Kai-Marian Pukall arbeitet als Senior Agile Coach für die Chili and Change GmbH. Seit vielen Jahren begleitet er agile Teams, immer mit dem Ziel, die Zusammenarbeit wertvoll und professionell, einfach und menschenfreundlich zu gestalten. Den Lean-Grundsatz “Eliminate Waste” wendet er bevorzugt auf alles an, was nach Methoden- und Businesstheater riecht.