a
HomeAgile VorgehensweisenDie Grundwerte der Agilität

Die Grundwerte der Agilität

Eine bekannte agile Vorgehensweise nennt sich Scrum. Diese stammt ursprünglich aus der Softwareentwicklung, um diese zu beschleunigen. Im Jahr 2001 haben eine Reihe von Software Engineers das agile Manifest unterschrieben, welches danach auch im Internet veröffentlicht wurde.

Für mich sind dabei die dort aufgeführten vier Werte entscheidend:

  1. Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  2. Funktionierende Software mehr als umfassende Dokumentation
  3. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  4. Reagieren auf Veränderung mehr als das Befolgen eines Plans

Diese vier kurzen Aussagen haben es in sich und diese sind auch der Grund, warum einige Unternehmen an der Umsetzung  – beispielsweise von Scrum – scheitern. Scrum ist kein besonders großes Regelwerk, es ist also einfach zu verstehen, aber eben schwer in der Umsetzung.

Schauen wir auf den ersten Punkt: Die Aussage ist, dass der Mensch mit seinem Bedürfnis nach einer Änderung (beispielsweise in einer Software) an erster Stelle steht. Diese Grundidee findet sich z. B. auch in der agilen Vorgehensweise „Design Thinking“ wieder. Die Prozesse und Werkzeuge spielen eine untergeordnete Rolle. Diese sollen dabei unterstützen, optimal mit dem Auftraggeber zu kommunizieren. Diese sind aber kein Ersatz für direkte persönliche Interaktion.

2. Wenn du in der Softwareentwicklung tätig bist, dann kennst du das Problem. Entweder es ist unglaublich gut dokumentiert, was ein Software-Release können muss oder es ist so gut wie nichts schriftlich festgehalten worden. Beide Umstände sind keine gute Herangehensweise. Aber noch viel weniger gut wäre es, wenn man ausreichend dokumentiert hat, aber der Kunde entweder die Software nicht testen kann, weil diese nicht existiert oder aber zu viele Fehler, bzw. falsche Implementierungen enthält.

Deshalb ist es bei agiler Vorgehensweise erst einmal wichtig, dass die Software das kann, was der Kunde benötigt. Und vor allem muss das Ergebnis so sein, dass der Kunde das Ergebnis auch sehen kann. Erst danach folgt die Dokumentation. Deshalb wird beispielsweise bei Scrum während des Sprints oder kurz vor Sprint-Ende dokumentiert. Aber das auch nicht ausufernd.

In der dritten Aussage geht es um die Zusammenarbeit im Vergleich zur Vertragsverhandlung. Stelle dir vor du hast einen Vertrag mit einem Auftraggeber ausgehandelt. Dafür wurden einige Personentage in Anspruch genommen. Im Laufe der Softwareentwicklung stellt sich etwas heraus, was der Kunde benötigt, aber mit einem Blick in den Vertrag eigentlich unmöglich macht. Nun hättest du verschiedene Möglichkeiten, wie würdest du es angehen?

Meiner Meinung nach ist es für keine Seite angenehm, denn der Auftraggeber weiß schon, dass er laut Vertrag keinen Anspruch besitzt und du weißt, dass du ihn darauf „festnageln“ könntest. Aber wem hilft das? Letztendlich gehen beide Seiten mit einem schlechten Gefühl aus derartigen Gesprächen. Es ist also deutlich klüger schon darauf hinzuweisen, dass es so vereinbart wurde, aber gemeinsam eine Lösung gefunden wird.

Im vierten Wert geht es um das Klammern an einen Plan. Im klassischen Projektmanagement ist das nicht neu, es wird dort tagtäglich so gelebt. Planänderungen sind Ausnahmen und nicht so gerne gesehen. Wer agil Software entwickeln möchte und dabei auch noch einen Erfolg erwartet, muss sich von diesem starren Denkprozess befreien. In Scrum sind Planänderungen willkommen, denn diese zeigen, dass der Auftraggeber einen Schritt weiter auf seine Lösung zugegangen ist. Und am „Ende des Tages“ zählt die Kundenzufriedenheit und nicht ob wir die Pläne mehrfach geändert haben.

Teile bitte diesen Inhalt mit:
Bewerte bitte den Inhalt
Keine Kommentare.

Hinterlasse doch ein Kommentar