Das Ziel muss definiert sein
Bei jedem Projekt oder Produkt muss zu Beginn klar definiert werden, welches Problem gelöst wird. Wichtig ist, dass das Ziel nicht mit der Lösung verwechselt wird.
Nach der Zieldefinition sind drei Faktoren festzulegen: Ressourcen (Budget, Personal), Zeit und Umfang.
Zeit und Ressourcen bilden einen Pol, der Umfang den Gegenpol. Es gilt zu bestimmen, welcher Pol fixiert und welcher flexibel oder geschätzt wird.
Agile und klassische IT-Dienstleistung
Als IT-Dienstleister stellt sich bei der Anbahnung eines neuen Projekts stets die Frage: Welches Vorgehen passt am besten? Sobald das Setup definiert ist, klärt sich die Frage meist von selbst.
Ein klassisches Setup liegt vor, wenn der Umfang feststeht (oft durch Lasten- und Pflichtenheft). Darauf basierend schätzt man Ressourcen und Zeit. Methodisch kommen hier Wasserfallmodell oder V-Modell zum Einsatz. Ein agiles Mindset und dessen Methoden eignen sich hier nicht.
Ein agiles Setup besteht, wenn Zeitraum und Ressourcen fix sind, der Umfang jedoch flexibel. Das Wasserfallmodell stößt hier an Grenzen; agile Methoden sind besser geeignet. Durch iteratives und inkrementelles Vorgehen nähert man sich schrittweise einer passenden Lösung.
Was ist das Risiko in der agilen Dienstleistung?
Ein Auftraggeber sucht normalerweise eine Lösung für ein Problem. Bevor er einen Dienstleister beauftragt, sucht er selbst nach einer Lösung. Ist er von dieser überzeugt, benötigt er nur noch jemanden, der sie umsetzt, und das Projekt kann starten.
Die Realität ist oft anders. Das Problem ist meist komplex, und die Lösung liegt nur ansatzweise vor. Wie man ein komplexes Problem löst, zeigt sich oft erst beim Ausprobieren der Ansätze.
In einem klassischen Setup, bei dem ein Pflichtenheft abgearbeitet wird und Zeit- und Ressourcenschätzungen genau eingehalten werden müssen, stellt sich bei neuen Erkenntnissen die Frage: Handelt es sich um einen Change-Request? Je nach Auswirkung auf Erfolg und Schätzung des Projekts entsteht schnell eine Diskussion mit dem Auftraggeber über die Kostenübernahme.
In einem agilen Setup, bei dem der Dienstleister mit der verfügbaren Zeit möglichst nahe an die optimale Lösung kommen muss, lautet die Frage bei neuen Erkenntnissen: Welcher nächste Schritt bringt uns der Lösung näher? Tritt dies zu oft auf, besteht für den Auftraggeber die Gefahr, am Ende der Ressourcen keine Lösung zu erhalten.
Für Auftraggeber ist das größte Risiko im agilen Setup das Vertrauen in den Dienstleister. Sie müssen darauf vertrauen, dass der Dienstleister ihr Problem in der gegebenen Zeit und mit den vorhandenen Ressourcen löst. Dieses Risiko besteht auch im klassischen Setup, ist dort aber in der Schätzung des Dienstleisters besser verborgen.
Wie funktioniert Agilität in der Dienstleistung?
Ein agiles Entwicklungsvorgehen funktioniert unter den gleichen Voraussetzungen. Der Auftraggeber und der Dienstleister vereinbaren ein Setup, dass dieses ermöglicht. Der Auftraggeber hat das Vertrauen in den Dienstleister, dass dieser verantwortungsvoll und zielführend mit der Zeit und den Ressourcen umgeht.
Das Entwicklungsteam zahlt das Vertrauen mit Leistungen und Transparenz zurück. Unter der Prämisse des „Agilen Manifestes“ haben sich Vorgehensweisen wie SCRUM und KANBAN über die Jahre etabliert. Die Methode ist nicht entscheidend, es geht um das Mindset, welches beim Entwicklungsteam vorhanden sein muss.
Bei 8tronix verwenden wir je nachdem, was gerade besser zum Auftrag und der Laufzeit passt, eines der beiden Vorgehen. Egal welches Agile Framework wir nutzen, für uns steht immer die Feedbackschleife zu unserem Auftraggeber im Mittelpunkt. (Wir fordern dies sogar in klassischen Setups ein). Auf wöchentlicher oder zweiwöchentlicher Basis präsentieren wir unsere Fortschritte und sprechen alles an, was noch nicht im direkten Austausch vorab geklärt wurde. In einem agilem Setup in der Dienstleistung sind später entstandene Anforderungen kein Change-Request-Verwaltungsakt mehr.
Praxisbeispiel bei unserem Kunden ESYLUX
Um zu zeigen, wie ein agiles Projekt mit 8tronix aussehen kann, betrachten wir ein abgeschlossenes Projekt. Unser Auftraggeber ESYLUX wollte folgendes Problem lösen: „In der Entwicklung eines ihrer Geräte werden Signale versendet, deren Überprüfung aufwendig und fehleranfällig ist.“ Im Daily Doing kam bereits eine proprietäre Lösung zum Einsatz, die als Ausgangspunkt diente, um ein eigenes Gerät zu entwickeln. Dieses sollte die Arbeit interner Entwickler erleichtern und den Start für Testautomatisierung sowie Hardware-in-the-Loop (HIL) Tests ermöglichen.
Wie war das Projektsetup?
ESYLUX gab ein Budget und einen Lösungszeitraum von zwei bis drei Monaten vor. Die Lösung war offen. Wir (8tronix) planten mit zwei Entwicklern und einem Projektmanager. So konnten wir direkt starten und Lösungsmöglichkeiten evaluieren.
In der Vergangenheit hatten wir bereits ein kleines Projekt mit ESYLUX erfolgreich umgesetzt und daher das Vertrauen gewonnen.
Welche Methoden kamen zum Einsatz?
Im agilen Setup setzten wir Methoden aus dem agilen Umfeld ein. Zu Beginn starteten wir zusammen mit ESYLUX ein Storymapping. Damit schufen wir ein gemeinsames Verständnis und definierten Arbeitspakete. Aus Teilproblemen definierten wir einen Durchstich, der die proprietäre Lösung von ESYLUX ersetzen würde. Weitere Probleme verpackten wir in spätere Versionen, falls noch Zeit blieb.
Wir etablierten einen wöchentlichen Termin zum Fortschrittsaustausch, zur Besprechung größerer Themen und zur Entscheidungsfindung. Dieser orientierte sich am Review aus dem SCRUM-Prozess.
Die Entwickler arbeiteten hauptsächlich nach der KANBAN-Methode. Es gab ein priorisiertes Backlog. Während des Fortschritts definierten wir die nächsten Aufgaben zeitnah genauer. Im Fokus stand, das Problem effizient zu lösen und Feedback vom Auftraggeber zu erhalten.
Wie hätte das Projekt in einem klassischem Setup ausgesehen?
ESYLUX hätte aufgrund ihrer proprietären Lösung und ihres Know-hows definiert, wie sie das Problem lösen wollen. 8tronix hätte diese Idee geprüft und ein Angebot mit Zeit- und Ressourcenschätzung abgegeben. Vor Beginn der Bearbeitung wären vermutlich noch einige Details zu klären gewesen.
Diese Absprachen, vertraglichen Klärungen und Preisverhandlungen hätten vermutlich 2–3 Wochen der insgesamt 2–3 Monate in Anspruch genommen. Ob das gewünschte Ergebnis erreicht worden wäre, bleibt fraglich.
Konnten wir das Problem am Ende lösen?
Kurz gesagt: Ja.
Dank der klaren Aufgabenstellung und des Vertrauens von ESYLUX konnten wir unser Wissen zielgerichtet einsetzen. Am Ende entwickelten wir ein Produkt, das Arbeitsschritte um das Fünffache beschleunigte. Neben dem Durchstich lösten wir zwei weitere Versionen und legten den Grundstein für Hardware-in-the-Loop-Tests.
