Agil

In der IT gibt es bei den meisten Beteiligten die erschreckende Neigung, bei jeder sich bietenden Gelegenheit zu schauen, ob es für die anstehende Aufgabe nicht ein passendes Tool gibt, also eine schicke Applikation. Leider ist die Realität im Jahre 2015 sehr einfach: Es gibt für alles ein Applikation.

Es gab da doch den Satz mit dem Tool und so weiter

Den Satz mit dem Tool und das es nicht zwingend hilft kennt wohl jeder. Auch bei der Einführung neuer Prozesse sollte man ihn sich aber zu Herzen nehmen. Ich bin in meiner Organisation als ScrumMaster tätig, den neuen Prozess zur Erstellung von Software (richtig, Scrum eingebettet in das Scaled Agile Framework, kurz SAFe) haben wir vor nicht allzu langer Zeit eingeführt. Hier habe ich dank zahlreicher Vergleichsgruppen und vieler Experimente gelernt, dass der möglichst einfache Ansatz oftmals der Beste ist, um so etwas wie Scrum in einem Team einzuführen. Gerade in der Startphase eines neuen agilen Teams wird sehr viel probiert und verändert, als ScrumMaster möchte ich dabei, dass das Team viel interagiert und sich mit den Inhalten beschäftigt.

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.

Das Unternehmen, in dem ich als ScrumMaster arbeiten darf, hat seine Art Software zu entwickeln vor etwas mehr als einem Jahr von einem klassischen Wasserfallmodell hin zur Nutzung des Scaled Agile Framework (SAFe) umgestellt.

SAFe definiert verschiedene Ebenen an Verantwortung - sie sollen den Fluss einer Anforderung vom Groben ins ganz Feine und den umgekehrten Weg zur fertigen Softwarelösung in Unternehmen abbilden. Dieses sogennate “Big Picture” zeigt schon, dass SAFe natürlich bei all jenen Punkte sammeln möchte, die daran glauben, dass Agilität in “echten” Unternehmen (Stichwort Enterprise) nicht funktioniert, sondern nur in kleinen Software-Bastelbuden erfolgreich sein kann.