So bin ich auch zu der Fragestellung gekommen, was an agilen Methoden so neu ist, was ist der Unterschied? Warum funktioniert das so gut? Das beschäftigt mich im Moment und ich habe dazu auch schon einen Blog Eintrag geschrieben. Dort beschreibe ich auch, warum funktionsübergreifende Teams so gut "funktionieren". Ein wichtiger Aspekt in diesen Teams ist, dass man von allen Interessengruppen (insb. auch dem Kunden) regelmäßiges, kurzfristiges und direktes Feedback bekommt. Das habe ich in meinem Blog Eintrag schon als Continuous Feedback bezeichnet. Über diesen Punkt habe ich dann länger nachgedacht und festgestellt, dass viele agile Techniken direkt darauf ausgerichtet sind kurzfristige und kontinuierliche Rückmeldung über die Qualität der Arbeitsergebnisse zu bekommen. Wo findet kontinuierliche Rückmeldung in einem agilen Umfeld statt? Ein paar Beispiele:
Kontinuierliche Rückmeldung vom Kunden
Der Kunde ist in einem agilen Projekt idealerweise Teil des funktionsübergreifenden Teams. Auf diese Weise sieht er das Ergebnis nicht alle paar Wochen oder Tage (im besten Fall), sondern er kann den gesamten Entwicklungsprozess begleiten und aktiv beeinflussen. Er korrigiert unfertige Entwicklungsstände der Entwickler, anstatt auf das Deployment zu warten. Die Entwickler können auch fragen: "... meintest Du das so?" Dann zeigen sie dem Kunden die neue Maske, die geradeentwickelt wird. Das so eingesammelte direkte Feedback reduziert Aufwand und erhöht die fachliche Qualität der deployten Software in der Testumgebung.
Kontinuierliche Rückmeldung von den Entwicklerkollegen
Auch die direkten Entwickler-Kollegen geben sich andauernd Feedback in einem agilen Team. Dies geschieht z.B. beim Pair Programming, über das tägliche Stehmeeting oder in der Kaffee-Küche. Auch der Sachverhalt, das die Teams in einem Büro sitzen sollten, verbessert das Feeback der Kollegen untereinander. So wird die produktorientierte Qualität der Software erhöht, also der Teil der Software, den der Kunde meistens garnicht wahrnimmt. (Der Kunde hat kein Interesse daran, ob das Programm gut "deignt" ist. Er versteht nicht, dass es die Folgekosten und Entwicklungsgeschwindigkeit bei Änderungen beeinflusst.)
Kontinuierliche Rückmeldung über die objektiv messbare Qualität
In einer Continuous Integration Umgebung wird die Anwendung regelmäßig kompiliert, zusammengebaut, analysiert (statische Sicht auf den Code) und getestet (dynamische Sicht). Dabei wird im Idealfall mehrfach am Tag integriert. So hat man einen objektiven Qualitätsstand der Anwendung und kann beobachten, ob man objektiv betrachtet besser oder schlechter geworden ist. Man bekommt kontinuierlich Feedback über die wichtigste Messgröße: läuft meine Software?
Kontinuierliche Rückmeldung über den Nutzen der Software
In kurzen Releasezyklen, also z.B. alle vier Wochen, wird die Software in Produktion gegeben. Dadurch hält man zum einen die Menge der zu entwickelnden Funktionen überschaubar (Prinzip "Teile und Hersche"), zum anderen weiß man aber auch zeitnah, ob die Software wirklich den erhofften Nutzen bei den Anwendern erzielt. Man weiß also frühzeitig, ob man insgesamt auf dem richtigen Weg ist. Spart man wirklich wie erhofft Kosten durch die Prozessautomatisierung? Baut sich der Stau im Auftragseingang im Fachbereich ab? Diese Fragen beantworten sich früh, wenn alle vier Wochen eingeführt wird.
Das waren konkrete Beispiele für kontinuierliches Feedback in einem agilen Projekt. Es gibt bestimmt auch andere Beispiele. Ich wollte in dem Blog nur das Konzept näher bringen. Jetzt muss ich den Kreis nochmal zur Eingangsfrage schliessen. Die Frage war: was ist in agilen Vorgehensweisen so besonders Neues? Neben Konzepten wie Selbstregulation und Selbstorganisation könnte das beschriebene Konzept des Continuous Feedback eine übergeordnete Rolle spielen.
Bei Continuous Feedback geht es um die Ausrichtung des Teams auf kontinuierliche Rückmeldung über die Qualität der einzelnen Arbeitsergebnisse.
Dieser einzelne Punkt ist vielleicht ähnlich wichtig wie die Fähigkeit sich selbst zu organisieren, bzw. die kontinuierliche Rückmeldung stellt auch bei der Selbstorganisation ein wichtiges Grundkonzept dar. In diesem Sinne handelt es sich um ein Querschnittskonzept, dass in verschiedenen Einzelkonzepten "eingewoben" wird. Das ist vergleichbar mit einem Security Konzept für eine Software. Sicherheit kann man auch nicht an einer Stelle einbauen. Stattdessen werden alle Programmteile davon beeinflusst. Was für Security bezogen auf ein Software-System gilt, ist übertragbar auf das Prinzip der kontinuierlichen Rückmeldung in einem agil organisierten Projekt. Die einzelnen organisatorischen Elemente (bzw. agilen Techniken) werden jeweils mit Continuous Feedback versehen.
No comments:
Post a Comment