Delivery Models für Softwareentwicklung

Problem

Die moderne Softwareentwicklung steht vor einem Paradoxon: Während digitale Produkte schneller entwickelt und häufiger angepasst werden müssen, hinken die Lieferprozesse, die dies ermöglichen, oft hinterher. Traditionelle Software-Liefermodelle, insbesondere planungsorientierte Modelle wie die Wasserfall-Methodik, wurden im Hinblick auf Vorhersagbarkeit und Kontrolle entwickelt. In dynamischen Märkten, in denen sich die Kundenerwartungen schnell weiterentwickeln und sich der Produktumfang während der Entwicklung ändert, können diese starren Ansätze jedoch zu erheblichen Verzögerungen, Fehlausrichtungen und Nacharbeiten führen.

Das Aufkommen von KI-gestützten Entwicklungstools (AI-powered development) verspricht eine Beschleunigung durch automatisierte Codegenerierung (automated code generation) und intelligente Tests (intelligent testing), aber Unternehmen haben Schwierigkeiten, diese Funktionen zu integrieren und gleichzeitig die für die DSGVO (data governance) , HIPAA (HIPAA) und Finanzvorschriften (inancial regulations) erforderlichen Standards in Bezug auf die Einhaltung gesetzlicher Vorschriften, Datenverwaltung und Cybersicherheit einzuhalten.

Ein grosses Problem ist die Diskrepanz zwischen Geschäftsstrategie und technischer Umsetzung. Bei herkömmlichen Delivery-Modellen werden Planung und Umsetzung oft in voneinander getrennte Phasen unterteilt, was zu einer Kluft zwischen den Vorstellungen der Stakeholder und dem, was die Teams letztendlich umsetzen, führt. Darüber hinaus lassen eine übermässige Vorabdokumentation und eine starre Umfangsplanung wenig Spielraum für die Reaktion auf neues Nutzer-Feedback oder neue technische Erkenntnisse. Dies kann dazu führen, dass Produkte zwar die ursprünglichen Spezifikationen erfüllen, aber keinen Mehrwert bieten. 

Wenn Teams grösser werden oder verteilt arbeiten, wird die Koordination zu einer grossen Herausforderung. Herkömmliche Modelle lassen sich nur schwer über wenige Teams hinaus skalieren, was zu fragmentierter Kommunikation, Doppelarbeit und Verzögerungen führt. In solchen Umgebungen ist es schwierig, den Überblick über alle Aktivitäten zu behalten, die Umsetzung an strategischen Zielen auszurichten und einheitliche Qualitätsstandards aufrechtzuerhalten. Hinzu kommt, dass der Aufstieg von Continuous Deployment (continuous deployment) und DevOps-Praktiken (DevOps practices )die Grenzen herkömmlicher, monolithischer Bereitstellungsmodelle noch deutlicher gemacht hat. 

Kurz gesagt: Angesichts der zunehmenden Komplexität von Software und der steigenden Erwartungen an die Bereitstellung reichen die traditionellen Einheitsmodelle nicht mehr aus. Unternehmen benötigen adaptivere, kollaborativere und skalierbarere Ansätze für die Softwareentwicklung. 

Lösung

Als Reaktion auf die Einschränkungen traditioneller Modelle hat die Branche ein vielfältiges Ökosystem von Software-Bereitstellungsframeworks entwickelt, die nun KI-gestützte Entwicklungsmethoden in umfassende Compliance-Frameworks integrieren. Diese reichen von vollständig adaptiven agilen Methoden über strukturierte Hybridmodelle bis hin zu Frameworks für Unternehmen wie SAFe (Scaled Agile Framework). Der rote Faden ist Flexibilität: Diese Modelle sind darauf ausgelegt, Veränderungen zu berücksichtigen, die Zusammenarbeit zu fördern und iterativ Mehrwert zu schaffen, während gleichzeitig die Governance-Kontrollen für die Einhaltung gesetzlicher Vorschriften und den verantwortungsvollen Einsatz von KI aufrechterhalten werden.

Moderne Frameworks integrieren die KI-Codegenerierung (AI code generation) in etablierte Qualitätskontrollen und Compliance-Validierungsprozesse (compliance), sodass Unternehmen intelligente Entwicklungstools nutzen und gleichzeitig Vorschriften und Cybersicherheitsstandards (cybersecurity standards) einhalten können.

Agile Methoden wie Scrum, Kanban, und Extreme Programming (XP) legen den Schwerpunkt auf inkrementelle Entwicklung, Teamautonomie und schnelle Feedbackzyklen. Sie ermöglichen es Teams, die Arbeit in überschaubare Teilaufgaben zu unterteilen, Prioritäten auf der Grundlage des Kundennutzens zu setzen und Pläne regelmässig anzupassen. Scrum beispielsweise nutzt strukturierte Sprints und Rollen, um Rhythmus und Fokus zu schaffen, während Kanban einen kontinuierlichen Fluss und visuelles Workflow-Management fördert. 

Für grosse Unternehmen oder regulierte Umgebungen kombinieren Hybridmodelle wie Scrumfall und Wagile das Beste aus Agile und Waterfall. Sie ermöglichen eine iterative Entwicklung innerhalb eines breiteren Rahmens von Governance und Planung. Disciplined Agile Delivery (DAD) und SAFe gehen noch einen Schritt weiter und bieten modulare Toolkits zur Anpassung der Lieferpraktiken über Teams, Programme und Portfolios hinweg. 

Darüber hinaus optimieren Lean-Praktiken die Wertlieferung durch die Beseitigung von Verschwendung, während DevOps und CI/CD Entwicklung und Betrieb für schnellere und zuverlässigere Releases integrieren. Frameworks wie das Spotify model und Large-Scale Scrum (LeSS) bieten skalierbare Möglichkeiten, mehrere autonome Teams zu koordinieren, ohne dabei an Agilität einzubüssen. 

Durch die Wahl des richtigen Delivery-Modells bzw. die individuelle Anpassung einer Kombination verschiedener Modelle können Unternehmen ihre Prozesse an die Anforderungen des Produkts, des Teams und der Umgebung anpassen. Das Ziel besteht nicht darin, sich strikt an eine Doktrin zu halten, sondern eine nachhaltige, qualitativ hochwertige Delivery in grossem Massstab zu ermöglichen. 

Result

Unternehmen, die moderne Softwarebereitstellungsmodelle einsetzen, erzielen messbare Verbesserungen bei wichtigen Leistungsindikatoren und halten gleichzeitig strenge Compliance- und Governance-Standards ein. Agile Frameworks ermöglichen eine schnellere Markteinführung, indem sie die Entwicklung in kurze, fokussierte Zyklen unterteilen, die durch KI-gestützte Entwicklungstools ergänzt werden, welche die Codierung beschleunigen, während die automatisierte Compliance-Validierung (compliance) die Einhaltung gesetzlicher Vorschriften gewährleistet.

Die Integration von KI-gestützten Entwicklungspraktiken – einschließlich automatisierter Codeüberprüfung (automated code review), intelligenter Tests und KI-Code-Generierung (AI code generation), in strukturierte Bereitstellungsframeworks 
ermöglicht 40 bis 60 % schnellere Entwicklungszyklen bei gleichzeitiger Einhaltung von Compliance-Standards.

Hybride Modelle (Hybrid models)bieten Flexibilität bei gleichzeitiger Aufrechterhaltung der Kontrolle. Durch die Integration von Planungsdisziplinen mit iterativer Ausführung bieten sie das Beste aus beiden Welten: die Fähigkeit, sich an Veränderungen anzupassen und gleichzeitig feste Fristen und regulatorische Anforderungen einzuhalten. Dies ist besonders wertvoll in Unternehmensumgebungen, in denen Governance unerlässlich ist, aber Agilität eine Wettbewerbsnotwendigkeit darstellt. 

Skalierte Agile-Modelle wie SAFe, LeSS, und das Spotify Squad Framework unterstützen die Abstimmung und Effizienz bei grossen Programmen mit mehreren Teams. Sie führen Koordinationsmechanismen ein, die es den verteilten Teams ermöglichen, auf gemeinsame Ziele hinzuarbeiten und gleichzeitig die Autonomie und Geschwindigkeit kleinerer Teams zu bewahren. Diese Modelle verbessern die teamübergreifende Zusammenarbeit, reduzieren Reibungsverluste bei der Übergabe und gewährleisten einheitliche Praktiken im gesamten Unternehmen. 

DevOps und CI/CD-Praktiken ermöglichen unterdessen eine nahezu kontinuierliche Bereitstellung hochwertiger Software. Automatisierung und Feedback-Schleifen reduzieren Fehler, verkürzen Release-Zyklen und ermöglichen schnellere Experimente. Dadurch wird die Entwicklung zu einem kontinuierlichen Wertstrom und nicht mehr zu einer Reihe isolierter Projekte. 

Der kumulative Effekt ist eine erhöhte organisatorische Agilität. Teams reagieren schneller auf Veränderungen, richten sich stärker an den Geschäftszielen aus und entwickeln qualitativ hochwertigere Software mit weniger Aufwand. Die Führungskräfte erhalten einen besseren Überblick über Fortschritte und Risiken, während sich die Arbeitsmoral der Teams aufgrund von eigenverantwortlicheren und reaktionsschnelleren Arbeitsweisen verbessert. Letztendlich verwandelt die Einführung des richtigen Software- Delivery-Modells die Softwareentwicklung von einem Engpass in einen strategischen Motor für Innovation und Wachstum. 

 

Agile Methodik

Agile is an umbrella term for a family of iterative and incremental software development methodologies. Agile approaches emphasize flexibility, collaboration, and rapid feedback over strict upfront planning. In an Agile process, work is done in small increments with frequent reassessment and adaptation, reducing waste and maximizing efficienc. The term originates from the Agile Manifesto (2001), which outlined core values favoring customer collaboration, responding to change, and delivering working software frequently. Compared to traditional linear methods, which plan everything in detail at the start, Agile is more adaptive and evolves through continuous learning and adjustment. 

Agile Methoden haben gemeinsame Prinzipien: Projekte werden in kleinere Teile zerlegt, funktionsübergreifende Teams werden einbezogen und es wird auf der Grundlage von Feedback kontinuierlich iteriert. Dies ist vergleichbar mit einem Jazzorchester, das gemeinsam improvisiert und sich anpasst, im Gegensatz zu einem klassischen Orchester, das einer festen Partitur folgt. Durch die iterative Bereitstellung von Software können agile Teams effektiver auf sich ändernde Anforderungen und Nutzerbedürfnisse reagieren. Beliebte Frameworks unter dem Dach von Agile sind Scrum, Kanban, Extreme Programming, und andere, die im Folgenden erläutert werden. 

Scrum Framework 

Scrum ist eines der am häufigsten verwendeten agilen Frameworks, das sich auf iterative Entwicklung durch zeitlich begrenzte Zyklen, sogenannte Sprints, konzentriert. Scrum verfolgt einen wertorientierten und empirischen Ansatz – das bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Beobachtungen basieren. Bei Scrum arbeitet ein funktionsübergreifendes Team in Sprints (in der Regel 2–4 Wochen lang) daran, ein potenziell lieferbares Produktinkrement zu entwickeln. Zu Beginn jedes Sprints hält das Team eine Planungssitzung ab, um zu entscheiden, welche Arbeitsaufgaben (aus einem priorisierten Backlog) in diesem Sprint erledigt werden sollen. Ein Product Owner ist für die Reihenfolge und Priorisierung des Backlogs verantwortlich und stellt sicher, dass das Team zuerst an den wertvollsten Funktionen arbeitet. Während des Sprints hält das Team tägliche Stand-up-Meetings ab, um sich abzustimmen, und am Ende führt es eine Überprüfung durch, um Feedback von den Stakeholdern einzuholen, sowie eine Retrospektive, um seinen Prozess zu verbessern. 

Scrum definiert klare Rollen: den Product Owner (Fokus auf den Geschäftswert), den Scrum Master (der den Prozess moderiert und Hindernisse beseitigt) und das Entwicklungsteam (das das Produkt erstellt). Scrum-Zeremonien (Veranstaltungen) wie Sprint-Planung, tägliche Stand-up-Meetings, Sprint-Review und Retrospektive fördern Transparenz und kontinuierliche Verbesserung. Das Ziel jedes Sprints ist es, eine Erweiterung des Produkts zu liefern, die von den Stakeholdern überprüft werden kann, sodass Feedback schnell in den nächsten Sprint einfliessen kann. Dieser iterative Zyklus wiederholt sich und ermöglicht eine schrittweise Wertsteigerung und Anpassungsfähigkeit an Veränderungen. 

Scaled Agile Framework (SAFe) 

Das Scaled Agile Framework (SAFe) Scaled Agile Framework (SAFe) ist eine agile Methodik, die darauf ausgelegt ist, agile und Lean-Prinzipien auf Unternehmensebene anzuwenden. SAFe bietet einen strukturierten Ansatz für die Koordination der Arbeit mehrerer agiler Teams innerhalb einer Organisation. Im Wesentlichen handelt es sich um eine Reihe von Organisations- und Workflow-Mustern, die Unternehmen dabei unterstützen sollen, Lean- und Agile-Praktiken über ein einzelnes Team hinaus zu skalieren. Die Grundlage von SAFe umfasst drei Ebenen (oft als Säulen bezeichnet): Team, Programm und Portfolio. Auf der Teamebene folgt SAFe weitgehend Scrum (Teams arbeiten in Sprints mit Scrum Masters und Product Owners). Auf der Programmebene wird das Konzept eines Agile Release Train eingeführt, bei dem mehrere Teams (ein „Zug“) ihre Iterationen synchronisieren, um gemeinsam grössere Features zu liefern, die von einem Release Train Engineer überwacht werden. Die Portfolioebene umfasst längerfristige Strategien, Investitionsfinanzierungen und die Koordination mehrerer Programme im Einklang mit den Geschäftszielen.  

SAFe wurde erstmals 2011 von Dean Leffingwell formalisiert und hat sich seitdem zu einem der beliebtesten Frameworks für die Skalierung von Agile in grossen Organisationen entwickelt. Es nutzt Ideen aus Scrum, Kanban, Lean-Produktentwicklung und anderen agilen Methoden, kombiniert mit Systemdenken. Das Framework schreibt einen bestimmten Rhythmus vor (z. B. synchronisierte Sprints und Program Increments), die Abstimmung zwischen den Teams und Rollen wie Produktmanager und Systemarchitekten, um teamübergreifende Anliegen zu behandeln. SAFe bringt mehr Struktur und Planung in Agile, um Abhängigkeiten in grossem Massstab zu bewältigen, zielt aber darauf ab, den Fokus von Agile auf inkrementelle Lieferung und schnelles Feedback beizubehalten. (Es wurde jedoch kritisiert, dass es eine Hierarchie schafft und bei unflexibler Umsetzung möglicherweise die Agilität verringert.) 

Waterfall Modell 

Das Waterfall model  Wasserfallmodell ist eine traditionelle, planungsorientierte Softwareentwicklungsmethode. Beim Wasserfallmodell wird das Projekt in aufeinanderfolgende Phasen unterteilt, wie z. B. Anforderungserfassung, Entwurf, Implementierung, Test, Bereitstellung und Wartung, wobei jede Phase abgeschlossen sein muss, bevor die nächste beginnt. Der Fortschritt verläuft wie ein Wasserfall in eine Richtung, mit minimalen Iterationen zwischen den Phasen. Dieser Ansatz war einst die vorherrschende Methode in der Softwareentwicklung, aber aufgrund seiner starren Struktur wird er heute bei Softwareprojekten seltener angewendet. 

Beim Wasserfallmodell werden alle Anforderungen und Pläne im Voraus formuliert, und spätere Änderungen im Prozess können schwierig und kostspielig sein. Der Schwerpunkt liegt auf Vorhersehbarkeit und gründlicher Dokumentation: Sobald der Plan festgelegt ist, versucht das Team, ihn genau umzusetzen. Dies kann bei Projekten mit klar definierten Anforderungen und geringen zu erwartenden Änderungen gut funktionieren. Die mangelnde Flexibilität des Wasserfallmodells ist jedoch ein Nachteil bei Projekten, bei denen die Anforderungen ungewiss sind oder sich wahrscheinlich weiterentwickeln werden. Oft vergeht viel Zeit, bis der Kunde ein funktionierendes Produkt zu sehen bekommt (in der Regel erst nach Abschluss der Implementierungs- und Testphase). Da dynamische Softwareanforderungen mit diesem sequenziellen Ansatz nicht vollständig erfüllt werden konnten, entstanden als Reaktion darauf adaptivere Methoden wie Agile. Heute wird Wasserfall eher in Branchen oder Projekten eingesetzt, in denen strenge Vorschriften und Vorhersehbarkeit von grösster Bedeutung sind, oder in Kombination mit Agile in einem Hybridmodell. 

Scrumfall Approach 

Scrumfall auch bekannt als Water-Scrum-Fall, ist ein hybrider Projektabwicklungsansatz, der Elemente von Waterfall und Scrum kombiniert. In einem Scrumfall-Modell nutzen Teams die strukturierte Planung und Kontrolle von Waterfall zusammen mit den iterativen Entwicklungszyklen von Scrum. In der Praxis bedeutet dies oft, dass ein Projekt mit einer Vorausplanungsphase im Waterfall-Stil beginnt (Definition von Anforderungen, Umfang, Budget usw.), dann in eine agile Entwicklungsphase übergeht, in der die Arbeit in Scrum-Sprints erledigt wird, und schliesslich mit einer traditionellen Waterfall-ähnlichen Bereitstellungs-, Release- und Wartungsphase endet. Dieser Ansatz versucht, das „Beste aus beiden Welten” zu vereinen: die Vorhersehbarkeit und Top-Down-Kontrolle von Waterfall und die Flexibilität und schnelle Iteration von Agile. 

Unternehmen können Scrumfall einsetzen, wenn sie bestimmte Wasserfallprozesse benötigen (z. B. umfassende Vorausplanung oder feste Meilensteine aus Compliance-Gründen), aber auch die Vorteile der iterativen Entwicklung nutzen möchten. Beispielsweise kann das Management einen detaillierten Projektplan und die Genehmigung der Anforderungen (Wasserfall) vorschreiben, während das Entwicklungsteam das Produkt in zweiwöchigen Scrum-Sprints mit häufigen Demos für die Stakeholder entwickelt, bevor es in die finale Integrations- und Release-Phase geht. Scrumfall hat in den letzten Jahren als Kompromissansatz an Popularität gewonnen. Laut einer PMI-Umfrage stieg die Verwendung hybrider Methoden wie Scrumfall von 20 % der Projekte im Jahr 2020 auf 31 % der Projekte im Jahr 2024, was darauf hindeutet, dass viele Unternehmen einen Mehrwert in der Kombination von agilen und Wasserfall-Praktiken sehen. Vorteile: Scrumfall kann Agilität in der Entwicklung bieten und gleichzeitig das Bedürfnis des Managements nach Vorab-Sicherheit befriedigen. Nachteile: Es kann die Nachteile beider Ansätze mit sich bringen (z. B. hoher Planungsaufwand und potenzielle Einschränkung der Agilität in späteren Phasen). 

Wagile Methodik

Wagile (eine Wortkombination aus Waterfall und Agile) bezeichnet jeden hybriden Ansatz, der die strukturierten Phasen von Waterfall mit den iterativen Zyklen von Agile kombiniert. Der Begriff „WAgile” wird oft informell verwendet, um einen Projektmanagementstil zu beschreiben, bei dem einige Teile Waterfall und andere Agile folgen. Im Wesentlichen ist Wagile = Waterfall + Agile. Manchmal wird es auch einfach als hybrides Projektmanagement bezeichnet. Bei einer Wagile-Methodik können Teams à la carte auswählen, welche Agile-Praktiken sie in einen überwiegend Wasserfall-Prozess integrieren möchten (oder umgekehrt). So können beispielsweise Anforderungen und Design im Voraus festgelegt werden (Wasserfall-Stil), während Entwicklung und Tests in iterativen Agile-Sprints erfolgen. Oder ein Projekt könnte grösstenteils im Agile-Modus ablaufen, aber eine finale Bereitstellung haben, die sich wie eine traditionelle Big-Bang-Veröffentlichung anfühlt. 

Wagile-Ansätze sind entstanden, weil „eine Grösse für alle“ selten zutrifft – verschiedene Projekte oder Phasen können von unterschiedlichen Techniken profitieren. Ein Wagile-Prozess ermöglicht Flexibilität, um die Arbeitsweise an den Kontext anzupassen. Dieser Ansatz kann während Übergangsphasen nützlich sein (ein Unternehmen, das von Waterfall zu Agile wechselt, kann Praktiken schrittweise mischen) oder wenn verschiedene Teams (oder Subunternehmer) unterschiedliche Methoden für dasselbe Projekt verwenden. Das Hauptmerkmal von Wagile ist, dass innerhalb eines Projektlebenszyklus mehrere Lebenszyklusmodelle (vorausschauende und adaptive) zum Einsatz kommen. Wagile bietet zwar eine grössere Flexibilität, kann aber auch zu einer komplexeren Koordination führen, da die Teammitglieder sowohl mit der Wasserfall- als auch mit der Agile-Denkweise und den entsprechenden Tools vertraut sein müssen. 

Disciplined Agile Delivery (DAD) 

Disciplined Agile Delivery (DAD)  ist ein Prozess-Framework, das agile Prinzipien auf Unternehmensebene erweitert und Anleitungen zur Integration und Anpassung verschiedener Praktiken bietet. DAD wird als ein menschenorientierter, lernorientierter hybrider agiler Ansatz für die Bereitstellung von IT-Lösungen beschrieben und ist Teil des grösseren Disciplined Agile (DA)-Toolkits, das ursprünglich von Scott Ambler und Mark Lines entwickelt wurde. Im Gegensatz zu einer einzigen vorgeschriebenen Methodik ist DAD ein Toolkit mit Strategien, die aus Scrum, Kanban, Extreme Programming (XP), Agile Modeling, Lean und sogar traditionellen Methoden stammen. Es zeigt, wie diese Praktiken zu einem zusammenhängenden Ganzen zusammengefügt werden können, und ermutigt Teams, ihre Arbeitsweise (WoW) je nach Kontext zu wählen. 

DAD wurde entwickelt, um Lücken zu schliessen, die einzelne agile Frameworks (wie Scrum) nicht abdecken, insbesondere in grossen oder komplexen Unternehmen. Es deckt den gesamten Lieferzyklus ab (von der Konzeption bis zur Umstellung) und enthält Leitlinien zu Bereichen wie Architektur, Governance, DevOps und Portfoliomanagement, die oft ausserhalb des Anwendungsbereichs von Scrum liegen. Im Wesentlichen zielt DAD darauf ab, eine Grundlage zu schaffen, auf der Agile mit angemessener Strenge in einem Unternehmen skaliert werden kann. Experten haben DAD als „einen hybriden agilen Ansatz für die Bereitstellung von IT-Lösungen in Unternehmen beschrieben, der eine solide Grundlage für die Skalierung bietet”. Im Jahr 2019 hat das Project Management Institute (PMI) Disciplined Agile übernommen, was die wachsende Bedeutung hybrider agiler Frameworks im Mainstream-Projektmanagement signalisiert. 

Hybrid Project Management 

Hybrid project management ist ein Überbriff und bezeichnet die Kombination von Elementen verschiedener Projektmethodiken (in der Regel Agile und Waterfall) zur Erstellung eines massgeschneiderten Ansatzes. In der Praxis bedeutet ein hybrider Ansatz oft, dass Agile-Techniken innerhalb einer breiteren Waterfall-Struktur eingesetzt werden. So können beispielsweise übergeordnete Phasen und Meilensteine traditionell geplant werden, aber innerhalb dieser Phasen arbeiten die Teams iterativ oder wenden Agile-Praktiken an. Ein Projektmanager beschrieb dies als die Verwendung von Wasserfall für die insgesamt vorhersehbaren Aspekte und Agile für die unsicheren, innovativen Teile. Auf diese Weise kann ein Unternehmen die Anpassungsfähigkeit und häufigen Lieferungen von Agile nutzen und gleichzeitig feste Fristen oder Compliance-Anforderungen einhalten, die eine wasserfallähnliche Kontrolle erfordern. 

Hybride Ansätze werden immer beliebter, da Projekte immer komplexer und vielfältiger werden. Viele Branchen (Finanzwesen, Behörden usw.), die eine strenge Dokumentation erfordern oder externen regulatorischen Auflagen unterliegen, können reine Agile-Methoden nicht vollständig umsetzen, sodass eine Mischung eine praktische Lösung darstellt. Das hybride Modell gibt Projektmanagern die Freiheit, sich die besten Praktiken herauszusuchen: Beispielsweise die Beibehaltung eines traditionellen Anforderungsdokuments und eines Gantt-Diagramms (Wasserfall) neben Kanban-Boards oder Sprint-Backlogs (Agile). Wie bereits erwähnt, zeigen Untersuchungen des PMI, dass mittlerweile fast ein Drittel aller Projekte hybride Methoden verwenden. Der Erfolg eines Hybridmodells hängt davon ab, dass sorgfältig definiert wird, welche Teile des Projekts welchen Ansatz verwenden, und dass das Team versteht, wie es in diesem dualen Modus arbeiten muss. Wenn dies gut gemacht wird, kann es sowohl die Disziplin der Planung als auch die Reaktionsfähigkeit von Agile bieten. 

Lean Software Entwicklung

Lean Software Entwicklung ist ein Ansatz, der von den Prinzipien der schlanken Fertigung (wie sie von Toyota eingeführt wurden) inspiriert ist. Die Kernidee von Lean ist die Maximierung des Werts durch die Beseitigung von Verschwendung – d. h. die Eliminierung aller Aktivitäten oder Prozesse, die keinen Mehrwert für den Kunden schaffen. In der Softwareentwicklung konzentriert sich das Lean-Denken auf Effizienz und die Optimierung von Abläufen: nur das Notwendige tun und dies so effektiv wie möglich. Durch die Eliminierung von Verschwendung (unnötige Funktionen, Bürokratie, Wartezeiten usw.) können Teams schneller und mit höherer Qualität liefern. 

Die schlanke Softwareentwicklung orientiert sich an fünf Prinzipien: Wert definieren (aus Kundensicht), Wertstrom abbilden (Schritte zur Erbringung dieses Werts), Fluss schaffen (die wertschöpfenden Schritte kontinuierlich gestalten), Pull etablieren (nur nach Bedarf produzieren, gesteuert durch die Nachfrage) und Perfektion anstreben (kontinuierliche Verbesserung). Diese Prinzipien helfen Teams, systematisch Engpässe und Ineffizienzen zu finden. Lean wird oft als eine Denkweise angesehen, die andere Methoden überlagern kann – beispielsweise kann man Scrum oder Kanban auf „Lean”-Weise implementieren, indem man ständig unnötige Arbeit ausmerzt und Prozesse verbessert. Zu den Lean-Praktiken in der Softwareentwicklung gehören beispielsweise die Begrenzung der laufenden Arbeit, die Automatisierung sich wiederholender Aufgaben und die kontinuierliche Integration von Änderungen (um Wartezeiten und Nacharbeiten zu reduzieren). Insgesamt bietet die Lean-Entwicklung einen klaren Fokus darauf, nur das zu entwickeln, was der Kunde wirklich braucht, und die Art und Weise, wie das Team diesen Wert liefert, unermüdlich zu verbessern. 

Kanban Methodik 

Kanban ist eine Methode zur Verwaltung und Verbesserung von Arbeitsabläufen innerhalb eines Prozesses, insbesondere für Tätigkeiten wie die Softwareentwicklung. Kanban hat seinen Ursprung in der schlanken Fertigung und umfasst in der Softwareentwicklung die Visualisierung des Arbeitsablaufs auf einer Tafel (in der Regel mit Spalten, die die einzelnen Phasen darstellen, und Karten für die Arbeitsaufgaben) sowie die Begrenzung der Anzahl der laufenden Arbeiten (WIP) in jeder Phase. Der Schwerpunkt liegt auf einer Just-in-Time-Lieferung und darauf, die Teammitglieder nicht zu überlasten. Im Gegensatz zu Scrum gibt es bei Kanban keine vorgeschriebenen zeitlich begrenzten Iterationen; es handelt sich um ein kontinuierliches Flussmodell, bei dem neue Arbeit nach Massgabe der verfügbaren Kapazitäten aufgenommen wird und nicht nach einem festen Zeitplan. 

Ein einfaches Kanban-Board kann Spalten wie „Zu erledigen“, „In Bearbeitung“, „In Prüfung“ und „Erledigt“ enthalten. Die Teammitglieder nehmen die nächste Aufgabe aus einer Warteschlange, wenn sie ihre aktuelle Arbeit beendet haben, und halten dabei die WIP-Limits ein, um Qualität und Fokus zu gewährleisten. Durch die Visualisierung aller Arbeiten und die Festlegung von WIP-Limits werden Engpässe sichtbar (wenn sich beispielsweise die Spalte „In Prüfung“ ständig füllt, ist dies ein Hinweis darauf, dass Anpassungen erforderlich sind). Kanban ermutigt Teams, ihren Arbeitsfluss kontinuierlich zu messen und zu verbessern (mithilfe von Kennzahlen wie der Zykluszeit). Viele agile Teams verwenden Kanban-Boards, auch wenn sie nach Scrum arbeiten, um Sprint-Aufgaben zu visualisieren. Die Flexibilität von Kanban und die Betonung inkrementeller Veränderungen machen es zu einer beliebten Wahl für Teams, die sich ohne grösere Prozessumstellungen verbessern möchten. Zusammenfassend lässt sich sagen, dass Kanban den Arbeitsablauf visualisiert und es dem Team ermöglicht, Aufgaben in seinem eigenen Tempo abzuarbeiten, wodurch eine reibungslose Lieferung ohne Überlastung eines Teils der Pipeline gewährleistet wird. 

Extreme Programming (XP) 

Extreme Programming (XP) ist eine agile Methodik, die sich auf Software-Engineering-Praktiken und eine enge Zusammenarbeit mit den Kunden konzentriert, um die Softwarequalität und die Reaktionsfähigkeit auf sich ändernde Anforderungen zu verbessern. XP wurde Ende der 1990er Jahre von Kent Beck und anderen eingeführt und treibt bestimmte Praktiken auf die „extreme“ Spitze – daher auch der Name. Wenn beispielsweise die Codeüberprüfung gut ist, macht XP sie kontinuierlich (Paarprogrammierung); wenn das Testen gut ist, schreibt XP vor, dass Tests vor dem Code geschrieben werden müssen (testgetriebene Entwicklung). Die Methode basiert auf fünf Grundwerten: Kommunikation, Einfachheit, Feedback, Mut und Respekt. Durch die Betonung dieser Werte zielt XP darauf ab, ein gesundes, von hohem Vertrauen geprägtes Teamumfeld zu schaffen, das sich anpassen und qualitativ hochwertige Software produzieren kann. 

Zu den wichtigsten Praktiken von XP gehören Pair Programming (zwei Entwickler arbeiten gemeinsam an einem Arbeitsplatz, um gemeinsam Code zu schreiben), testgetriebene Entwicklung (TDD), kontinuierliche Integration, häufige Releases, einfaches Design, Refactoring und ein nachhaltiges Arbeitstempo. Der Kunde (oder sein Vertreter) ist eng in das Team eingebunden und liefert Anforderungen in Form von User Stories und kontinuierlichem Feedback zu den Iterationen. XP-Teams arbeiten in der Regel in sehr kurzen Zyklen (1–2 Wochen Iterationen) und liefern häufig Software aus. Das ultimative Ziel ist nicht nur ein Endprodukt von hoher Qualität, sondern auch ein Entwicklungsprozess, der die Qualität durchgehend aufrechterhält und die Arbeitserfahrung der Entwickler verbessert. Zwar können nicht alle Projekte jede XP-Praxis anwenden, doch haben seine Prinzipien des ständigen Feedbacks und der technischen Disziplin viele andere agile Frameworks beeinflusst. 

Feature-Driven Development (FDD) 

Feature-Driven Development (FDD) ist eine iterative und inkrementelle Softwareentwicklungsmethodik, die, wie der Name schon sagt, den Prozess auf die häufige Bereitstellung konkreter Funktionen (vom Kunden geschätzte Funktionalität) konzentriert. FDD wurde Ende der 1990er Jahre entwickelt (und ist damit ein frühes iteratives Modell, das als Vorläufer späterer agiler und schlanker Methoden gilt). Der Ansatz beginnt mit der Erstellung eines Gesamtmodells und einer Funktionsliste und setzt sich dann mit einer Reihe von zweiwöchigen Design- und Entwicklungszyklen fort, die sich jeweils auf eine bestimmte Funktion oder eine kleine Gruppe von Funktionen konzentrieren. 

In FDD werden Funktionen in der Regel in der Form „<Aktion> <Ergebnis> <Objekt>“ definiert
(z. B. „Gesamtkosten der Bestellung berechnen“). Der Prozess umfasst fünf grundlegende Schritte: Entwicklung eines Gesamtmodells, Erstellung einer Funktionsliste, Planung nach Funktionen, Entwurf nach Funktionen und Erstellung nach Funktionen. Die Teams arbeiten parallel an der Implementierung der Funktionen, soweit dies sinnvoll ist. FDD gilt als adaptiv, da es regelmässig funktionierende Features hervorbringt und Feedback einbezieht, aber auch ein strukturiertes, planorientiertes Gefühl vermittelt, da es eine gründliche Vorabmodellierung und Feature-Aufschlüsselung erfordert. Diese Kombination kann für Teams attraktiv sein, die sich ein klares Bild von den zu liefernden Ergebnissen mit festgelegten Terminen wünschen, aber dennoch an den Details iterieren möchten. Obwohl FDD heute nicht so häufig verwendet wird wie Frameworks wie Scrum, entspricht seine Betonung auf häufigen greifbaren Ergebnissen und adaptiver Planung den Agile-Prinzipien. Es zeigt einen wichtigen Punkt auf: Viele „neue” Agile-Ideen hatten frühere Formen (die häufige Lieferung und Anpassung von FDD war eine Inspiration für spätere Methodiken). 

DevOps Praktik

DevOps  ist eine Reihe von Praktiken (und eine kulturelle Philosophie), die Softwareentwicklung (Dev) und IT-Betrieb (Ops) miteinander verbindet. Das Ziel von DevOps ist es, den Lebenszyklus der Systementwicklung zu verkürzen und eine kontinuierliche Bereitstellung hochwertiger Software zu gewährleisten. In traditionellen Strukturen arbeiteten Entwicklungsteams (die den Code schreiben) und Betriebsteams (die die Systeme bereitstellen und warten) isoliert voneinander, was oft zu langsamen und problematischen Releases führte. DevOps überbrückt diese Kluft, indem es die Zusammenarbeit, Automatisierung und Überwachung während des gesamten Prozesses fördert. Es wird oft als ein fortlaufender Kreislauf aus Planung, Codierung, Erstellung, Testen, Release, Bereitstellung, Betrieb und Überwachung dargestellt – mit kontinuierlichem Feedback in allen Phasen. 

Zu den wichtigsten DevOps-Praktiken gehören Continuous Integration (CI), Continuous Delivery/Deployment (CD) (siehe unten), Infrastructure as Code, automatisierte Tests und proaktive Überwachung. Organisatorisch kann DevOps funktionsübergreifende Teams umfassen, denen sowohl Entwickler als auch Betriebsingenieure angehören, oder die Übernahme von Prinzipien des Site Reliability Engineering (SRE). Durch die Verbesserung der Kommunikation und den Abbau von Barrieren zwischen Entwicklung und Betrieb können Teams Probleme früher erkennen, häufiger bereitstellen und schneller auf Kundenbedürfnisse reagieren. Die DevOps-Denkweise legt auch Wert auf Kundenfeedback und iterative Verbesserungen und steht damit im Einklang mit agilen Philosophien. DevOps geht jedoch über die Entwicklung hinaus und umfasst auch den Betrieb von Software, um sicherzustellen, dass häufige Updates und Änderungen zuverlässig und sicher an die Benutzer ausgeliefert werden können. Im Wesentlichen ermöglichen DevOps-Praktiken die kontinuierliche Bereitstellung von Mehrwert für Kunden, indem sie Bereitstellung und Betrieb als integralen Bestandteil des Entwicklungsprozesses und nicht als nachträglichen Einfall betrachten.  

Continuous Integration/Continuous Deployment (CI/CD) 

Continuous Integration (CI) and Continuous Deployment (or Continuous Delivery, CD)
sind eng miteinander verbundene Praktiken unter dem Dach von DevOps, die schnelle und zuverlässige Software-Releases ermöglichen. Kontinuierliche Integration ist die Praxis, Codeänderungen von mehreren Entwicklern mehrmals täglich in einem gemeinsamen Repository zusammenzuführen, wobei jede Zusammenführung einen automatisierten Build- und Testprozess auslöst. Die Idee dahinter ist, Integrationsprobleme frühzeitig zu erkennen, denn wenn ein neu integrierter Code-Commit dazu führt, dass ein Test fehlschlägt oder ein Build unterbrochen wird, wird dies sofort erkannt und kann behoben werden. CI stellt sicher, dass die Codebasis immer in einem funktionsfähigen Zustand ist, und reduziert das Problem „Auf meinem Rechner funktioniert es“, indem Änderungen kontinuierlich in einer sauberen Umgebung validiert werden. 

Rapid Application Development (RAD) 

Rapid Application Development (RAD)  ist ein Softwareentwicklungsansatz, der schnelles Prototyping und iterative Entwicklung gegenüber umfangreicher Planung in den Vordergrund stellt. RAD entstand in den 1980er und 1990er Jahren als Reaktion auf das schwerfällige Wasserfallmodell und zielte darauf ab, Software schneller und unter stärkerer Einbeziehung der Nutzer zu entwickeln. In einem RAD-Projekt sammelt das Team grundlegende Anforderungen und erstellt dann schnell eine Reihe von Prototypen oder Teillösungen, die von den Endnutzern bewertet werden. Das Feedback wird schnell gesammelt und zur Verfeinerung der nächsten Iteration verwendet. Dieser Zyklus wiederholt sich, bis das Produkt den Anforderungen der Benutzer entspricht. Der Schwerpunkt liegt auf Geschwindigkeit und Flexibilität, auch wenn dies einige Kompromisse bei den Funktionen oder der Eleganz des Designs bedeutet, um schneller eine nutzbare Software liefern zu können. 

RAD umfasst in der Regel kleine, fokussierte Teams und nutzt häufig Tools, die eine schnelle Entwicklung ermöglichen (wie visuelle Programmierumgebungen oder Codegeneratoren). Die Einbindung der Nutzer ist hoch; von den Stakeholdern wird erwartet, dass sie kontinuierlich Feedback zu den sich entwickelnden Prototypen geben. Aufgrund seiner Ausrichtung auf kurze Entwicklungszyklen eignet sich RAD am besten für Projekte, die anfangs nicht klar definiert sind oder einen begrenzten Umfang haben und bei denen sich die Anforderungen ändern können, wenn die Nutzer die Prototypen sehen. Es ist ideal für kleinere Projekte mit klar definierten Zielen, die schnelle Ergebnisse und häufige Anpassungen erfordern. RAD kann jedoch für sehr grosse, sicherheitskritische oder stark strukturierte Projekte, bei denen umfassende Anforderungen und Dokumentationen erforderlich sind, weniger geeignet sein. In moderner Hinsicht verkörpern viele agile Praktiken den Geist von RAD, aber RAD als eigenständiger Begriff hebt die Priorität der Entwicklungsgeschwindigkeit und des Nutzer-Feedbacks gegenüber formalen Prozessen hervor. 

Large-Scale-Scrum (LeSS)

Large-Scale Scrum (LeSS) ist ein Rahmenwerk zur Skalierung von Scrum auf grosse Produktentwicklungsgruppen (Dutzende oder sogar Hunderte von Personen), wobei die Leichtigkeit und Anpassungsfähigkeit von Scrum erhalten bleibt. Die Kernidee von LeSS ist, dass Scrum auch bei einer Skalierung Scrum bleibt, d. h. es wird versucht, so wenig wie möglich über das Standard-Scrum-Modell für ein Team hinaus hinzuzufügen. Im Wesentlichen ist LeSS eine skalierte Version des traditionellen Scrum, bei der die Scrum-Prinzipien auf mehrere Teams angewendet werden, die an einem Produkt arbeiten. Es gibt zwei Varianten: LeSS (für 2–8 Teams) und LeSS Huge (für Hunderte von Entwicklern, die in viele Teams aufgeteilt sind). Beide Varianten behalten einen einzigen Produktfokus bei: In der Regel überwacht ein Product Owner das gesamte Produkt-Backlog für alle Teams. 

Unter LeSS arbeiten alle Teams im gleichen Sprint-Rhythmus und produzieren wie beim normalen Scrum in jedem Sprint ein lieferbares Produktinkrement. Es gibt einige Koordinierungsmechanismen, beispielsweise schlägt LeSS eine gemeinsame Sprintplanung (Teil 1) mit Vertretern aller Teams vor, um zu entscheiden, welches Team welche Aufgaben übernimmt, gefolgt von der Sprintplanung jedes einzelnen Teams (Teil 2). In ähnlicher Weise sind alle Teams oder ihre Vertreter an einer gemeinsamen Sprint-Überprüfung und einer gemeinsamen Retrospektive beteiligt. Die Idee dahinter ist, die Koordination zu verbessern und gleichzeitig den Teams zu ermöglichen, sich selbst zu organisieren und direkt zu kommunizieren, anstatt zusätzliche Managementebenen hinzuzufügen. Durch funktionsübergreifende Teams und die Vermeidung spezialisierter Komponententeams versucht LeSS, Komplexität und Übergaben zu reduzieren. Zusammenfassend lässt sich sagen, dass LeSS den empirischen Ansatz und die funktionsübergreifende Teamarbeit von Scrum in grossem Massstab nutzt, wobei zusätzliche Rollen oder Artefakte auf ein Minimum reduziert werden. Im Gegensatz zu eher präskriptiven Skalierungsframeworks legt LeSS den Schwerpunkt auf Vereinfachung („mehr mit LeSS”) und Lean Thinking, um Bürokratie zu vermeiden, ohne dabei die Notwendigkeit der Abstimmung zwischen mehreren Teams ausser Acht zu lassen. 

Spotify Squad Framework 

Das Spotify Squad Framework, Das oft einfach als „Spotify-Modell“ bezeichnete Konzept ist ein Ansatz zur Skalierung von Agile, der bekannt wurde, nachdem Spotify ihn um 2012 herum vorgestellt hatte. Es handelt sich dabei nicht um ein formales Framework, sondern vielmehr um eine Beschreibung, wie Spotify seine Teams im Hinblick auf Agilität und Innovation organisiert hat. Das Spotify-Modell ist menschenorientiert und auf Autonomie ausgerichtet und betont eine starke Ingenieurskultur und Kommunikationsnetzwerke gegenüber starren Prozessen. Die Struktur führte neue Begriffe für die Teamorganisation ein: Squads, Tribes, Chapters und Guilds. 

In diesem Modell ist ein Squad die grundlegende Entwicklungseinheit, ein kleines funktionsübergreifendes, selbstorganisiertes Team (in der Regel <10 Personen), das für eine bestimmte Funktion oder einen bestimmten Bereich verantwortlich ist. Jedes Squad wählt seine eigene Arbeitsweise (das kann Scrum, Kanban oder jede andere agile Technik sein, die zu ihm passt) und hat einen Agile Coach und einen Product Owner. Ein Tribe ist eine Sammlung von Squads (in der Regel bis zu 100 Personen), die in verwandten Bereichen arbeiten. Tribes dienen dazu, die Abstimmung und Zusammenarbeit zwischen Squads sicherzustellen, die an einem grösseren Produkt oder einer grösseren Produktfamilie arbeiten. Innerhalb eines Tribes ist ein Chapter eine Gruppe von Spezialisten aus verschiedenen Squads (zum Beispiel können alle Tester oder alle Frontend-Entwickler in verschiedenen Squads ein Chapter bilden) – Chapters sind horizontale Gruppierungen, die Wissen, Standards und möglicherweise einen Vorgesetzten teilen. Gilden sind informelle Interessengemeinschaften, die sich über die gesamte Organisation erstrecken (z. B. eine Gilde für DevOps-Praktiken oder eine Gilde für mobile Entwickler), in denen Menschen freiwillig Best Practices und Ideen austauschen. 

Dieses Spotify-Modell ermöglicht es einem grossen Unternehmen, die Agilität vieler kleiner, autonomer Teams zu bewahren und gleichzeitig genügend Struktur und Wissensaustausch zu fördern, um aufeinander abgestimmt zu bleiben. Die Philosophie von Spotify war, dass die Gewährung von Autonomie (mit Verantwortlichkeit) den Teams mehr Engagement und Innovationskraft verleihen würde. Es gibt keine von oben vorgeschriebenen „Zeremonien“; den Teams wird vertraut, dass sie agile Rituale nach Bedarf durchführen. Viele Unternehmen bewunderten das Spotify-Modell aufgrund seiner Erfolgsgeschichte und versuchten, es nachzuahmen, obwohl Spotify selbst sich in den letzten Jahren über dieses Modell hinaus weiterentwickelt hat. Das Modell lehrte die Branche, wie wichtig es ist, Teams durch Kultur und Organisationsdesign statt durch einen strengen Skalierungsprozess aufeinander abzustimmen – „Ausrichtung ermöglicht Autonomie”, wie sie es formulieren. Zwar kann nicht jedes Unternehmen die Struktur von Spotify vollständig kopieren, doch die Konzepte von Squads/Tribes und Chapter/Guilds haben die Art und Weise beeinflusst, wie moderne Technologieunternehmen über die Skalierung agiler Teams denken. 

Fazit

In der Softwareentwicklungsmethodik gibt es keine Einheitslösung. Jedes Delivery-Modell ob Wasserfall, Agile oder Hybrid hat Stärken, die es für bestimmte Projektarten und Unternehmenskulturen geeignet machen. Moderne Softwareentwicklung beinhaltet oft eine Mischung verschiedener Techniken: zum Beispiel die Verwendung von Agile-Sprints innerhalb eines Wasserfall-Vertrags oder die Einführung von DevOps-Automatisierung neben Scrum-Teamarbeit. Wie bereits erwähnt, entwickeln viele Teams ihren eigenen einzigartigen Prozess, indem sie Frameworks kombinieren und ihren Ansatz kontinuierlich optimieren. Der Schlüssel zum Erfolg liegt darin, angesichts sich ändernder Anforderungen agil zu bleiben und gleichzeitig eine ausreichende Planung und Qualitätskontrolle sicherzustellen. Durch das Verständnis des Spektrums an Liefermodellen, von traditionellen bis hin zu Agile, einschliesslich skalierter und hybrider Varianten, können Unternehmen die Praktiken auswählen und anpassen, die ihren Kunden den grössten Mehrwert bieten. Das ultimative Ziel ist ein Prozess, der es dem Team ermöglicht, qualitativ hochwertige Software effizient zu liefern und auf Veränderungen zu reagieren, unabhängig davon, ob dieser Prozess streng nach Vorschrift oder als sich weiterentwickelnde Mischung aus verschiedenen Methoden erfolgt.