03.05.2019  in Agile Methoden  

Agile Werte – eine Bestandsaufnahme (Teil 1/2)

Damit agiles Arbeiten volle Wirkung entfalten kann, braucht es verlässliche Prinzipien und Werte. Das Agile Manifest definiert vier Wertepaare für eine erfolgreiche Softwareentwicklung.

Im agilen Umfeld gibt es zahlreiche Praktiken, die dabei unterstützen, Projekte erfolgreich durchzuführen. Das Schöne an Praktiken ist, dass man sie leicht lernen kann und sie für jedermann sichtbar sind. Setzt man diese Praktiken aber ein, ohne die dahinterstehenden Prinzipien und Werte zu berücksichtigen, dann verfehlen die Praktiken schnell ihre Wirkung und können sogar missbraucht werden (vgl. Michael O. Church Why “Agile” and especially Scrum are terrible).

Das Manifest für unfähige agile Software-Entwicklung spiegelt genau diese Frustration wider. Sucht man also nach den agilen Werten, so findet man eine Vielzahl an Inspirationen. Jedes Framework hat seine eigene Werteliste und Jurgen Appelo stellt eine ganze DIN A4-Seite mit Vorschlägen für Team-Werte bereit. Wie soll man sich da zurechtfinden?

Agiles Manifest
Sieht man das Agile Manifest als Grundsäule aller agilen Softwareentwicklung an, dann lassen sich alle Prinzipien und Praktiken auf vier Wertepaare zurückführen. Wertepaare, die jedoch konkurrierende Werte in sich tragen und deren Verhältnis zueinander auszutarieren ist. Um das Wirkprinzip zu verinnerlichen, hilft das Wertequadrat von Schulz von Thun.

Das Wertequadrat
Im Wertequadrat werden zwei gegensätzliche, positive Werte gegenübergestellt, z. B. Sparsamkeit und Großzügigkeit. Zu jedem dieser positiven Werte wird dann ein negativer Wert gesucht. Das geht ganz einfach: Wenn man eher sparsam ist und der Partner eher großzügig, dann wirft man ihm im Streit Verschwendung vor und er im Gegenzug Geiz. Aus dem Wertepaar und ihren Gegenspielern ergibt sich somit ein Wertequadrat, auf dem man seine Position bestimmen kann.

Solange man sich auf der Basislinie befinde, ist alles gut. Wenn man aber wirklich in Richtung eines negativen Wertes ausschlägt, dann kann man seine Entwicklung anstoßen, indem man sich in Richtung des gegensätzlichen positiven Wertes orientiert. Denn wenn man geizig ist, möchte man ja nicht verschwenderisch werden, sondern nur etwas großzügiger.

Nun zu den Wertepaaren im Agile Manifest. In diesem Blogpost wenden wir uns den ersten beiden Wertepaaren des Agile Manifests zu.

1. Wertepaar: „Individuen und Interaktionen“ und „Prozesse und Werkzeuge“

Das Agile Manifest sagt: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
Was bedeutet das? Es ist wichtig, definierte Prozesse einzuhalten und sinnvolle Werkzeuge zu verwenden. 

Prozesse
Wenn man jedes Mal aufs Neue überlegt, wie man vorgehen möchte, verschwendet man Zeit und Mühe. Prozesse helfen, wichtige Schritte nicht zu vergessen und einen Überblick über den Fortschritt zu haben.

Aber wichtiger als Prozesse zu definieren ist es, miteinander zu reden, sich auszutauschen. Nicht alle Arbeitsschritte lassen sich in Prozessen ausdrücken, das gilt besonders für Kreativprozesse. Gute Konzepte entstehen im Dialog, gute Projekte in der Zusammenarbeit. Prozesse können nämlich eine „Über-den-Zaun-werf-Mentalität“ fördern und eine Beschränkung der Aufmerksamkeit auf den aktuellen Arbeitsschritt – getreu dem Motto: „Nach mir die Sintflut, Hauptsache, ich bin fertig!“ Der Blick für das Ganze kann verloren gehen.

Tools
Gemeinsam abgestimmte und gute Tools helfen beim gemeinsamen Arbeiten. Schlechte Tools können einen hingegen in den Wahnsinn treiben. Zu viele spezielle Tools fördern jedoch Spezialistentum. Dann können bestimmte Arbeiten nur von bestimmten Personen durchgeführt oder noch schlimmer, bestimmte Informationen nicht von allen eingesehen werden. Oft reicht ein einfaches Tool, das jeder bedienen kann, um ein Ziel zu erreichen – beispielsweise Papier und Stift.

Warum sind Individuen und Interaktionen im agilen Kontext nun wichtiger? Weil agile Methoden besonders dann nützlich sind, wenn es um unvorhersehbare, schlecht planbare Situationen geht, wie zum Beispiel ein Software-Entwicklungsprojekt. Da braucht es einfach Menschen, die eigenständig entscheiden können, was in der konkreten Situation das sinnvollste Vorgehen ist. Wenn man sich nur an Prozesse halten muss, dann kann man auch Maschinen die Arbeit machen lassen. Aber im agilen Kontext sind die eigenverantwortliche Entscheidung jedes Individuums, die Selbstorganisation des Teams und die ständige Verbesserung der Hebel zum Erfolg.

Ausgewogenes Verhältnis
Um ein ausgewogenes Verhältnis zu finden, hilft das besagte Wertequadrat. „Individuen und Interaktionen“ einerseits und „Prozesse und Werkzeuge“ andererseits stehen dort als positives Wertepaar. Solange man sich auf der Basis-Linie bewegt, ist also alles in Ordnung. In agilen Kontexten sollte man sich aber eher im linken Bereich der Basis-Linie aufhalten.

 

Was passiert, wenn man es mit Prozessen und Werkzeugen übertreibt? Dann landet man in der Bürokratie, ihrem negativen Gegenspieler.

  • Entscheidungen können nicht mehr schnell getroffen werden, weil langatmige Prozesse eingehalten werden müssen.
  • Die Eigenverantwortung sinkt. Wenn man sich an den Prozess hält, kann man ja nichts falsch machen. Mitdenken ist unerwünscht.
  • Das führt aber auch dazu, dass Fehler nicht zugegeben werden. Sie existieren eigentlich gar nicht. Und wenn doch, dann war jemand anders schuld. Zur Not der Prozess.
  • Die Definition of READY ist so hart formuliert, dass es eigentlich kein Ticket mehr in einen Sprint schaffen kann. Negotiable ade!
  • Dadurch entsteht auch wieder Verschwendung, weil zu viel Arbeit in die Spezifikation und zu wenig Arbeit in das Schaffen von Wert gesteckt werden.
  • Das Team redet nicht mehr miteinander, Tickets werden hin und her geschubst, Konzepte und Tasks „über die Mauer geworfen“. Interdisziplinäre Teams, die gemeinsam auf ein Ziel hinarbeiten weichen Spezialisten, die nur ihr To Do vor Augen haben.


Und was passiert, wenn man es mit Individuen und Interaktionen übertreibt? Dann lebt man in einer Gruppen-Kuscheln-Kultur.

  • Entscheidungen können nicht mehr schnell getroffen werden, weil alles ausdiskutiert werden muss und jeder mit dem Ergebnis zufrieden sein muss.
  • Persönliche Befindlichkeiten nehmen überhand. Warum soll ich zurückstecken, wenn die andern es nicht tun?
  • Konflikte werden nicht ausgetragen, sondern unter den Teppich gekehrt, weil wir uns doch alle so liebhaben und so gut verstehen. Wer will schon die Stimmung vermiesen?
  • Abstimmungen finden zwischen Tür und Angel statt. Dokumentation? Wozu? Haben wir uns darauf geeinigt, dass wir sowas machen? Hat doch keiner Bock drauf!


2. Wertepaar: „Funktionierende Software“ und „umfassende Dokumentation“

Das Agile Manifest sagt: Funktionierende Software ist wichtiger als umfassende Dokumentation.
Was bedeutet das? Eine gute Dokumentation ist wichtig, denn sie spart Zeit. Gerade im agilen Umfeld, wo Features erstmal nur als Minimal Viable Product (MVP) ausgeliefert und ständig verbessert werden, ist es wichtig zu wissen, welcher Umfang aktuell im Produkt enthalten ist. Wenn man das nicht irgendwo strukturiert nachlesen kann, muss man jedes Mal, wenn das Feature erweitert werden soll, über Reverse Engineering das Feature wieder neu erfassen. Oder man muss sich an einen Entwickler wenden, der dann im Code nachschaut.

Wenn dann auch der Code nicht dokumentiert ist, dann muss der Entwickler sich intensiv in die Funktionen einarbeiten, um eine Aussage darüber treffen zu können. Und wenn dann die tatsächliche Umsetzung ansteht, muss sich der nächste Entwickler wieder einarbeiten, um diese vornehmen zu können.

Allerdings schafft Dokumentation dem Kunden keinen direkten Wert. Lauffähige Software hingegen schon, denn neue Features bringen neuen Nutzen und binden somit die Kunden an das Produkt. Zum Sprint-Ende ist es die dringendere Aufgabe, Bugs im Feature zu fixen, anstatt die Dokumentation fertigzustellen. Wohlgemerkt: Dringender!

Gerade beim Framework Scrum wird oft angemerkt, dass die Auslastung der Team-Mitglieder innerhalb des Sprints schwanken kann und Leerlauf entsteht. Dieser Leerlauf kann aber beispielsweise genutzt werden, um die Dokumentation der Features aus dem letzten Sprint zu erweitern. Das erfordert Disziplin, die aber Grundvoraussetzung in allen agilen Vorgehensweisen ist.

Umfassende Dokumentation
Besonderes Augenmerk sollte hierbei das Attribut „umfassend“ erhalten. Dokumentation zu erstellen ist zeitaufwendig. Sie zu pflegen und aktuell zu halten, noch mehr. Daher sollte man hier sehr darauf achten, welche Bereiche man intensiver dokumentiert und welche Dokumentationsarten man verwendet. Kombiniert man diesen Wert zum Beispiel mit dem Prinzip „Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.“, so ergibt sich daraus automatisch, dass gut geschriebener Code hier die absolute Basis ist.

Spätestens bei der Übergabe eines Tickets an den Tester muss außerdem klar definiert sein, wie das Feature funktionieren soll, sonst ist eine Qualitätssicherung unmöglich. Zusätzlich spielt im agilen Kontext auch die Testautomatisierung eine große Rolle. Allein durch die vorhandenen Testbeschreibungen ist die Software in ihrer Funktionsweise bereits dokumentiert.

Einzelne Test-Cases ergeben aber leider noch kein zusammenhängendes Bild. Das wird aber benötigt, um beispielsweise neue Teammitglieder einzuarbeiten oder mit den Stakeholdern neue Features zu besprechen. Daher ist es wichtig, die visuellen Artefakte aus der Anforderungsspezifikation ebenfalls in die Dokumentation zu überführen und aktuell zu halten. Damit sind gemeint:

  • Wireframes
  • Ablaufdiagramme
  • Systemschaubilder

Eine aussagekräftige Dokumentation ist also auch im agilen Kontext wichtig, allerdings sollte man sich auf die relevanten Aspekte beschränken. Wie bei der Testautomatisierung gilt es, jederzeit den Kosten-Nutzen-Faktor vor Augen zu haben. Schauen wir also wieder auf das Wertequadrat.

Ausgewogenes Verhältnis
Auf der Basis-Linie ist noch alles gut, im agilen Umfeld sollte man sich jedoch mehr im linken Bereich aufhalten.

 

Was passiert, wenn man es mit der Dokumentation übertreibt? Dann leitet man plötzlich ein Archivariat:

  • Die Entwicklungsgeschwindigkeit wird gebremst, weil ein Feature erst DONE ist, wenn es vollständig dokumentiert ist.
  • Eine vollständige Dokumentation erzeugt sehr hohen Verwaltungsaufwand, um sie immer aktuell zu halten.
  • Es besteht die Gefahr, dass sich alle auf die Doku verlassen und weniger miteinander kommunizieren.


Aber was passiert, wenn man zu wenig dokumentiert und nur noch auf funktionierende Software setzt? Man landet in der Adhoc-Programmierung:

  • Die Software ist schlecht wartbar, da man den Code nicht mehr versteht.
  • Entscheidungen, sowohl in der Architektur als auch in den Anforderungen, sind schlecht nachvollziehbar.
  • Die Software kann schlecht getestet werden, wenn niemand weiß, wie sie funktionieren soll.
  • Das Risiko bei Deployments steigt dadurch erheblich an.
  • Es entsteht Inselwissen: „Das kann nur XYZ machen, der kennt sich als Einziger damit aus.“


Lesen Sie im nächsten Blogbeitrag am 10. Mai die Fortsetzung zu den agilen Werten.

Die Gastautorin:
Sabine Kunigowski
Senior IT Specialist beim Cassini
Schwesterunternehmen Aleri Solutions
agile(@)no-spam.cassini.de