KANBAN und WirkOps

# Ausgangslage

BANAN AI erhält scheinbar einen simplen Auftrag:

> „Entwickelt eine mobile Kantinen-App.“

Funktional zunächst trivial:

* Speiseplan anzeigen

* Standort wählen

* Favoriten speichern

* Push-Nachrichten

* Offline-Funktion

Dann folgt der sicherheitskritische Einschlag:

> Die App wird als VS-NfD eingestuft.

Begründung:

* Bewegungsprofile von Sicherheitskräften

* Routinen & Aufenthaltsmuster

* potenzielle Angriffsvektoren

* Informationsaggregation

* Behördenkontext

Dadurch verändert sich das Projekt fundamental:

Von:

* einfacher Mobile App

Zu:

* sicherheitskritischem Service-System.

Und genau hier zeigt sich die Stärke von WirkOps + KANBAN.

Denn SCRUM würde jetzt typischerweise versuchen:

* Sprintplanung,

* Story Points,

* Velocity,

* Sprint Commitments

aufrechtzuerhalten —

während die Realität explodiert.

KANBAN dagegen erlaubt:

* dynamische Priorisierung,

* emergente Sicherheitsanforderungen,

* Architektur-Lernschleifen,

* kontinuierliche Flow-Steuerung.

—

# Grundprinzip des WirkOps-KANBAN-Setups

Das Team wird nicht nach Hierarchie gebaut —

sondern nach:

* Wirkungslogiken,

* Flow-Funktion,

* Systemverantwortung.

Die Rollen entstehen also aus:

* Fachrolle

* * Wirkprofil

* * Belbin-Teamrolle.

—

# Das Team

## 1. Coordinator (integrativ/strategisch)

### Rolle:

Lead Service Manager

### Wirkprofil:

Integrativ + strategisch

### Aufgabe:

* hält Gesamtfluss stabil

* verbindet Security, Architektur und Delivery

* moderiert Priorisierung

* schützt Team vor Eskalationschaos

* organisiert Situational Awareness

### Typischer Satz:

> „Bevor wir optimieren, brauchen wir gemeinsames Lageverständnis.“

—

# 2. Monitor Evaluator (strategisch)

### Rolle:

Enterprise Lead Architect

### Wirkprofil:

Strategisch

### Aufgabe:

* bewertet Risiken

* erkennt Architekturfolgen

* verhindert Schnellschüsse

* analysiert Sicherheitsimplikationen

### Typischer Satz:

> „Die eigentliche Gefahr liegt nicht in der App — sondern in den Metadaten.“

—

# 3. Specialist (strategisch)

### Rolle:

Security Architect

### Wirkprofil:

Strategisch

### Aufgabe:

* erstellt Sicherheitskonzept

* BSI-/VS-NfD-Konformität

* Kryptographie

* Zero-Trust-Design

* Mobile Hardening

### Typischer Satz:

> „Offline-Caching ist jetzt plötzlich ein Sicherheitsproblem.“

—

# 4. Plant (strategisch/kreativ)

### Rolle:

Service Architect

### Wirkprofil:

Strategisch-kreativ

### Aufgabe:

* entwirft innovative Lösungswege

* findet Architekturkompromisse

* reduziert Komplexität

* entwickelt sichere UX-Konzepte

### Typischer Satz:

> „Warum zeigen wir überhaupt personenbezogene Präferenzen an?“

—

# 5. Shaper (operativ)

### Rolle:

Operativer Service Manager

### Wirkprofil:

Rot

### Aufgabe:

* treibt Delivery

* beseitigt Blocker

* eskaliert Entscheidungen

* verhindert Analyse-Lähmung

### Typischer Satz:

> „Wir diskutieren seit drei Tagen über Token-Lifetime.“

—

# 6. Implementer (operativ)

### Rolle:

Systems Engineer

### Wirkprofil:

Operativ-pragmatisch

### Aufgabe:

* CI/CD

* Mobile Device Integration

* Deployment

* Infrastruktur

* Betriebsfähigkeit

### Typischer Satz:

> „Ich brauche jetzt ein deploybares Zielbild.“

—

# 7. Completer Finisher (operativ/strategisch)

### Rolle:

Process Engineer

### Wirkprofil:

Blau-rot

### Aufgabe:

* Qualitätskontrolle

* Prozesssicherheit

* Auditfähigkeit

* Dokumentationsqualität

* Nachvollziehbarkeit

### Typischer Satz:

> „Wenn das BSI-Audit kommt, brauchen wir Beweise — nicht gute Absichten.“

—

# 8. Teamworker (integrativ)

### Rolle:

Integrativer Service Manager

### Wirkprofil:

Grün

### Aufgabe:

* reduziert Spannungen

* moderiert Konflikte

* schützt Zusammenarbeit

* synchronisiert Kommunikation

### Typischer Satz:

> „Security und Operations reden gerade aneinander vorbei.“

—

# 9. Resource Investigator (integrativ/operativ)

### Rolle:

Service Manager mit Behörden- und Lieferantennetzwerk

### Wirkprofil:

Grün-rot

### Aufgabe:

* Schnittstelle zu:

* Behörden

* Kantinenbetreiber

* MDM-Anbieter

* Zertifizierungsstellen

* beschafft Informationen

* erkennt externe Risiken früh

### Typischer Satz:

> „Das BSI hat letzte Woche neue Mobile-Härtungsvorgaben veröffentlicht.“

—

# KANBAN-Setup

Jetzt beginnt das eigentlich Interessante.

Das Team arbeitet NICHT in Sprints.

Sondern im kontinuierlichen Flow.

—

# Das Board

| ——- | ——- | ————— | ———– | ——— | ———– | ———— | ———- | ——- |

—

# WIP-Limits

Sehr wichtig.

| Spalte | WIP |

| ————— | — |

| Analyse | 3 |

| Security Review | 2 |

| Architektur | 2 |

| Umsetzung | 4 |

| Audit | 1 |

Warum?

Weil VS-NfD-Projekte typischerweise sterben an:

* Parallelisierung,

* Kontextwechsel,

* Audit-Stau,

* Sicherheits-Nacharbeit.

—

# Phase 1 – Projektstart

## Eingang

Die ersten Anforderungen kommen rein:

* Speiseplan anzeigen

* Push-Funktion

* Favoriten

* Offline-Nutzung

Der Shaper sagt:

> „Easy. Zwei Monate.“

Dann schlägt der Security Architect Alarm.

Neue Karten entstehen:

* Bedrohungsanalyse

* BSI-Klassifizierung

* Offline-Risikoanalyse

* Device Binding

* Zertifikatsmanagement

* Logging-Konzept

* Rollenmodell

* Härtungskonzept

* Audit-Trail

* Incident-Konzept

Plötzlich wächst das Board explosionsartig.

—

# WirkOps-Moment Nr. 1

Der rote Shaper will sofort liefern.

Der blaue Specialist stoppt:

> „Wir kennen die regulatorischen Auswirkungen noch nicht.“

Konflikt entsteht.

Der Teamworker moderiert.

Der Coordinator übersetzt:

> „Wir haben kein Delivery-Problem. Wir haben ein Unsicherheitsproblem.“

Das ist typische WirkOps-Arbeit:

Nicht Prozesse lösen Konflikte —

sondern komplementäre Wirkungsprofile.

—

# Phase 2 – Flow stabilisieren

Das Team erkennt:

Security Review wird zum Engpass.

Der Security Architect blockiert ständig Karten.

KANBAN macht das sichtbar.

Im SCRUM-Setup wäre das oft verborgen bis Sprintende.

—

# Reaktion nach KANBAN-Logik

Nicht:

> „Security muss schneller arbeiten.“

Sondern:

> „Das System ist falsch entkoppelt.“

Also entstehen neue Policies:

* Security-by-Design-Templates

* Vorvalidierte Architekturpatterns

* Definition-of-Ready für Security

* Automatisierte Compliance Checks

Der Process Engineer standardisiert diese Regeln.

—

# WirkOps-Moment Nr. 2

Der Plant entwickelt eine Idee:

> „Wir speichern keine individuellen Daten lokal. Nur signierte Tagespakete.“

Der Specialist ergänzt:

> „Dann reduzieren wir die VS-NfD-Angriffsfläche massiv.“

Der Implementer sagt:

> „Das kann ich automatisiert deployen.“

Hier entsteht emergente Systemintelligenz.

Nicht durch Meetings —

sondern durch Flow + Rollenkomplementarität.

—

# Phase 3 – Eskalation

Dann passiert der Klassiker.

Das BSI fordert plötzlich:

* vollständige Offline-Sperrung

* Device-Attestation

* verpflichtende Zertifikatsrotation

Das zerlegt die bisherige Architektur.

SCRUM würde jetzt oft implodieren:

* Sprintziel kaputt

* Velocity zerstört

* Replanning

* Scope-Diskussionen

KANBAN dagegen absorbiert das einfacher.

Neue Karten werden priorisiert.

WIP-Limits verhindern Panik-Multitasking.

—

# WirkOps-Moment Nr. 3

Jetzt zeigt sich der Unterschied der Wirkprofile brutal.

## Rot (Shaper)

will:

* sofortige Umstellung

* Taskforce

* Nachtschichten

## Blau (Monitor Evaluator)

warnt:

* Architekturbruch

* technische Schulden

* Sicherheitslücken

## Grün (Teamworker)

erkennt:

* Teamstress

* beginnende Schuldzuweisungen

Der Coordinator stabilisiert:

> „Wir optimieren jetzt nicht Geschwindigkeit — sondern Entscheidungsqualität.“

—

# Phase 4 – Betriebsintegration

Jetzt kommen Operations-Themen:

* Monitoring

* SIEM-Anbindung

* Zertifikatsabläufe

* Mobile Device Compliance

* Incident Runbooks

Der Systems Engineer übernimmt Flow-Führung.

KANBAN verschiebt sich jetzt von:

* Feature-Flow

zu:

* Betriebs-Flow.

Das ist typisch.

—

# Entscheidender WirkOps-Effekt

Die Rollen bleiben —

aber ihre Dominanz verschiebt sich je Phase.

| Phase | Dominante Rollen |

| —————— | —————————— |

| Initiale Idee | Plant / Resource Investigator |

| Sicherheitsklärung | Specialist / Monitor Evaluator |

| Delivery | Shaper / Implementer |

| Stabilisierung | Teamworker / Coordinator |

| Audit | Completer Finisher |

| Betrieb | Implementer / Coordinator |

Das ist der eigentliche WirkOps-Kern:

> Teams sind keine statischen Kästchen —

> sondern dynamische Wirkungsfelder.

—

# Warum KANBAN hier hervorragend funktioniert

Weil das Projekt:

* emergente Risiken besitzt,

* regulatorisch volatil ist,

* hohe Unsicherheit hat,

* stark interrupt-getrieben wird,

* Architektur-Lernschleifen braucht.

SCRUM hätte hier wahrscheinlich:

* künstliche Sprint-Artefakte erzeugt,

* permanentes Replanning,

* Velocity-Diskussionen,

* Scope-Kämpfe.

KANBAN dagegen akzeptiert:

> Sicherheit verändert kontinuierlich den Flow.

Und genau das ist in VS-NfD-Umgebungen realistisch.

—

# Das eigentliche Ergebnis

Die App ist am Ende fast nebensächlich.

Der wahre Output des Systems ist:

* sichere Deliveryfähigkeit,

* adaptive Zusammenarbeit,

* auditfähiger Flow,

* lernende Architektur,

* resiliente Operations.

Und genau dort treffen sich:

* WirkOps,

* Team-of-Teams,

* DevOps,

* SRE,

* KANBAN,

* Security Engineering,

* moderne Serviceorganisation.