Abenteuer in SAFe - Wer den Kunden findet, kann ihn behalten!

Dass ich in einem Unternehmen arbeite, in dem seit nun gut einem Jahr das Scaled Agile Framework - kurz SAFe - eingesetzt wird, habe ich bereits erwähnt, oder? Heute geht es um Anforderungen und die Rolle des Kunden, so wie ich sie in meiner täglichen Arbeit mit und in SAFe erlebe!

Agil funktioniert durch Nähe zum Kunden und ständiges Feedback

Die Idee von Agilität wird gerade dadurch interessant und funktioniert in vielen Fällen besser als andere Vorgehensweisen, weil der Kunde für die Entwicklung eines Produktes nicht nur punktuell, sondern permanent eingebunden wird - er kann und muss präsent sein und steuern, indem er seine Anforderungen und sein Feedback zur Lösung sehr regelmäßig an das Entwicklerteam zurück spielt. So kann am Ende das richtige, bestmögliche Produkt (im Rahmen von Zeit und Budget) erstellt werden.

Im Scaled Agile Framework gibt es eine Übersicht über Rollen und Bereiche im sogenannten “Big Picture”. SAFe ist per Definition nicht nur pure Agilität, es ist auch noch größere Agilität als anderswo, weil skaliert. Das Element Kunde ist aber leider nicht zu sehen (es wurde quasi “aus-skaliert”) - es existieren Proxy-Kunden in Form von Product Owner und Product Manager, allerdings spielt der Kunde im Rahmenwerk zumindest nicht so eine gewichtige Rolle, dass man ihn auf das große Übersichtsbild setzen müsste. Das ist wahrscheinlich der Entstehung von SAFe geschuldet: In dem Unternehmen, für das es ursprünglich entworfen wurde, war der Kunde leider auch schon aus dem Fokus geraten…

Fehlender Kunde? Na und, das haben wir vorher doch auch schon hingekriegt!

Warum ist der fehlende Bezug zum Kunden ein Problem, an dem ich mich störe? Ganz einfach: Der Kunde soll das Produkt nutzen, er soll seine Anforderungen umgesetzt bekommen und soll ebenso deutlich sagen, was er nicht möchte. In einem Unternehmen, dass bereits vorher vom Kunden abstrahiert hat und dessen (Software-)Entwicklung eher durch Change Requests als durch echte Anforderungen getrieben ist, wird es sehr schwer, die agile Idee zu installieren. Change Requests “kennen” die aktuelle Lösung eines Problems und wollen diese verändern. Oder sie wollen ein bestehendes System um eine neue Funktionalität erweitern.

Die Lösung ist die Lösung

Hierbei wird nicht selten eine Anforderung als gewünschte Lösung beschrieben. Der Anforderungssteller glaubt zu wissen, welches die beste Umsetzung für seine Anfrage ist und setzt sich zu wenig mit dem Grund seines Änderungswunsches auseinander. Gerade das kann aber zu erstaunlichen und innovativen Lösungen führen. Wenn er dem Entwicklungsteam verdeutlichen kann, was er will und warum er es will (“Was will ich mit der neuen Funktionalität erreichen?”), kann das Team eine effiziente und intuitive Lösung suchen, anstatt einfach nur einen Knopf an einer bestimmten Stelle im Menü einzufügen (Obwohl das natürlich auch die richtige Lösung sein kann!).

Aber ist das nun ein spezifisches Problem von SAFe? Nein. Es ist eine generelle Herausforderung beim Umstieg auf ein agileres Vorgehen bei der Entwicklung von Lösungen.

SAFe macht es aber leichter, einen klassischen CR-Prozess beizubehalten: Die verschiedenen Ebenen und Rollen fordern für jede Anforderungen einen bestimmten Basisprozess - eine Anforderung geht im Framework einen langen Weg, bis sie beim Entwicklungsteam ankommt. Zusätzlich taucht das Wort Anforderung nirgenwo allzu offen auf, schließlich hat sich der Erfinder von SAFe sehr genau mit dem klassischen und dem agilen Requirements Engineering auseinander gesetzt und will hier Bedeutungskonflikte vermeiden. Das finde ich grundsätzlich gut, würde es nicht bei Worthülsen wir Epic und Feature genauso zu Problemen mit der Definition kommen.

Das Framework ist nie das Problem

SAFe ist ein Framework und muss von Firmen implementiert werden. Ein Rahmenwerk gibt per Definition nur einen Rahmen. Und egal welches Framework nicht zu funktionieren scheint, ist es in der Realität doch zu einem großen Teil das implementierende Unternehmen, welches das Problem ist. Das gilt für SAFe genauso wie für “unskalierte” Ansätze wir Scrum oder XP. Bei SAFe habe ich allerdings allzu oft das Gefühl, dass es uns leicht gemacht wird, in viele Fallen zu tappen und anschließend zu glauben, dass das ganze agile Zeug auch nicht funktioniert.

Immerhin entwickelt sich das SAFe-Framework weiter und die Autoren lernen dazu: In der kommenden Version 4.0 taucht erstmals der Kunde auf. Leider an dem Punkt im “Big Picture”, der am weitesten von Product Owner und Entwicklungsteam entfernt ist…