Low-Code-Anpassung an Agile in einer Woche

Eine Low-Code-Plattform für Agile anpassen: Eine einwöchige Transformation

Low-Code-Plattformen ermöglichen schnelle Prozessanpassungen, um sich wandelnden Geschäftsanforderungen gerecht zu werden. In nur einer Woche passte ein Team ein auf Wasserfall ausgerichtetes ITSM 365-System an die Agile-Methodik an, indem es Sprints, Scrum-Boards und Backlogs hinzufügte. Dies löste Probleme mit mehreren Tools und manueller Dateneingabe und sparte Lizenzkosten und Zeit.

Ein typisches Szenario: Ein Unternehmen kauft ein System für Wasserfall-Projekte, dann wechselt die F&E-Abteilung zu Scrum, und das Marketing übernimmt Kanban. Das Ergebnis sind drei separate Tools mit jährlichen Kosten von rund 1 Million Euro plus manueller Datensynchronisierung.

Probleme mit starren Systemen und Low-Code-Lösungen

Starre Systeme erfordern separate Projekte für Änderungen, zwingen Prozesse, sich dem Tool anzupassen, und überlasten die Benutzeroberfläche.

Problem 1: Änderungen als separates Projekt.

Das Hinzufügen eines "Risiken"-Feldes dauert Monate. Mit Low-Code: Ein Administrator erstellt ein benutzerdefiniertes Feld im visuellen Editor in Minuten – ein Listentyp mit den Werten "Niedrig/Mittel/Hoch/Kritisch".

Problem 2: Prozesse passen sich dem System an.

Scrum-Sprints imitieren Phasen, wodurch Boards und Prioritäten verloren gehen. Mit Low-Code: Eine neue "Sprint"-Entität, parallel zum Gantt-Diagramm.

Problem 3: Überladene Benutzeroberfläche.

In einer Wasserfall-Aufgabenkarte sind Story Points unter Budget- und Ressourcenfeldern versteckt. Lösung: Eine separate Agile-Ansicht mit relevanten Feldern.

Problem 4: Fehlende Skalierbarkeit.

Unternehmenswachstum führt zu Methodikanpassungen und zusätzlichen Kosten. Low-Code erweitert sich mit Modulen ohne Migrationen.

Das Wesen von Low-Code für Projektmanagement

Die Grundkonfiguration deckt 70–80 % der Anforderungen ab: Projekt-Phase-Aufgaben-Hierarchie, Gantt-Diagramme, kritischer Pfad, Aufwandsverfolgung, Dashboards.

Low-Code fügt hinzu:

• Neue Entitäten (Sprint, User Story);
• Schnittstellen (Scrum-Boards);
• Automatisierung (Trigger, berechnete Felder);
• Benutzerdefinierte Metriken.

Konfigurationsverhältnis:

• 80 % – visueller Editor;
• 15 % – einfache Skripte;
• 5 % – Entwickler.

Schritt-für-Schritt-Agile-Transformation

Schritt 1: "Sprint"-Entität.

Neuer Projekttyp "Agile". Attribute:

• Name (Sprint 1);
• Ziel;
• Dauer (2 Wochen).

Wasserfall-Phasen sind ausgeblendet.

Schritt 2: Anpassen von "Aufgabe".

Felder:

• Verknüpfung zum Sprint;
• Typ (User Story/Bug/Technische Aufgabe);
• Schätzung (Tage/Stunden).

Optional: Story Points, Akzeptanzkriterien.

Schritt 3: Scrum-Board.

Neue Ansicht "Board":

• Spalten: Erstellt/In Bearbeitung/Code Review/Test/Erledigt;
• Gruppierung nach Verantwortlichen;
• Farben nach Typ;
• Kartenfelder: Nummer, Betreff, Priorität, Avatar, Schätzung, Frist.

Schritt 4: Backlog.

Liste mit Filter "sprint = leer". Spalten: Nummer, Betreff, Status, Verantwortlicher, Priorität, Frist. Massenzuweisung zu Sprints, Sortierung, Filter.

Der "Sprints"-Tab zeigt Aufgaben nach Aufschlüsselung, Liste der Sprints.

Wichtige Erkenntnisse

• Einsparungen: Ein System statt drei – minus 1 Million Euro/Jahr an Lizenzen und manueller Arbeit;
• Geschwindigkeit: 80 % der Änderungen ohne Code, Transformation in einer Woche;
• Skalierbarkeit: Unterstützung für Wasserfall/Agile/Kanban-Mix ohne Migrationen;
• Effizienz: Reduziertes Shadow IT, kognitive Belastung, Fehler;
• Automatisierung: Trigger, Dashboards für Routineaufgaben.

Eine solche Anpassung bewahrt die Grundfunktionalität für klassische Projekte und fügt Agile ohne Datenverlust hinzu.

— Editorial Team