Agile entwickeln mit festen Budgets | K&C Software München

Agile entwickeln mit festen Budgets | K&C Software München

Kostenkontrolle als Schlüssel zu erfolgreicher agiler Software-Entwicklung

Im Zeitalter der digitalen Transformation ist die schnelle Umsetzung von Business Cases der Schlüssel zum Erfolg. Häufig hat derjenige die Nase vorn, der die höchste Geschwindigkeit an den Tag legt. Leider existiert für die meisten Unternehmer und Manager einen Faktor, der hierbei Grenzen setzt – das Budget.

Selbst in einer agilen Welt, in der sich die Anforderungen häufig ändern und die technische Realisierung fortlaufend an neue Gegebenheiten angepasst wird, lautet die zentrale Fragestellung von Managern an ihre Product Owner: „Wie hoch werden die Kosten sein?“

Fundierte Entscheidungen lassen sich tatsächlich nur dann treffen, wenn die Kosten einer Lösung bekannt sind.

Die Antwort der IT zur Kostenfrage wird in der Regel lauten: „Beschreiben Sie die Anforderungen“. Es folgt eine langwierige, teure Kalkulation, die zwei Wochen in Anspruch nimmt. Schon befinden Sie sich wieder beim klassischen Wasserfallmodell. Im vergangenen Jahr wurden weniger als ein Drittel der IT-Projekte frist- und budgetgerecht abgeschlossen. Laut einer McKinsey-Studie, die in Zusammenarbeit mit der Universität Oxford durchgeführt wurde, wird in mehr als der Hälfte aller IT-Projekte das Budget um durchschnittlich 45 Prozent überschritten.

Bei K&C werden wir sowohl von etablierten Großunternehmen als auch von Start-ups häufig mit Anfragen dieser Art konfrontiert. Oftmals besteht zwar eine klare Vision, die Anforderungen sind jedoch nicht genau definiert. Selbstverständlich ist zudem der Kosten- und Zeitrahmen begrenzt. Trotz allem muss im Rahmen jeder Business-Entscheidung sowohl der Aufwand als auch die voraussichtliche Implementierungszeit berücksichtigt werden. Gleiches gilt für die Gesamtrisiken des IT-Projekts.

Glücklicherweise erfordern die meisten IT-Projekte weniger Kreativität, als in IT-Expertenkreisen angenommen wird. Bei einer korrekten Herangehensweise sind zahlreiche Vorhaben eher als Handarbeit zu bezeichnen. Dank etablierter Methoden ist bereits im Vorfeld bekannt, auf welche Weise Features implementiert werden müssen und welcher Aufwand hierfür entsteht.

Aus diesem Grund haben wir einen integrierten Vertriebs- und Projektmanagementprozess entwickelt. Wir nennen die Vorgehensweise „Controlled Agile“.

Der Prozess ermöglicht es, schnell auf Business-Anforderungen zu reagieren und gleichzeitig agil zu bleiben. Ein Beispiel: Vor einigen Wochen erhielten wir eine Anfrage. Nennen wir den Interessenten aus Gründen des Datenschutzes Bastian. Er kommt aus dem Maschinenbau und vertreibt äußerst spezifische Betriebsstoffe. Sein Gedanke ist es, einen Marktplatz zu realisieren, auf dem Händler diese Artikel präsentieren können.

0. Vollständige Agilität

Bastian hat in der Vergangenheit sehr unterschiedliche Erfahrung mit Software-Anbietern gemacht. Beispielsweise hatte er eine hervorragende Idee für eine App. Er bevorzugte einen Festpreis, da die Finanzierung über sein äußerst begrenztes Privatvermögen erfolgen sollte. Ein Anbieter unterbreitete ihm einen sehr verlockenden Preis. Es verging einige Zeit, bis er das Ergebnis zu Gesicht bekam – und er war bitter enttäuscht. Die gesamte App war aus Kundensicht nutzlos. Es folgten Ausreden wie „Sie haben uns nicht gesagt, dass Sie eine „Passwort-Vergessen-Funktion“ benötigen. Dieser sogenannte Change Request (CR) sollte nach Aussage des Anbieters drei weitere Tage kosten. Es folgten mehrere Aktionen dieser Art.

Bastian nahm sich vor, beim nächsten Projekt den agilen Ansatz zu testen. Hierbei war das Budget anfangs nicht definiert, da die Anforderungen an die Lernkurve innerhalb des Projekts angepasst wurden. Es wurden Sprints und tägliche Telefonkonferenzen vereinbart, um die Fortschritte zu diskutieren. Erneut verging die Zeit. Letztlich wurde das Budget so weit überschritten, dass Bastian das Projekt aufgeben musste.

Verständlicherweise war Bastian skeptisch, als wir ihm unsere Vorgehensweise (Controlled Agile) erläuterten.

Jede Investitionsentscheidung muss auf der Grundlage des für die Umsetzung erforderlichen Zeit- und Arbeitsaufwands getroffen werden.

1. Business-Plan

Die Ausgangslage stellt sich wie folgt dar: Bastian kennt den Markt. Er weiß, welche Umsatzpotenziale vorhanden sind und wie sich Marketingbudgets darstellen sollten. Ihm ist jedoch nicht bekannt, wie hoch die Kosten für die Implementierung sein werden. Wird sein Eigenkapital ausreichen? Benötigt er Investoren? Wie lange wird die Implementierung dauern? Wann ist die Gewinnschwelle erreicht?

Darüber hinaus benötigt der IT Product Owner Klarheit darüber, welcher Faktor wichtiger ist: Ist eine schnelle Markteinführung mit einer geringen Nutzeranzahl gefordert oder sind von Anfang an Spitzen hinsichtlich der Useranzahl zu erwarten? Präsentieren wir die Lösung zunächst im kleinen Kreis oder stellen wir sie direkt dem gesamten Markt zur Verfügung?

Die Implementierungsstrategie ist ein bedeutsamer Bestandteil eines jeden Business-Plans. Im Zeitalter der digitalen Transformation werden die IT-Implementierungs- und Infrastrukturstrategie hierbei sehr oft gemeinsam betrachtet.

Für jedes erfolgskritische Projekt ist Transparenz hinsichtlich der Kosten, der erforderlichen Ressourcen und der Terminplanung eine wesentliche Entscheidungsgrundlage. Dies gilt für Start-ups und etablierte Unternehmen gleichermaßen.

Um die beste Implementierungsstrategie zu identifizieren und eine solide Basis für die Umsetzung zu schaffen, müssen wir zunächst ein Verständnis für die Unternehmensziele entwickeln.

Wir befragen daher im Rahmen eines Workshops sämtliche Stakeholder hinsichtlich ihrer Vision. Wir klären zudem, wie die Probleme ihrer Kunden gelöst werden sollen. Durch diesen kundenorientierten Ansatz stellen wir sicher, dass nur Features implementiert werden, die für das MVP (Minimum Viable Product) relevant sind. Unnötige Kosten lassen sich hierdurch vermeiden.

Durch das Verständnis der Vision und des Business Case wird eine solide Basis für die Implementierung geschaffen.

2. Product Backlog (1-4 Stunden)

Aus High-Level-Features ergeben sich häufig direkt zahlreiche Standard-Features oder Epics. So erfordert der User Login beispielsweise eine Reihe von Standardfunktionen, um DSGVO-Konformität herzustellen. Wir agieren stets anhand von Best Practices, sodass wir oftmals von Beginn an definieren können, welche Funktionen für ein voll funktionsfähige Anwendung erforderlich sind.

Die meisten Business-Anwender haben Schwierigkeiten mit dieser Denkweise. Vergleichbar ist dies mit dem Kauf eines Autos. Der Kunde wird Ihnen vermutlich die gewünschte Farbe und Leistung des Motors mitteilen. Er wird jedoch kaum erwähnen, dass er auch einen Schlüssel braucht. Gleiches gilt in der Software-Entwicklung: Zu oft unterstützen IT-Unternehmen ihre Kunden nicht bei der Definition eines sinnvollen Gesamtpakets.

Auf Basis dieser Erfahrungswerte bereiten wir gemeinsam mit unseren Kunden Wireframes auf, um die gesamte Applikation zu beschreiben. Auf diese Weise ist eine hohe Kundenzufriedenheit gewährleistet.

Kundenerfahrung umfasst weitaus mehr als Benutzererfahrung. Während die Benutzererfahrung nur aussagt, dass die Funktion Spaß macht und einfach zu bedienen ist, führt eine positive Kundenerfahrung zu bestimmten Aktionen, die das Geschäft beleben. Ein klassisches Beispiel ist das Anklicken des „Kaufen-Buttons“.

Die ursprüngliche Anforderung von Bastian war simpel: „Ich brauche einen Online-Marktplatz.“ Wir zeigten auf, dass hierfür eine DSGVO-konforme Benutzerauthentifizierung, die Integration eines Payment-Anbieters mit KYC-Funktionalität („Know your customer“) sowie ein ansprechendes Design erforderlich sind. Dank Bastians fundiertem Wissen hinsichtlich der Bedürfnisse seiner Kunden war es möglich, einen äußerst effizienten Prozess zu realisieren. Dieser ermöglichte es den Anwendern, die benötigten Produkte mit nur wenigen Klicks zu finden. Dies stellt künftig einen Wettbewerbsvorteil für ihn dar.

Trotz offensichtlicher Zufriedenheit mit der zukünftigen Anwendung brennt Bastian eine Frage unter den Nägeln: „Wie viel wird das Kosten?“

Unsere Antwort: „Wir müssen nur noch einige Randbedingungen klären.“

Für Business-Anwender steht der Kundennutzen im Vordergrund. Mit Best Practices kann ein MVP so gestaltet werden, dass ein positives Kundenerlebnis sichergestellt ist.

3. Erster Entwurf der Architektur (1-4 Stunden)

Bei der Definition von Funktionen greifen wir auf Best Practices zurück. Dies gilt auch für die Ausgestaltung der Architektur.

Zwar ist jedes Unternehmen einzigartig, die technische Basis ähnelt sich jedoch oftmals. Aus betriebswirtschaftlicher Sicht ist es beispielsweise kein großer Unterschied, ob wir einen Marktplatz für Rechtsberatungsleistungen oder für virtuelle Waren im Gaming-Bereich einrichten.

Entsprechende Anwendungen können oftmals unter Verwendung bestehender Architekturvorlagen, welche auf Best Practices basieren, realisiert werden. Eine Suchfunktion ist stets eine Suchfunktion – egal ob auf einem Online-Marktplatz, in einem Shop oder einem Collaboration-Tool. Gleiches gilt für Formulare, Tabellen, Menüs und andere Elemente. Die Komplexität kann jedoch unterschiedlich ausgeprägt sein. Ein Formular auf einem Online-Marktplatz kann etwa Galerien, Videos und mehr enthalten, während andere Formulare schlicht textbasiert sind.

K&C verfügt über eine Wissensdatenbank, in der sämtliche Best Practices hinsichtlich der Architektur dokumentiert sind. In einem technischen Workshop stellen wir eine Verbindung zwischen den gewünschten Epics und den bestehenden Vorlagen her, indem wir gezielt Fragen stellen.

Für einige Anwendungen eignet sich ein einfaches CMS, das auf Performance und SEO ausgelegt ist, am besten. Andere Anwendungen erfordern möglicherweise ein komplexes Genehmigungssystem für die Erstellung von Content.

In den meisten Fällen empfehlen wir ein „Cloud Ready Design“, das eine einfache Skalierung und Implementierung der Anwendung in jeder Umgebung ermöglicht – egal ob intern oder extern.

Bastians Ziele sind ambitioniert. Ihm ist bewusst, dass die Anwendung in der heutigen Zeit rund um die Uhr verfügbar sein und sämtliche Nachfragespitzen abdecken können muss. Also einigen wir uns darauf, mit einer externen Cloud-Lösung ins Rennen zu gehen.

Der Business Case definiert auch den Rahmen für die Umsetzung. Ist eine einfache Lösung ausreichend oder soll die Grundlage für zukünftige Erweiterungen geschaffen werden?

4. Erste Kostenschätzung (0,5-1 Stunde)

Nachdem klar ist, welche Technologien zum Einsatz kommen werden, können wir – auch auf Basis unserer bisherigen Projekterfahrung – eine erste Kostenschätzung vornehmen. In unserer „Lessons-Learned-Datenbank“ erfassen wir hierfür sämtliche Implementierungsaufwände vergangener Projekte sowie die entsprechenden Einschätzungen der Experten.

Wir erstellen schlicht eine Liste der verschiedenen Komponenten wie Suche, Formular oder Multimedia-Galerie und multiplizieren diese mit ihrem jeweiligen Implementierungsaufwand.

Im nächsten Schritt kommt der Aufwand für unterstützende Tätigkeiten wie Entwicklung, Qualitätssicherung und Projektmanagement hinzu.

Auf diese Weise sind wir in der Lage, sehr schnell einen ersten Kostenvoranschlag zu erstellen. Meist reichen 30 Minuten hierfür aus.

Nun weiß Bastian, dass seine Anwendung insgesamt 90.000 Euro kosten wird. Durch das Entfernen von Funktionen, die für das MVP nicht relevant sind, kann er seinen Budgetrahmen von 45.000 Euro jedoch einhalten. Er nutzt diese Informationen, um seine Investition abzusichern und Investoren zu gewinnen. Da etwas Kapital fehlt, unterstützt ihn seine Großmutter gerne.

Das Projekt kann beginnen.

Anhand von Architekturvorlagen lassen sich die Aufwände für Funktionen innerhalb kurzer Zeit abschätzen. Zeit- und kostenintensive Analysen hinsichtlich des Budgets sind nicht erforderlich. Zudem liegt die Abweichung bei dieser Herangehensweise meist nur im Bereich von +/- 15 Prozent. Die Kosten sind bekannt und solide unternehmerische Entscheidungen können folgen.

5. Kontrollierte agile Entwicklung

Jetzt beginnt die agile Software-Entwicklung inklusive Kostencontrolling.

Wir nutzen zudem einen iterationsbasierten Ansatz, um die Auslieferung zu beschleunigen. Zu Beginn jeder Iteration schätzen wir die zu implementierenden User Stories. Diese Schätzungen sollten durch ein Team erfolgen, das sich nicht mit der vorangegangenen Kostenschätzung befasst hat. Auf diese Weise können die Mitarbeiter den Aufwand unvoreingenommen beurteilen.

Ein weiterer Vorteil: Das Management kann sich in den Product Owner und das Team hineinversetzen. Bei starken Abweichungen muss der Grund identifiziert und eine Lösung erarbeitet werden.

In unserem Beispiel ist der Product Owner überrascht, dass das Team eine Funktion wesentlich aufweniger einschätzt, als in der ursprünglichen Annahme. Er findet heraus, dass die für die Zahlungsabwicklung erforderlichen Fähigkeiten im Team fehlen. Durch das Einbeziehen eines Entwicklers mit entsprechender Expertise konnten wir die ursprünglich geplanten Kosten aber dennoch einhalten.

Durch den Vergleich der ersten Einschätzung und der Aufwandschätzungen von genauer definierten User Stories können wertvolle Erkenntnisse gewonnen werden. Oftmals führen folgende Faktoren zu Abweichungen:

  • häufige Änderung der Anforderungen
  • neue Anforderungen, für die das Fachwissen im Team fehlt
  • falsche Festlegung der Architektur
  • zu genaue Definition der Architektur

6. Soll-Ist-Vergleich

Der Vergleich zwischen der ursprünglichen Einschätzung und den tatsächlichen Aufwänden sollte regelmäßig nach jedem Sprint stattfinden. Anstelle von künstlichen Story Points, die im betriebswirtschaftlichen Sinne nur schwer greifbar sind, messen wir den tatsächlichen Aufwand in Manntagen und die Kosten pro Stunde. Dies ist im Regelfall ein guter Indikator für die Performance des Teams.

Bastian ist überrascht, dass der Aufwand höher ausfiel, als erwartet. Eine Analyse ergibt, dass im Vorfeld nicht alle für das MVP relevanten Funktionen identifiziert wurden.

Wir tappen also nicht mehr im Dunkeln, sonder wissen genau, ob wir uns noch auf Kurs befinden.

7. Verfeinerung des Product Backlogs

Auf diese Weise lässt sich nachvollziehen, wann und zu welchen Kosten das Projekt abgeschlossen sein wird.

Agile Entwicklung

Bastian ist froh, dass der Projektfortschritt und die Kosten für ihn transparent sind. Er priorisiert die Funktionen, um den geplanten Kostenrahmen einzuhalten. Er verfügt zudem über das relevante Zahlenmaterial für seine Investoren und seine Großmutter.

Das Produkt kann „live“ gehen.

Kommentar hinzufügen

E-Mail-Adresse ist schon registriert. Bitte benutze Das Login-Formular oder nenne eine andere.

Du hast einen falschen Nutzernamen oder Passwort eingegeben

Sorry that something went wrong, repeat again!
Kontaktieren Sie uns