Frischfleisch am Werk – Das Agile Manifest (von Iris Kussatz)

Ist es das? Ist das wirklich alles? Als ich dem Link gefolgt bin, der mich zum Manifest für Agile Softwareentwicklung leiten sollte, hatte ich einen mehrseitigen Artikel erwartet, in dem dieses komplizierte Konstrukt mit Beispielen und in aller Ausführlichkeit beschrieben wird – ein bisschen wie die Bibel der Organisationen. Was ich aber auffand war eine Seite, die aus zwei Dritteln schon mal nicht aus Inhalt, sonders aus Links zu anderen Sprachen besteht und ansonsten aus einer Ansammlung von Unterschriften, Informationen zu den Autoren und zur Entstehung des Manifests. Auf der Seite zur Geschichte des Manifests fand ich dann endlich den erwarteten (wenigstens mittellangen) Text und stürze mich in die Tiefen der Vergangenheit mit Daten, Fakten und Theorien, die sich über Jahre entwickelten. Oder auch nicht? Schon der erste Satz „… 17 people met to talk … and of course ,to eat“ hat mir ein Schmunzeln entlockt und der restliche Text hob meine Stimmung nur umso mehr, bis ich mich schließlich auf einer Comicseite wiederfand, weil ich das Wort „Dilbertesque“ nicht verstand! (Ein Comic von Adam Scott zu Unternehmenskultur und Management dessen Hauptperson „Dilbert“ ist – Sehr zu empfehlen!) Jedenfalls fand ich den historischen Abriss deutlich amüsanter als erwartet

.

Na gut, dann gucken wir mal, was es mit diesem mysteriösen Manifest auf sich hat und folgen dem Link zu den 12 Prinzipien: Eine ähnlich schlichte Seite empfängt mich, auf der das Hintergrundbild wohl noch das aufregendste darstellt. Da stehen sie nun diese 12 Prinzipien, einfach runtergeschrieben. Ohne Erklärungen, Beispiele oder sonst irgendwas. Ein bisschen wie die 10 Gebote auf der Steintafel. Hier habe ich versucht, meine ersten Gedanken einzufangen und da ich als Frischfleisch im Feld des agilen Arbeitens meinen Bildungsauftrag so allein nicht erfüllen kann, habe ich mir Frederik dazu geholt, um mir dabei zu helfen.

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

==> Easy. Der Kunde ist König.

→ „Stimmt in dem Sinne, dass der Kunde die beste Anlaufstelle ist, um Orientierung zu bekommen, wann, was und wie viel geliefert werden soll.„

2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

==> Okay, das ist schon etwas schwieriger… Ich soll dankbar dafür sein, wenn etwas nicht nach Plan läuft?

→ „Dankbar bist du, wenn deine Kund*innen ehrlich zu dir sind und wichtige Veränderungswünsche ansprechen. Diese können den Marktwert erhöhen, sie zu ignorieren könnte wiederum sehr teuer werden.“

3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

==> Das ist ein interessanter Ansatz. Wenn man so schnell wie möglich ein funktionstüchtiges Produkt aufweisen kann und dieses nur noch in den Funktionen erweitert, dann habe ich während der Entwicklung parallel ständig ein schon funktionierendes Produkt. Wer entscheidet denn dann, wann es wirklich fertig ist und gibt es das überhaupt?

→ „Das entscheidet ganz einfach die Kund*in! Die kürzeren Zyklen geben die Möglichkeit der zeitnahen Anpassung/ Erweiterung je nach Nutzer*innenbedürfnis.“

4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

==> Ehrlich gesagt, dachte ich das wäre der Standard. Was macht man den stattdessen?

→ „In der Regel gehen sich alle aus dem Weg und sind überrascht, wenn sie sich dann doch mal zum Statusmeeting treffen. Daher ist hier die Empfehlung zumindest kurz eine tägliche Begegnung zu ermöglichen. Schwierigkeit: Manch einer denkt es sei nicht seine/ ihre Aufgabe zusammenzuarbeiten und die Zusammenarbeit zu managen.“

5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.

==> Ich kann mir vorstellen, dass das besonders in Führungspositionen schwer umzusetzen ist. Hat man nicht immer mal wieder den Gedanken, dass man es selber besser machen würde?

→ „Gegenseitiges Vertrauen entsteht nur durch Vertrauensvorschuss auf Seiten der Führungskraft, ist aber essenziell für jede Art der Zusammenarbeit. Führen heißt Vertrauen lernen. Vertrauen führt zu Motivation.„

6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

==> Ergibt Sinn! Schnell, ungefiltert und in Echtzeit. Nur die Umsetzung ist vielleicht manchmal schwierig.

→ „Das Prinzip: versuche es so oft wie möglich! Dieser Invest zahlt sich aus, denn er wirkt präventiv gegen Konflikte oder Missverständnisse.„

7. Funktionierende Software ist das wichtigste Fortschrittsmaß.

==> Hatten wir sowas ähnliches nicht oben schon mal (3. Prinzip)? Naja, dann scheint es wohl besonders wichtig zu sein.

→ „Das kommt wahrscheinlich daher, dass die Autoren Software-Entwickler sind :p und es unterstreicht die Ergebnisorientierung. Ergebnisse generieren Wert!„

8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

==> Das ist mir zu abstrakt. Ist schon klar, dass hier nicht das Laufen im Gang gemeint ist, aber der Rest muss mir erklärt werden.

→ „Hier geht es um die kontinuierliche Arbeitslast innerhalb eines Teams/Organisation. Abweichungen sollten in einem gewissen Rahmen bleiben. Der Vorteil: ein besseres Risikomanagement, da durch gleichmäßige Tempi sämtliche Arbeit planbarer wird. Das System läuft nicht unter Volllast, sondern gleichmäßig bei ungefähr 80%-iger Auslastung.„

9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

==> Ich weiß jetzt nicht, wie man durch akribische Korrektur von Kleinigkeiten besonders „wendig“ werden soll.

→ „Hier ist gemeint, dass die Ergebnisse einen hohen Anspruch und Qualitätsstandard gerecht werden sollen. Dies wird unterstützt durch einen gewissen Blick für exzellente Details. Achtung: beachte das 10. Prinzip!„

10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.

==> Paradox. Klingt ein bisschen als sollte man auf der faulen Haut liegen bleiben. Was ist denn hier gemeint?

→ „Ich bin davon überzeugt, dass uns hier die Sprachbarriere einen Streich spielt. Ich übersetze mir den Satz meistens mit: Einfachheit – die Kunst, die Menge nicht notwendige Arbeit zu minimieren – ist essentiell.“

11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

==> Wenn die Experten das sagen, dann wird das wohl stimmen.

→ „Ja, sehe ich auch so. Ich würde ergänzen „durch interdisziplinäre Teams, die sich selbst organisieren dürfen“, denn sie sind die eigenen ExpertInnen für ihre Aufgaben.„

12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

==> Die guten alten Reflexionsrunden. Also wenn sie es schon ins Manifest geschafft haben, scheinen sie ja wirklich etwas zu bringen. Oder? Wie viele Teams machen denn tatsächlich regelmäßige Reflexionsrunden?

→ „Das machen tatsächlich viele (mal mehr mal weniger gut). Entscheidend ist das gemeinsames Lernen und ein geeigneter Rahmen für Inspektion und Anpassung mit Bezug auf die Zusammenarbeit.„

Ich habe die 12 Prinzipien jetzt auf jeden Fall besser verstanden, brauche aber nach der ganzen Theorie mal eine Pause. Wenn Ihr euch für etwas mehr alltagtaugliches interessiert, dann schaut euch doch mal das „Agile Maturity Growth Model“ der New Work Academy an. Damit bekommt ihr ein Werkzeug zur Organisationsentwicklung an die Hand mit dem ihr Anhaltspunkte zur Beeinflussung der intrinsischen Motivation erhaltet. So fällt es vielleicht leichter, die agile Arbeit zum Arbeitsplatz zu bringen.