Wo fängt man mit Agilität eigentlich an?

Scrum, Kanban, Definition of Done: Irgendwer hat gesagt, dass agil der neue Hype ist. Die Aussage bewegte sich irgendwo zwischen „Mit agil wird es für alle besser“ und einem leicht theatralischem „Wenn wir überleben wollen, müssen wir uns mit Agilität beschäftigen“ – und irgendwie fragst du dich: Was soll das Ganze?

Irgendwann kam jemand mit einem Buch über Scrum und einer großen Idee an.

Wir müssen jetzt dringend agiler werden, hat er gesagt, und mit Begriffen wie VUCA (Volatility, uncertainty, complexity and ambiguity) um sich geschmissen. Okay, okay, dir ist schon klar, dass sich die Welt irgendwie verändert hat und wir etwas verändern sollten, aber muss man denn gleich die ganzen bisherigen Praktiken über Board werfen und ein ganz neues Set von Rollen und Verhaltensweisen annehmen?

Einen Schritt zurück: Was wollen wir denn eigentlich erreichen?

Wir wollen ein Problem lösen.

Ich schätze, als die Unterzeichner des agilen Manifests ansetzten, etwas zu unternehmen, dass zu einem Thema werden sollte, dass mehr oder minder ihre ganze Branche, vom Entwickler bis zur Geschäftsführung, beeinflusssen sollte, hatten sie eigentlich nur ein Problem im Sinn.

Wir Menschen lieben Problemlösung, aber wir Menschen mit technischem Hintergrund ganz besonders.

Die Erfahrenen unter uns sind auch richtig gut darin; intuitiv wenden sie verschiedene Heuristiken an, um die Ursachen einzugrenzen, das Problem zu verstehen und schließlich zu lösen. Nicht selten generieren sie dabei Erkenntnisse, mit denen sie nicht nur das Problem lösen, sondern auch den Ausgangszustand verbessern können. Wenn man sie denn lässt.

Nicht einfach nur ein Bug

Interessanterweise war die Problemstellung in der Softwarebranche etwas anders als die üblichen technischen Probleme, und -obwohl manch einer für diese Art von Troubleshooting den Entwicklern vermutlich nicht das Skillset attestiert hätte – erkannten sie sehr gut, dass es nicht allein um technische Themen ging.

Die Softwarebranche steckte nämlich in der Krise und die Entwickler waren direkt betroffen.

Zu viel zu tun, zu wenig Zeit: Der Bedarf an Software war immer größer geworden und die bisherige Herangehensweise führte dazu, dass von der Konzeption bis zur Marktreife von Software zu viel Zeit vergeht, um den Marktbedürfnissen gerecht zu werden. Einige Projekte wurden mitten im Verlauf abgebrochen, andere konnten bei ihrem Abschluss die geschäftlichen Erwartungen nicht mehr erfüllen.

Irgendwie ist jeder ein bisschen schuld … irgendwie auch nicht

In so einer Situation ist es all zu leicht nach Schuldigen zu suchen. So ist für jeden irgendein Anderer Schuld:

• Die Entwickler sind Schuld, weil sie zu lange brauchen und zu sehr auf ihr begrenztes Problemgebiet schauen.

• Die Manager und Projektleiter sind Schuld, weil sie nur Druck machen statt an der Problemlösung zu arbeiten.

• Der Kunde ist Schuld, weil er nicht weiß, was er eigentlich will, ständig seine Meinung ändert und alles sofort und gleich haben will.

• Die Ops-Leute, die Admins und Infrastruktur-Experten sind natürlich auch Schuld, weil sie mit den Lieferungen der Entwickler nie zufrieden sind und mehr Wert auf „Never change a running system“ legen als auf Flexibilität.

Eigentlich ist es aber nicht so einfach, sondern viel mehr komplex.

Die Probleme immer bei den Anderen zu sehen ist zwar einfach und naheliegend, aber wäre es nicht viel zielführender, sich mehr mit Zusammenarbeit zu beschäftigen und wie man sie verbessern kann?

Vielleicht doch ein Bug?

Vielleicht ist es ja doch ein Bug – und zwar im System. Einem System, das darauf ausgelegt ist, „over the wall“ zu arbeiten, also jeder in seiner Problemdomäne, ohne Blick nach links oder rechts, ein Problem nach dem Anderen lösen – und es schließlich über die Mauer zu einem anderen Fachbereich zu werfen.

Vielleicht war dieses Systemdesign auch irgendwann zielführend und muss jetzt einfach weiter entwickelt werden. Weil sich die Bedingungen geändert haben und der Kunde beispielsweise nicht einfach nur seine Meinung ständig ändert, sondern einfach auf die geänderte Bedingungen reagiert.

Wie fängt man denn jetzt an mit Agilität?

Ich bin doch kein Softwarentwickler und hab ganz andere Probleme wirst du vielleicht sagen. Aber wenn du bis hierhin gelesen hast, bist du wahrscheinlich auch schon etwas weiter 😉

Das ständige Genörgel kennt man ja doch eigentlich überall, oder? Dabei könnte hin- und wieder ein Lob viel mehr fruchten. Hin und wieder festzustellen wie klar und sauber das Wasser ist – statt auf das halbleere Glas zu schauen – das könnte dir und anderen Aufwind geben.

Glaubste nicht? Na dann probier es doch einfach mal aus.

Etwas über die Anderen lernen – der vielleicht beste Anfang für Agilität

Überhaupt könnte etwas über die Anderen lernen, über ihre Beweggründe und Motive, der beste Anfang für Agilität sein.

Also – wenn du es eilig hast, diesen Artikel zu beenden: lies etwas über Retrospektiven, über Appreciate Aquiry und frag dich: Könnte es mir etwas nützen? Würde es mich weiterbringen, etwas über die Anderen und meine Zusammenarbeit mit ihnen zu erfahren?

Wenn sich nämlich eines durch das agile Manifest und die zugehörigen Prinzipien durchweg ausmachen lässt, ist es der Fokus auf das Miteinander: miteinander den Kunden zufrieden stellen, miteinander und über Spezialisierungsgrenzen hinweg interagieren und kollaborieren, auch und gerade mit dem Kunden.

Etwas über Motivation lernen: Autonomy, Mastery, Purpose

Eigentlich keine besonders neue Erkenntnis, dass motivierte Individuen die beste Arbeit abliefern.

Trotzdem tut sich ein Spalt auf zwischen dem, was die Wissenschaft über Motivation weiß und was im Business praktiziert wird, sagt Daniel H. Pink, der Autor von „Drive: Was Sie wirklich motiviert“ (Affliate-Link). Seine These ist, dass äußere Anreize wie Geld und Prestige weniger zur Motivation beitragen und echte Motivation auf den folgenden Faktoren fußt: Selbstbestimmung, Perfektionierung, und Sinnerfüllung.

Ich weiß nicht, wie es dir geht, aber ich erkenne daran für mich viel Wahres. An etwas Sinnvollem arbeiten, dabei meine individuellen Fähigkeiten einsetzen und verbessern können, finde ich schon ziemlich motivierend. Aber ohne Selbstbestimmung, ohne das Gefühl meine Lage im Griff zu haben, geht gar nichts.

Eventuell denkst du: „Schön und gut – aber bin ich nicht der falsche Adressat für dieses Gerede? Red doch mal mit meinem Chef.“

Du wirst wahrscheinlich schon wissen, worin du gut bist. Gut so.

Weißt du auch, was du (selbst entscheiden) darfst oder nicht darfst und für welchen Zweck du deine Arbeitsleistung erbringst? Kennst du die Anforderungen deiner Kunden oder die Zwänge deines Chefs? Was könntest du tun, um etwas darüber rauszufinden?

Und wenn du Teamleiter, Projektleiter oder gar der Boss von Allen bist: Hilfst du deinen Teammitgliedern und Mitarbeitern dabei, den Sinn ihrer Tätigkeit zu verstehen und sorgst für optimale Bedingungen?

Letztlich macht es auch Sinn, herauszufinden, dass man in gewissem Maße schon agil ist – eine Bestandsaufnahme ist immer gut.

Erst jetzt mit Methoden beschäftigen

Erst jetzt lohnt sich meiner Meinung nach der Blick auf Methoden. Dabei sind Methoden wie Kanban, Scrum und Konsorten nicht der Pfad zur Erleuchtung, sondern einfach nur ein guter Ausgangspunkt. Diesen Methoden liegen viele kluge Gedanken zugrunde und es lohnt sich, sich einfach mal darauf einzulassen.

Agilität ist kein Ziel, sondern ein dauerhafter Prozess

Lernen und experimentieren

Wenn man dann noch zusammen daran arbeitet, mit allen im Team und in Zusammenarbeit mit dem Kunden den Status Quo immer wieder und für Alle zu verbessern, dann ist man eigentlich schon mitten drin in diesem Agilitätsding.

Agilität ist nämlich kein Ziel, sondern ein dauerhafter Prozess und tatsächlich eine Notwendigkeit.