Zum Hauptinhalt springen

Auf die Plätze, fertig, los!

Ein Produkt oder Innovation agil entwickeln

Der Produktrahmen ist festgelegt und Sie haben einen Dienstleister oder Umsetzungspartner für Ihr Produkt gefunden? Dann sind Sie jetzt startklar und es kann in die tatsächliche Entwicklung des Produkts gehen!

Auch wenn Sie die Entwicklungsarbeit nicht selbst erbringen können, sollten Sie sich in dieser Phase keineswegs zurücklehnen, sondern weiterhin eine aktive Rolle einnehmen. Die zentrale Frage, um die es sich in diesem Abschnitt dreht: Wie stellt man sicher, dass die Zusammenarbeit mit dem Umsetzungspartner reibungslos verläuft und das Produkt erfolgreich entwickelt wird?

Behalten Sie die Verantwortung mit einer/einem Product Owner:in​

Spätestens zu Beginn der Entwicklungsphase des Produkts sollten Sie eine Person aus Ihrem Team als Product Owner:in festlegen. Product Owner sind ein fester Bestandteil des Projektteams und maßgeblich für den Erfolg des Projektes verantwortlich. Es ist daher entscheidend, dass diese Rolle auch durch eine in der entsprechenden Verwaltung tätige Person selbst ausgeführt wird. Idealerweise findet sich eine Person, die Erfahrungen mit digitaler Produktentwicklung hat, mindestens aber eine gewisse Leidenschaft sowie Interesse für digitale Anwendungen mitbringt. Vertiefte technische Kenntnisse sind für die Rolle hilfreich, aber nicht unbedingt notwendig, da es ja gerade darum geht, das Produkt mit der Nutzer:innenbrille zu betrachten. Wichtiger sind die grundsätzliche Bereitschaft und Kapazitäten, sich auf die – zeitintensive, aber sehr gewinnbringende – agile Projektarbeit einzulassen.

Finden Sie kurze Arbeitswege zu Ihrem Dienstleister​

Sobald die tatsächliche Entwicklungsarbeit beginnt, setzt häufig die Denkweise ein: „Jetzt sind die Programmier:innen dran und wir müssen erstmal warten, bis sie was zu zeigen haben.“ Doch nur weil Sie nicht direkt entwickeln, sollten Sie sich nicht aus dieser Phase herausziehen, denn Sie sind ja weiterhin der Kapitän, der das Schiff noch steuern soll.

Konkret heißt das: Bleiben Sie auch während der Entwicklungsphase an Bord. Pflegen Sie einen engen Austausch mit der Crew, einschließlich der externen Dienstleister:innen. Üblicherweise arbeiten agile Teams und Tech-Agenturen in "Sprints", die eine vordefinierte Dauer haben (oft zwischen einer Woche und einem Monat). Sie können entsprechend eine Vereinbarung mit Ihrem Dienstleister eingehen, dass Sie zum Ende eines Sprints ein „Check-In“ durchführen, um sich über den aktuellen Stand des Projekts auszutauschen. Hierbei geht es keineswegs um ein Mikromanagement des Projekts, sondern darum, dass beide Seiten kurze Arbeitswege und einen regelmäßigen Austausch zueinander haben, um wertvolles Feedback einzuholen und erforderliche Anpassungen schnell umzusetzen: Nur so können Sie regelmäßig sicherstellen, dass das Produkt auch wirklich entlang der Nutzer:innenbedarfe entwickelt wird und bei Bedarf ein frühzeitiges Gegenlenken möglich ist.

Nutzen Sie die richtigen Tools, um auf dem Laufenden zu bleiben​

Regelmäßige Treffen mit Ihrem Dienstleister sind nicht der einzige Weg für Sie, um über die Entwicklung Ihres Produkts informiert zu bleiben. Entwicklungsteams nutzen in der Regel digitale Tools, um Ihre Entwicklungsarbeit in einzelnen Aufgaben abzubilden (vgl. “Kanban Boards”). Diese werden dann priorisiert und systematisch angegangen. Meistens wird auch der aktuelle Status der Aufgabe angezeigt, damit alle im Projekt sehen können, ob aktuell daran gearbeitet wird.

Machen Sie sich diese agile Herangehensweise auch für die Entwicklung Ihres Produkts zu eigen. Versuchen Sie den Überblick zu behalten, wo sich das Projekt gerade befindet und welche Aufgaben aktuell priorisiert werden. Es gibt diverse digitale Tools, die für das Verfolgen von Entwicklungsarbeit geeignet sind. Ihr Dienstleister sollte mit solchen Tools vertraut sein und kann Ihnen sicherlich eine Empfehlung geben, was sich in Ihrem Fall am besten anbietet.

Lassen Sie sich regelmäßig Demos zeigen!​

Ein Grundsatz der agilen Entwicklung ist das iterative Arbeiten in zeitlich getakteten Sprints; deren Ergebnisse direkt in einen funktionsfähigen Prototypen fließen. Das bedeutet für Sie im Grunde, dass es eine unfertige Version des Produkts gibt, die schrittweise mit neuen Features oder Verbesserungen ergänzt wird. Und als Verantwortliche:r für das Produkt können und sollten Sie diesen Fortschritt miterleben.

Auch hier gilt: Bleiben Sie nah am Produkt und lassen Sie sich statt eines Zwischenberichts oder einer Präsentation über die gelungene Arbeit der vergangenen Wochen oder Monate lieber eine Demonstration des Prototypen zeigen! Entweder wird Ihnen vom Dienstleister der aktuelle Arbeitsstand gezeigt oder Sie erhalten idealerweise einen direkten Zugang zu einer Testversion des Produkts, wo Sie die Features selbst testen können.

Mit solchen Demos können Sie nicht nur den Fortschritt in der Entwicklung genauer betrachten, sondern – was viel wichtiger ist – auch erkennen, wann die Entwicklungsarbeit von Ihren Erwartungen abweicht und frühzeitig gegensteuern.

Testen Sie frühzeitig Ihr Produkt – auch außerhalb des Produktteams​

Unabhängig davon, um welche Art oder welchen Umfang von IT-Anwendung es sich handelt, gilt: Starten Sie Ihre ersten Testläufe so früh wie möglich! Je früher und öfter IT-Entwicklungen im Anwendungskontext erprobt werden, desto besser kann wertvolles Feedback von den Nutzenden gesammelt werden.

Keine Sorge – Sie brauchen hierfür weder einen perfekten Prototypen noch eine breite Öffentlichkeit: Sie können die Nutzer:innentests auch mit einer kleinen Gruppe von Nutzer:innen z. B. in Form eines sogenannten „Klick-Dummies“ durchführen, der noch nicht alle Funktionen enthält. Damit können die Nutzenden die Anwendung prototypisch erfahren und Feedback zur Bedienbarkeit des Produkts geben. Mit diesem Feedback können Sie wiederum ihr Produkt strategisch weiterentwickeln und mögliche Hürden frühzeitig identifizieren.

Die agile Entwicklung sieht vor, Software so früh wie möglich zu pilotieren, selbst wenn die Entwicklung noch nicht abgeschlossen ist. So kann es immer wieder mal vorkommen, dass eine Software aufgrund von Feedback überarbeitet werden muss. Das ist völlig normal und kein Zeichen dafür, dass etwas schiefgelaufen ist – im Gegenteil: es ist immer besser, dieses Feedback noch in der Test- oder Pilotphase einzuholen, statt nach der Veröffentlichung des finalen Produkts.