Prozess10 Min. Lesezeit

Agile & Scrum in der Softwareentwicklung: wie funktioniert das in der Praxis?

Von Mustafa KoseGründer und Entwickler von VirtuoLabVeröffentlicht Zuletzt aktualisiert

Agile ist ein Ansatz der Softwareentwicklung, bei dem ein Produkt in kurzen Zyklen wächst, mit funktionierender Software und Kundenfeedback nach jedem Zyklus. Der Ansatz geht auf das Agile Manifest von 2001 zurück, verfasst von 17 Personen. Scrum ist das bekannteste agile Framework, beschrieben im Scrum Guide (November 2020) von Ken Schwaber und Jeff Sutherland. 2026 umfasst ein Scrum Team typischerweise 10 Personen oder weniger und arbeitet in Sprints von höchstens einem Monat. In jedem Sprint ist Schritt 1 das Sprint Planning, Schritt 2 das Daily Scrum, Schritt 3 das Sprint Review und Schritt 4 die Sprint Retrospective. Ein Ein-Personen-Studio wie VirtuoLab übernimmt zum Beispiel Sprints, Backlog und Demos, aber nicht die komplette Teamstruktur. Kunden von VirtuoLab sehen schon nach dem ersten Sprint funktionierende Software, mit einer Demo über Microsoft Teams oder vor Ort.

Was ist agile Softwareentwicklung?

Agile Softwareentwicklung ist eine Art, Software in kleinen, funktionierenden Schritten zu bauen statt in einer großen Lieferung am Ende. Der Ansatz geht auf das Manifest für Agile Softwareentwicklung von 2001 zurück. Das Manifest nennt 17 Autoren, darunter Kent Beck, Martin Fowler, Ken Schwaber und Jeff Sutherland. Der Text enthält vier Werte und zwölf Prinzipien. Laut Prinzip 3 soll funktionierende Software alle paar Wochen bis alle paar Monate kommen, bevorzugt im kürzeren Rhythmus. Außerdem nennt das siebte Prinzip funktionierende Software das wichtigste Fortschrittsmaß. In der Praxis bedeutet agil, dass ein Kunde früh echte Bildschirme sieht, echte Funktionen testet und unterwegs Prioritäten verschiebt. Teams arbeiten mit Scrum, Kanban oder Extreme Programming, um die agilen Werte in feste Routinen zu übersetzen. Für Unternehmer bringt das 2026 vor allem frühes Feedback, solange eine Korrektur noch günstig ist.

Die vier Werte des Agilen Manifests:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Worin unterscheidet sich agil vom Wasserfallmodell?

Das Wasserfallmodell ist ein sequenzieller Ansatz, bei dem Analyse, Design, Entwicklung, Test und Übergabe in festen Phasen aufeinander folgen. Jede Phase beginnt erst, wenn die vorherige abgeschlossen ist. Der Wasserfall funktioniert gut, wenn die Anforderungen stabil und vollständig bekannt sind, zum Beispiel bei einer einmaligen Migration von 5.000 Kunden in ein neues System. Software für ein wachsendes Unternehmen bleibt 2026 jedoch selten stabil. Nutzer entdecken neue Wünsche, sobald der erste Bildschirm erscheint. Im Wasserfallprojekt sieht der Kunde das Ergebnis erst am Ende, sodass ein Missverständnis aus Woche 2 im Monat 6 teuer wird. Agile teilt dieselbe Arbeit in kurze Zyklen. Jeder Zyklus endet mit funktionierender Software, einer Demo über Microsoft Teams, Google Meet oder vor Ort und einer Entscheidung über die nächste Priorität. Außerdem wird in jedem Zyklus getestet, nicht nur in einer Schlussphase. Die Tabelle zeigt die Unterschiede, die ein Kunde am stärksten merkt.

Wasserfall
Agil (zum Beispiel Scrum)
Planung
Alles im Voraus
Grobplanung, Details pro Sprint
Erste funktionierende Software
Am Ende
Nach dem ersten Sprint
Neue Prioritäten
Formaler Änderungsantrag
Nächster Sprint, über das Backlog
Rolle des Kunden
Genehmigt Spezifikation und Endergebnis
Prüft in jedem Sprint eine Demo
Risiken
Spät sichtbar
Früh sichtbar

Wie funktioniert Scrum laut Scrum Guide?

Scrum ist ein leichtgewichtiges Framework, um komplexe Probleme in kurzen, überprüfbaren Zyklen zu lösen. Die offiziellen Regeln stehen im Scrum Guide (November 2020) von Ken Schwaber und Jeff Sutherland, der auch 2026 noch die gültige Fassung ist. Der Guide beschreibt ein Scrum Team aus einem Scrum Master, einem Product Owner und Developers, typischerweise 10 Personen oder weniger. Gearbeitet wird in Sprints von höchstens einem Monat. Jeder Sprint umfasst vier Events: Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective. Drei Artefakte machen die Arbeit transparent. Das Product Backlog enthält alles, was das Produkt brauchen könnte, und das Sprint Backlog enthält den Plan für einen Sprint. Das Increment ist das nutzbare Ergebnis, ein konkreter Schritt in Richtung Product Goal. In der Praxis führen viele Teams das Backlog in Jira oder Trello. Schließlich ruht Scrum auf drei Säulen: Transparenz, Überprüfung und Anpassung.

Scrum-Event
Zweck
Maximum bei einem Ein-Monats-Sprint
Sprint Planning
Sprint Goal und Arbeit festlegen
8 Stunden
Daily Scrum
Fortschritt Richtung Sprint Goal prüfen
15 Minuten
Sprint Review
Ergebnis prüfen und nächste Schritte festlegen
4 Stunden
Sprint Retrospective
Arbeitsweise verbessern
3 Stunden

Was passiert in einem Sprint, Schritt für Schritt?

Ein Sprint ist ein fester Zeitraum von höchstens einem Monat, in dem ein Team Backlog-Einträge in ein nutzbares Increment verwandelt. Schritt 1 ist das Sprint Planning: Das Team wählt ein Sprint Goal und die dafür nötigen Backlog-Einträge. Schritt 2 ist die Bauphase, in der Developers täglich kleine Teile entwerfen, programmieren und testen. Ein Daily Scrum von höchstens 15 Minuten hält ein Team von bis zu 10 Personen auf Kurs. Schritt 3 ist das Sprint Review, in dem Stakeholder funktionierende Software sehen und über die nächsten Schritte entscheiden. Laut Ken Schwaber und Jeff Sutherland ist das Sprint Review eine Arbeitssitzung und nicht nur eine Präsentation. Schließlich ist Schritt 4 die Sprint Retrospective, in der das Team festlegt, was besser werden soll. Jedes Increment muss die Definition of Done erfüllen, den gemeinsamen Qualitätsstandard für fertige Arbeit. Zum Beispiel kann eine Definition of Done für eine Web-App mit Next.js 2026 automatisierte Tests, ein Code-Review und ein Test-Deployment verlangen.

Funktioniert Scrum mit nur einem Entwickler?

Scrum nach Lehrbuch ist ein Team-Framework, deshalb kann ein einzelner Entwickler Scrum nicht im strengen Sinn umsetzen. Der Scrum Guide (November 2020) beschreibt drei getrennte Verantwortlichkeiten und hält fest, dass der Product Owner eine Person ist und kein Gremium. Ein Solo-Entwickler, der zugleich Scrum Master ist, coacht nur sich selbst, und ein Daily Scrum mit einem Teilnehmer ist eine To-do-Liste. VirtuoLab ist ein Ein-Personen-Unternehmen in Papendrecht und behauptet deshalb nicht, Scrum zu betreiben. Stattdessen übernimmt VirtuoLab die agilen Bausteine, die in jeder Größe funktionieren. Der erste Baustein ist ein priorisiertes Backlog, der zweite sind kurze Sprints, und der dritte ist eine Zwischendemo mit funktionierender Software. Der Kunde steuert unterwegs mit und entscheidet, was am wichtigsten ist, eine Rolle nah am Product Owner. In der Praxis sprechen Kunden 2026 direkt mit dem Entwickler, ohne Account Manager dazwischen.

Wie arbeitet VirtuoLab mit kurzen Sprints und Demos?

VirtuoLab ist eine Softwareagentur in Papendrecht, die Web-Apps, mobile Apps und SaaS-Plattformen in kurzen Sprints mit Zwischendemos baut. Jedes Projekt folgt vier Schritten. Zuerst kommt ein kostenloses Kennenlernen, in dem der Umfang festgelegt wird. Danach machen Design und Validierung aus dem Umfang Bildschirme und einen Plan. Drittens laufen Entwicklung und Test in kurzen Sprints, jeweils gefolgt von einer Demo funktionierender Software über Microsoft Teams oder vor Ort. Schließlich bringen Launch und Support das Produkt live. Der Preis steht fest, bevor Code geschrieben wird, und danach gehören Code und Daten dem Kunden. Eine einfache Web-App kostet zum Beispiel 5.000 bis 10.000 € und dauert 2026 etwa 3 bis 6 Wochen. Eine mittelgroße Web-App für 10.000 bis 25.000 € dauert 6 bis 12 Wochen. Die Preise sind Richtwerte, der genaue Preis folgt nach dem kostenlosen Kennenlernen. VirtuoLab entwickelt mit Next.js, TypeScript und PostgreSQL, und der Entwickler, der die Software baut, präsentiert jede Demo selbst.

Wann ist agil nicht die richtige Wahl?

Agil ist die falsche Wahl, wenn der Umfang klein, fest und vorab vollständig bekannt ist. Eine einfache API-Schnittstelle für 1.500 bis 4.000 € hat oft ein klares Ziel, zum Beispiel: Bestellungen aus Shopify sollen mit Exact Online synchronisiert werden. Für einen Auftrag von wenigen Tagen ist ein kurzer Plan mit einer Testrunde schneller als Sprints. Agil scheitert auch, wenn der Kunde keine Zeit für Feedback hat. Laut Prinzip 4 arbeiten Fachleute aus dem Business und Entwickler während des gesamten Projekts täglich zusammen. Eine Demo ohne Entscheidung des Kunden kostet einen Sprint, egal ob die Demo vor Ort oder über Google Meet läuft. Außerdem brauchen manche Projekte vorab eine vollständige Spezifikation, zum Beispiel für eine Ausschreibung oder eine strenge Compliance-Prüfung. Dann funktioniert ein hybrider Ansatz am besten: erst eine feste Spezifikation, danach kurze Bauzyklen mit Demos. In der Praxis lautet die eigentliche Frage 2026, wie viel Feedback ein Projekt braucht.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Agile und Scrum?

Agile ist ein Satz von Werten und Prinzipien, Scrum dagegen ein konkretes Framework, um diese Werte umzusetzen. Das Agile Manifest stammt aus dem Jahr 2001. Das Manifest beschreibt, worauf es ankommt, etwa funktionierende Software und das Reagieren auf Veränderung. Der Scrum Guide von Ken Schwaber und Jeff Sutherland beschreibt, wie ein Team die Arbeit organisiert: Verantwortlichkeiten, Events und Artefakte. Der Guide setzt auch feste Regeln, etwa ein Scrum Team von 10 Personen oder weniger und Sprints von höchstens einem Monat. Scrum ist eines von mehreren agilen Frameworks. Kanban setzt auf einen kontinuierlichen Arbeitsfluss ohne feste Sprints. Außerdem konzentriert sich Extreme Programming auf technische Praktiken wie Pair Programming und testgetriebene Entwicklung. In der Praxis kombinieren viele Teams 2026 Elemente, zum Beispiel Scrum-Sprints mit Kanban-Boards in Jira oder Trello. Jedes Scrum-Projekt ist agil, aber nicht jedes agile Projekt nutzt Scrum.

Wie lang sollte ein Sprint sein?

Ein Sprint dauert höchstens einen Monat, so steht es bei Ken Schwaber und Jeff Sutherland im Scrum Guide vom November 2020. Innerhalb dieser Grenze hängt die richtige Länge davon ab, wie schnell Feedback nötig ist. Kürzere Sprints bedeuten häufigere Demos und schnellere Korrekturen, aber auch mehr Planungstermine. Bei kleinen Softwareprojekten sind 2026 Sprints von einer oder zwei Wochen üblich. Eine einfache Web-App mit 3 bis 6 Wochen Laufzeit hätte sonst nur ein oder zwei Feedbackmomente. Längere Sprints von drei oder vier Wochen passen zu größeren Teams von 7 bis 10 Personen mit stabilen Prioritäten. Die wichtigste Regel ist Regelmäßigkeit, weil ein fester Rhythmus den Fortschritt von Sprint zu Sprint vergleichbar macht. Ein Kunde kann zum Beispiel jeden zweiten Freitag dieselbe Stunde für eine Demo über Microsoft Teams reservieren. Ein kurzer, planbarer Demo-Termin hält das Feedback in Gang, ohne lange Meetings.

Wie passt ein Festpreis zu agilem Arbeiten?

Ein Festpreis passt zu agilem Arbeiten, wenn das Budget feststeht und der Umfang innerhalb klarer Grenzen flexibel bleibt. Bei VirtuoLab vereinbaren Sie den Preis, bevor Code geschrieben wird, auf Basis des Umfangs aus dem kostenlosen Kennenlernen. Als Richtwert für 2026 kostet eine einfache Web-App 5.000 bis 10.000 €. Während der Sprints zeigt ein gemeinsames Backlog, welche Funktionen in den vereinbarten Umfang fallen. Laut Prinzip 2 des Agilen Manifests sind sich ändernde Anforderungen willkommen, selbst spät in der Entwicklung. Eine neue Idee bekommt dann eine von zwei Optionen. Die erste Option ist, den neuen Eintrag gegen einen bestehenden Eintrag ähnlicher Größe zu tauschen. Die zweite Option ist, den neuen Eintrag für eine spätere Phase einzuplanen. Eine Exportfunktion kann zum Beispiel in Phase 2 wandern, während Login und Abrechnung zuerst für die ersten 100 Nutzer live gehen. So schützt der Ansatz beide Seiten: Der Kunde behält Budgetsicherheit, und das Projekt behält Raum, auf Veränderung zu reagieren.

Weiterlesen

Quellen