Agile Softwareentwicklung: Ablauf und Grenzen
· DigifyNow
Bei agiler Softwareentwicklung legen Sie nicht vorab den gesamten Umfang fest. Stattdessen pflegen Sie eine priorisierte Liste von Anforderungen, das Backlog. Das Team baut in kurzen, festen Zyklen jeweils die wichtigsten Punkte als lauffähige Software. Danach führt es das Ergebnis den Fachleuten vor und plant den nächsten Zyklus neu. Sie steuern über die Reihenfolge im Backlog: Zeit und Budget je Zyklus bleiben fest, der Umfang bewegt sich.
Was versteht man unter agiler Softwareentwicklung?
Agile Softwareentwicklung ist ein Sammelbegriff für Vorgehensweisen, bei denen Software in kurzen, wiederkehrenden Zyklen entsteht. Nach jedem Zyklus gibt es ein Stück, das wirklich läuft. Gemeint ist also kein einzelnes Verfahren, sondern eine Haltung, aus der mehrere Methoden hervorgegangen sind, etwa Scrum, Kanban oder Extreme Programming. Das Gegenmodell ist das klassische Wasserfall-Vorgehen. Dort steht am Anfang ein vollständiges Pflichtenheft, und gebaut wird erst, wenn es abgenommen ist.
Der Unterschied liegt darin, wann Sie etwas lernen. Im Wasserfall sehen Sie die Software erst am Ende, und eine falsche Annahme aus der Planung wird dann am teuersten. Agil sehen Sie nach jedem Zyklus etwas Lauffähiges und können die Richtung ändern, bevor viel darauf aufgebaut ist. Ein Beispiel: Ein Handwerksbetrieb will eine digitale Auftragsverwaltung. Agil wird zuerst nur das Anlegen eines Auftrags mit Kunde und Termin gebaut, und zwei Disponenten probieren es im Alltag aus. Erst wenn das trägt, folgen Materiallisten, Fotos von der Baustelle und die Übergabe an die Rechnung. Merken die Disponenten dabei, dass sie Aufträge vor allem am Telefon anlegen, wird die Eingabemaske umgebaut, bevor jemand die Rechnungsanbindung programmiert hat.

Welche Werte und 12 Prinzipien stehen im Agilen Manifest?
Die Grundlage ist das Manifest für Agile Softwareentwicklung. Es wurde 2001 veröffentlicht und steht auf agilemanifesto.org auch auf Deutsch. Es nennt vier Werte, jeweils als Gewichtung: Individuen und Interaktionen vor Prozessen und Werkzeugen, funktionierende Software vor umfassender Dokumentation, Zusammenarbeit mit dem Kunden vor Vertragsverhandlung und Reagieren auf Veränderung vor dem Befolgen eines Plans. Das Manifest sagt ausdrücklich, dass auch die rechte Seite Wert hat. Dokumentation und Verträge werden also nicht abgeschafft, sie bekommen nur weniger Gewicht. Dazu kommen zwölf Prinzipien, hier sinngemäß zusammengefasst:
- Den Kunden früh und laufend mit nutzbarer Software zufriedenstellen.
- Geänderte Anforderungen auch spät im Projekt annehmen.
- Funktionierende Software in kurzen Abständen liefern.
- Fachleute und Entwickler arbeiten während des Projekts täglich zusammen.
- Projekte um motivierte Menschen herum aufbauen und ihnen vertrauen.
- Informationen am besten im direkten Gespräch weitergeben.
- Funktionierende Software ist das wichtigste Maß für den Fortschritt.
- Ein Tempo halten, das sich dauerhaft durchhalten lässt.
- Auf technische Qualität und gutes Design achten.
- Einfachheit: möglichst viel Arbeit gar nicht erst machen.
- Die besten Lösungen kommen aus Teams, die sich selbst organisieren.
- Das Team prüft regelmäßig, wie es besser werden kann, und passt sich an.
Wie läuft ein agiler Entwicklungszyklus konkret ab?
Die Methoden heißen unterschiedlich, aber ein Zyklus ist fast immer gleich aufgebaut. In Scrum heißt so ein Zyklus Sprint. Seine Länge wird vorab festgelegt und danach nicht mehr verändert.
- Backlog füllen: Anforderungen als kurze Beschreibungen aus Nutzersicht sammeln, zum Beispiel: Als Disponent will ich einen Auftrag einem Monteur zuweisen, damit er ihn auf dem Handy sieht.
- Priorisieren: Eine Person auf Ihrer Seite legt die Reihenfolge fest. In Scrum heißt diese Rolle Product Owner. Fehlt diese Person, entscheidet niemand, was zuerst kommt.
- Zyklus planen: Das Team nimmt sich nur so viele Punkte von oben, wie es im Zyklus fertig bekommt. Fertig heißt dabei getestet und lauffähig, nicht bloß programmiert.
- Bauen und täglich abstimmen: Ein kurzes tägliches Treffen klärt, was einen Punkt gerade blockiert.
- Review: Das Ergebnis wird an echter Software vorgeführt, nicht auf Folien. Ihre Rückmeldung landet als neuer oder geänderter Punkt im Backlog.
- Retrospektive: Das Team schaut auf die eigene Arbeitsweise und legt eine konkrete Änderung für den nächsten Zyklus fest.
Für Sie als Auftraggeber ist Schritt 2 der entscheidende Hebel. Wer die Reihenfolge im Backlog bestimmt, bestimmt auch, was bei begrenztem Budget am Ende fertig ist. Wie ein beauftragtes Projekt von der Anfrage bis zur Abnahme abläuft, beschreibt der Artikel Softwareentwicklung: So läuft ein Projekt ab.

Was ist der Unterschied zwischen Agile und Scrum?
Agil ist die Haltung aus dem Manifest. Scrum ist ein konkretes Rahmenwerk, das diese Haltung mit festen Regeln umsetzt: drei Rollen (Product Owner, Scrum Master, Entwicklungsteam), Sprints mit fester Länge und feste Termine wie Planung, Review und Retrospektive. Jedes Scrum-Projekt ist agil, aber nicht jedes agile Projekt nutzt Scrum. Kanban zum Beispiel kommt ganz ohne Sprints aus und begrenzt stattdessen, wie viele Aufgaben gleichzeitig in Arbeit sein dürfen.
| Merkmal | Wasserfall | Scrum | Kanban |
|---|---|---|---|
| Planung | Vollständig vorab im Pflichtenheft | Grob im Backlog, genau je Sprint | Laufend, Aufgabe für Aufgabe |
| Taktung | Phasen nacheinander | Sprints mit fester Länge | Kein fester Takt, fortlaufender Fluss |
| Rollen | Projektleitung, Fachabteilung, Entwicklung | Product Owner, Scrum Master, Entwicklungsteam | Keine vorgeschriebenen Rollen |
| Änderungen | Über einen formalen Änderungsantrag | Zum nächsten Sprint möglich | Jederzeit über die Reihenfolge der Aufgaben |
| Passt gut zu | Feststehenden, gut beschriebenen Anforderungen | Neuen Produkten mit offenen Fragen | Wartung, Support, laufender Weiterentwicklung |
Welche 5 Phasen der Softwareentwicklung gibt es – und was macht agil daraus?
Softwareentwicklung, also das Planen, Programmieren, Prüfen und Betreiben von Software, wird oft in fünf Phasen eingeteilt: Anforderungen erheben, Entwurf, Umsetzung, Test sowie Betrieb und Wartung. Im Wasserfall laufen diese Phasen einmal nacheinander ab, und jede endet mit einem Dokument, das die nächste freigibt. Agil verschwinden die Phasen nicht. Sie laufen in jedem Zyklus im Kleinen durch: Für die drei wichtigsten Backlog-Punkte wird geklärt, entworfen, gebaut, getestet und ausgeliefert. Daraus folgt eine technische Anforderung, die oft unterschätzt wird. Wenn jeder Zyklus etwas Lauffähiges liefern soll, müssen Test und Auslieferung weitgehend automatisiert sein. Ohne automatisierte Tests steigt der Prüfaufwand mit jedem Zyklus, weil alles bisher Gebaute wieder von Hand getestet werden muss. KI-Werkzeuge beschleunigen inzwischen die Umsetzung, ersetzen aber nicht die Prüfung. Was sie am Code wirklich leisten, steht im Artikel KI-Softwareentwicklung: Was KI am Code leistet.

Wann funktioniert agile Softwareentwicklung nicht?
Agil ist kein Selbstläufer. Die meisten Probleme haben eine klar erkennbare Ursache:
- Niemand auf Kundenseite hat Zeit: Ohne eine Person, die priorisiert und zu den Reviews kommt, baut das Team nach eigenen Annahmen. Dann ist es ein Wasserfall ohne Pflichtenheft.
- Die Anforderungen stehen fest: Bei einer gesetzlich vorgegebenen Meldeschnittstelle oder beim Nachbau eines bestehenden Formulars gibt es wenig zu lernen. Dort ist ein klarer Plan oft der kürzere Weg.
- Agil als Ausrede für fehlende Planung: Auch agil braucht ein Ziel, eine grobe Architektur und eine Vorstellung vom Gesamtumfang. Sonst wächst das Backlog schneller, als es abgearbeitet wird.
- Fertig ist nicht fertig: Gelten Punkte als erledigt, die noch nicht getestet sind, sammeln sich Fehler, und spätere Zyklen gehen für Nacharbeit drauf.
- Rituale ohne Wirkung: Tägliche Treffen und Retrospektiven, aus denen nichts folgt, kosten Zeit und ändern nichts.
- Abhängigkeiten von Dritten: Wenn ein Zugang zur Warenwirtschaft oder eine Freigabe der IT wochenlang dauert, hilft auch der kürzeste Zyklus nicht.
Geht agile Softwareentwicklung mit Festpreis?
Ja, aber anders als oft erwartet. Ein Festpreis für einen festen Umfang widerspricht dem Gedanken, den Umfang während des Projekts zu ändern. Möglich sind zwei Muster. Das erste ist ein festes Budget mit beweglichem Umfang: Sie entscheiden über die Reihenfolge im Backlog, was innerhalb des Budgets gebaut wird, und was nicht mehr hineinpasst, fällt bewusst weg. Das zweite sind kleine, abgeschlossene Pakete, etwa ein MVP mit klar beschriebener Kernfunktion, für die ein fester Rahmen vereinbart wird, bevor das nächste Paket geplant wird. Bei beiden Mustern zählt die Abnahme gegen schriftliche Kriterien je Paket. Ob das rechtlich eher ein Werk- oder ein Dienstvertrag ist, klären Sie am besten mit Ihrer Rechtsberatung. Was den Aufwand selbst treibt, also Umfang, Schnittstellen, Datenmigration und Betrieb, ist im Artikel Kosten für Softwareentwicklung aufgeschlüsselt.

Agentur für Softwareentwicklung im Westerwald: Worauf achten?
Wer im Westerwald einen Partner für Softwareentwicklung sucht, sollte weniger auf das Wort agil im Angebot achten als darauf, wie tatsächlich gearbeitet wird. Prüfbare Fragen fürs Erstgespräch: Sehe ich nach jedem Zyklus lauffähige Software auf einer Testumgebung? Wer pflegt das Backlog, und kann ich es jederzeit einsehen? Wie ist fertig definiert? Wem gehört der Quellcode? Wer betreut das System nach dem Start? Räumliche Nähe hilft bei Workshops am Anfang und bei Reviews mit Mitarbeitern, die selten am Bildschirm sitzen, etwa in Werkstatt oder Lager.
DigifyNow sitzt in Unnau im Westerwald und arbeitet deutschlandweit, mit Schwerpunkt Westerwald, Koblenz und Siegerland. Das Team entwickelt individuelle Apps, Web-Apps und Software für kleine und mittlere Unternehmen. Am Anfang steht ein MVP, das nur die Kernfunktion enthält, danach wird es schrittweise zum laufenden System weiterentwickelt. Ein Beispiel ist das individuelle Backoffice mit CRM für Mundo Marketing. Einen Überblick über das Angebot gibt die Seite zu den Leistungen von DigifyNow, die regionale Arbeit beschreibt die Seite Softwareentwicklung im Westerwald.
Wann sich Unterstützung lohnt
Hilfe von außen lohnt sich, wenn Sie Software brauchen, die es so nicht als Standardprodukt gibt, intern aber kein Entwicklungsteam haben. Sie lohnt sich auch, wenn ein laufendes Projekt nach mehreren Zyklen nichts Nutzbares hervorgebracht hat. Nicht lohnend ist sie, wenn eine fertige Software Ihren Ablauf schon zu großen Teilen abdeckt. Bringen Sie zum Gespräch mit: den Ablauf, den die Software unterstützen soll, die Systeme, mit denen sie Daten austauschen muss, eine Person, die priorisieren darf, und einen groben Budgetrahmen. In der kostenlosen, unverbindlichen Einschätzung Ihres Vorhabens klärt DigifyNow, ob und in welchem Zuschnitt sich eine eigene Entwicklung anbietet.

Häufige Fragen
Ist agile Softwareentwicklung teurer als klassische?
Pro Arbeitsstunde nicht, denn die Kostentreiber sind dieselben: Umfang, Schnittstellen, Daten und Betrieb. Der Unterschied liegt im Risiko. Klassisch wird der Umfang vorab fest beschrieben, und spätere Änderungen laufen über Nachträge. Agil wird das Budget je Zyklus festgelegt, der Umfang bleibt beweglich. Dadurch wird weniger gebaut, was keiner braucht. Im Gegenzug brauchen Priorisierung und Reviews mehr von Ihrer Zeit.
Wie viel Zeit muss ich als Auftraggeber einplanen?
Mindestens für zwei Aufgaben. Erstens die Priorisierung des Backlogs vor jedem Zyklus. Zweitens das Review am Ende jedes Zyklus, bei dem Sie lauffähige Software prüfen. Dazu kommen kurze Rückfragen zwischendurch. Fallen Reviews regelmäßig aus, baut das Team ohne Rückmeldung weiter. Damit verliert das agile Vorgehen seinen einzigen Vorteil gegenüber einem festen Plan.
Was ist ein MVP in der agilen Entwicklung?
Ein MVP (Minimum Viable Product) ist die kleinste Version einer Software, die einen echten Ablauf von Anfang bis Ende abdeckt und von echten Nutzern verwendet wird. Ein Klickdummy zeigt nur Bildschirme, ein Proof of Concept beantwortet eine einzelne technische Frage. Das MVP dagegen läuft im Alltag. Es ist meist der erste größere Meilenstein in einem agilen Projekt.