Sie steigen an der Stelle ein, die zu Ihrem Vorhaben passt — und können nach jeder Phase neu entscheiden.
Zusammenarbeit · Vorgehen
Unser Vorgehensmodell: vier klare Phasen.
Scrum in der Entwicklung, Kanban im Betrieb. Sie sehen im Sprint-Review lauffähige Software — und wissen an jedem Punkt, wo Ihr Projekt steht.
Die vier Phasen
Vom Zielbild zum laufenden Betrieb.
01
Discovery
Zwei bis drei Workshops mit Ihren Stakeholdern klären das Was und Warum. Ergebnis: User Story Map, Architekturskizze, priorisiertes Backlog und Budget-Indikation. Danach können Sie das Projekt jederzeit stoppen — Sie haben trotzdem ein verwertbares Konzept.
Discovery im Detail02
Inception
Sprint 0 schafft die Grundlage: Entwicklungs- und Testumgebungen, CI/CD-Pipelines, finale Stack-Entscheidung, Schnittstellen-Mocks und eine gemeinsam vereinbarte Definition of Done.
03
Build
Produktionsreifer Code in Inkrementen. Am Sprint-Ende zeigen wir lauffähige Software, Sie geben auf Staging ab. Priorisierung und Reihenfolge stimmen wir laufend ab; das Qualitätsniveau bleibt konstant.
Agile Entwicklung im Detail04
Run
Nach dem Go-Live wechseln wir auf Kanban: Störungen, kleine Änderungen und Weiterentwicklung laufen im Fluss. Den vollständigen 24/7-Betrieb übernimmt auf Wunsch sd3 technology.
Rollout und Betrieb im Detail16Wochen
Ziel bis zum stabilen MVP-Release — sechs bis acht Sprints.
10Arbeitstage
je Sprint — von Planung bis Review.
2Wochen
Sprintlänge, mit Review und Retrospektive am Ende.
4Augen
prüfen jede Änderung, bevor sie in den Hauptzweig geht.
Arbeitsprinzipien
Woran Sie unsere Arbeitsweise erkennen.
Vier Regeln, die auch dann gelten, wenn es im Projekt eng wird.
01Lauffähige Software im Review
Fortschritt zeigt sich am Produkt. Was im Review nicht läuft, gilt als nicht fertig.
Demo auf StagingAbnahme durch den Fachbereich
02Vier-Augen-Prinzip
Keine Änderung geht ungeprüft in den Hauptzweig — auch dann nicht, wenn sie klein aussieht oder eilig ist.
Reviews im TeamArchitekt eingebunden
03Testpyramide mit klaren Stufen
Automatisierte Tests auf allen Ebenen sichern das Verhalten ab. Sie sind die Voraussetzung dafür, dass wir schnell bleiben können.
CI bricht bei RotRegression abgesichert
04Transparenz nach außen
Sie sehen Commit-Historie, Backlog und Board jederzeit ein. Probleme sprechen wir früh an.
Kein Reporting-TheaterEskalation zur Geschäftsführung
Rollen
Wer im Projekt woran arbeitet.
Kleine Teams, klare Verantwortung — und eine Ansprechperson, die den Überblick behält.
Product Owner bei Ihnen
Sie priorisieren, was den größten Nutzen bringt. Wir unterstützen bei Formulierung und Schnitt der Anforderungen, entscheiden aber nicht über Ihr Geschäft.
Architekt bei uns
Verantwortet die technische Linie über Sprints hinweg: Struktur, Schnittstellen, Sicherheit, Wartbarkeit — und ist in jedem Projekt fix eingeplant.
Eingespieltes Entwicklerteam
Feste, eingespielte Personen im Projektteam. Fällt jemand aus, kompensieren wir das — das ist unsere Ergebnisverantwortung.
Betrieb aus der Gruppe
Für Monitoring, Patching und Helpdesk übernimmt sd3 technology. Sie behalten eine Ansprechperson, auch wenn zwei Firmen beteiligt sind.
KI in der Entwicklung
Versprechen an Ihren CTO
Pragmatisch agil, nah am Projekt.
-
Priorisierung bleibt verhandelbar — das Qualitätsniveau nicht.
-
Ausfälle kompensieren wir, ohne dass die Zusage kippt.
-
Neue Technologie? Dann liefern wir zuerst einen Proof of Concept.
Verzögert eine Anforderung den Live-Gang, priorisieren wir im engen Austausch pragmatisch um.
Vertragliche Rahmenbedingungen
Code, Komponenten und Nutzungsrechte klar geregelt.
Bei individuellen Softwarelösungen unterscheiden wir zwischen dem kundenspezifischen Anteil und wiederverwendbaren technischen Bausteinen. Was davon wie geregelt wird, hängt vom Projekt und vom Vertrag ab — deshalb steht es hier als Gesprächsgrundlage.
01Individuell für Sie entwickelt
Der individuell für einen Kunden entwickelte oder kundenspezifisch angepasste Teil wird entsprechend der vertraglichen Vereinbarung für den Kunden geregelt.
02red.soft-Komponenten
Basiert eine Lösung teilweise auf eigenen red.soft-Bausteinen, verbleiben diese grundsätzlich bei red.soft, sofern vertraglich nichts anderes vereinbart ist.
03Basiskomponenten Dritter
Lizenzierte Basisbestandteile bleiben beim jeweiligen Lizenzgeber. Welche Komponenten im Einsatz sind, legen wir offen.
04Erweiterbar je Projekt
Erweiterte Nutzungsrechte, Erwerbsmöglichkeiten für bestimmte Bestandteile, Übergabe- und Exit-Regelungen, Quellcode-Übergabe oder Escrow-Vereinbarungen.
Entscheidend ist eine transparente Regelung, die zum Projekt, zum Betriebsmodell und zu den langfristigen Anforderungen passt. Die konkrete Ausgestaltung klären wir vor Projektstart schriftlich.
Häufige Fragen
Häufige Fragen zum Vorgehen.
Nächster Schritt
Sprechen wir über Ihr Vorhaben.
Der kleinste sinnvolle Schritt ist ein gemeinsamer Workshop. Danach wissen Sie, was Ihr Vorhaben grob kostet — und wir, ob wir die Richtigen dafür sind.