Ideen

• Kanban
• product review sessions

ChatGPT

Fehlendes Backlog

welche agilen vorgehensmodelle bzw. best practices gibt es in der software-entwicklung, wenn das product backlog noch nicht da ist. es gibt zwar eine produktvision und auch schon einen PoC, aber das Produkt ist sowohl technisch als auch nutzenseitig immer nocht nicht planbar in user stories. daher ist SCRUM nicht machbar. das team ist ca. 8 personen groß, und wir überlgen, einen meilenstein in den nächsten 8 wochen einfach durch tägliches ‘PDCA’ zu erstellen: ein morgendliches planning, dann in subgruppen ein erforschen, dann im Plenum wieder C (Check) zusammenführen/integrieren, und ein abschliessendes ‘A’ als Ergebnissicherung, Versionierierung, Dokumentation. Was hälst du von diesem Vorgehen, bzw. welches Risiken und Verbesserungsvorschläge hast du? Oder gibt es ein Standard-Vorgehen hierfür?

Dein beschriebenes Szenario – Vision und PoC vorhanden, aber kein ausformuliertes Product Backlog – ist typisch für eine frühe Explorations- oder Inceptionsphase in der Produktentwicklung. In dieser Phase ist klassisches Scrum tatsächlich oft zu starr, weil es eine gewisse Klarheit über Features und Stories voraussetzt. Das von euch überlegte Vorgehen klingt nach einer sehr pragmatischen und iterativen Methode, die im Kern gut zu den Lean-Startup-Prinzipien oder Design Thinking + Agile Engineering passt.

Bewertung eures PDCA-basierten Vorgehens

Positiv:

• Täglicher PDCA-Zyklus (Plan-Do-Check-Act) sorgt für schnelle Feedbackschleifen.
• Morgendliches Planning und Check-Meeting im Plenum fördern Transparenz und Selbstorganisation.
• Subgruppen-Erkundung erlaubt parallele Experimente.
• Abschließendes “A” zur Ergebnissicherung ist essenziell, sonst bleibt es bei “busy work”.

Risiken:

1. Fehlende Langfriststruktur: Ohne grobe übergreifende Richtung (z. B. Meilensteinplan, Zielbild) kann es leicht in ziellosem Explorieren enden.
2. Uneinheitlicher Erkenntnisgewinn: Subgruppen könnten redundant oder inkompatibel arbeiten, wenn kein gemeinsames Verständnis besteht.
3. Dokumentation als „Nachsorge“: Wenn die Doku erst am Ende passiert, droht Wissensverlust – lieber „Living Docs“ in Echtzeit pflegen.
4. Stakeholder-Abkopplung: Ohne explizite Reviews oder Demo-Rituale kann Feedback von außen fehlen.

Verbesserungsvorschläge

1. Exploration Backlog oder Hypothesenboard: Auch ohne klassisches Product Backlog könnt ihr mit einem Experiment-/Hypothesenboard (à la Lean Startup) arbeiten. Zum Beispiel:

   • Hypothese: „Feature X wird den Use Case Y verbessern.“
   • Experiment: „Prototyp bauen und testen mit Nutzergruppe Z.“
   • Ergebnis & Learnings dokumentieren.

2. Wöchentliche Zielsetzungen: Jeden Montag ein Weekly Planning mit klaren Zielen für die Woche (Outcome-fokussiert, nicht Task-fokussiert).

3. Integration mit Dual Track Agile: Das Vorgehen ähnelt dem Dual-Track-Modell: ein Discovery-Track (Erkunden, Validieren, Prototypisieren) läuft parallel zum späteren Delivery-Track (Releases, Sprints). Ihr seid noch voll im Discovery-Track.

4. Design Studio oder Spike-Zeitfenster: Strukturiert Zeit für z. B. 2-Tages-Design-Studios oder 1-Tages-Spikes – das erhöht die Qualität der Exploration.

5. Review/Share-Session freitags: Eine fixe wöchentliche Review-/Demo-Session (auch intern) erhöht die Disziplin und hilft beim „Check“-Teil im PDCA.

Gängige Standard-Methoden in dieser Phase

• Design Thinking (für Nutzerzentrierte Exploration)
• Lean UX / Lean Startup (Hypothesengetrieben)
• Dual Track Agile
• Google Design Sprint (5 Tage) – extrem hilfreich, wenn es um das Testen von Nutzerideen geht
• Shape Up (Basecamp) – für nicht-sprintbasiertes Arbeiten mit “Bet” auf 6-Wochen-Projekte

Fazit:
Euer PDCA-Zyklus ist ein solider, pragmatischer Einstieg in eine unsichere, vorstrukturierte Produktphase. Mit ein paar Ergänzungen (Exploration Backlog, feste Review-Elemente, Hypothesenstruktur) könnt ihr daraus ein effektives Discovery-Vorgehen machen, das den Übergang zu einem klassischen agilen Framework (z. B. Scrum) vorbereitet.

Möchtest du eine konkrete Vorlage für ein Exploration Backlog oder Hypothesenboard für euer Team?

Architektur vorhanden

ok, du findest vor allem Tages-Zyklen zu kurz. Ich möchte noch ergänzen, dass wir eine Architektur haben. Das klingt vielleicht paradox, aber es ist tatsächlich so, dass wir das Software-syewtm bereits designed haben, und die Komponenten auch bereits kennen, aber jetzt vor allem die Wege des automatischen Deployments in eine Cloud und die Konfigurations- und Verwaltungsstrukturen unsrerer Software herausfinden müssen. Das ist da, was sich gerade nicht weiter planen lässt. Kannst du mit diesen Ergänzungen dein Feedbach nochmal schärfen?

Danke für die Ergänzung – das ändert die Ausgangslage entscheidend und erlaubt eine deutlich präzisere Einordnung.

Neue Ausgangslage

• Ihr habt eine Architektur: Die Komponenten und Schnittstellen sind klar.
• Es gibt bereits einen PoC und eine Produktvision.
• Das Backlog fehlt, weil ihr gerade die “nicht-funktionalen” Themen wie Deployment, Cloud-Umgebung, Konfiguration und Betrieb klärt.
• Das System ist technisch grob fertig designt, aber die Operations- und Deployment-Prozesse sind unklar und werden explorativ entwickelt.

Schärferes Feedback

1. Tages-PDCA-Zyklen wirken in diesem Kontext zu granular

Bei Infrastruktur-, Deployment- oder Konfigurationsfragen entstehen oft tiefe „Spikes“ (z. B. CI/CD-Pipeline aufsetzen, Helm-Chart modellieren, Secrets Handling evaluieren). Diese brauchen oft mehr als einen Tag bis zum „Check“, weil Abhängigkeiten (z. B. Rechte, Cloud-Zugänge, Testumgebungen) entstehen. Ein 2- bis 3-Tages-Rhythmus mit klaren Zwischenzielen wäre realistischer, ergänzt um:

• Daily Standup als Taktgeber, aber nicht zwangsläufig als vollständiger PDCA-Zyklus.
• Weekly Planning mit Zielvorgaben und Review-Ritualen, um Fortschritt messbar zu machen.

2. Was ihr macht, ist kein Produkt-Delivery, sondern “System Enablement”

Ihr steckt im Übergang von Architektur zu einem Infrastructure as Code + Plattform Enablement Track. Das bedeutet:

• Die „User Stories“ sind keine klassischen Features, sondern z. B.:
  • „Als Team möchte ich unsere Software mit einem Befehl deployen können.“
  • „Als Betreiber will ich wissen, wie ich Services konfiguriere.“

Das spricht für ein Infrastructure Kanban Board, keine Sprints.

3. Mögliche Vorgehensmodelle / Best Practices

4. Konkrete Empfehlungen zur Strukturierung

• Ziele für die 8 Wochen formulieren als “Capabilities”, z. B.:
  • „Greenfield-Clouddeployment in AWS/GCP über GitHub Actions.“
  • „Parameterisierbares Helm-Chart mit Doku.“
  • „Konfigurierbarkeit über ENV vs. Secrets evaluieren.“
• Dazu 1–2 Woche cadence, jede Woche ein Review/Checkpoint.
• Boards mit Task-Kategorien:
  • 🧪 Spike
  • 🛠️ Tooling/Automation
  • 📦 Infrastruktur/Dienst
  • 📓 Dokumentation
• Ergebnisse sofort versionieren und dokumentieren, z. B.:
  • GitOps Repo-Struktur
  • ADRs
  • Beispiel-Deployments

Fazit

Ihr seid im “technisch operativen Enablement” eures Systems, nicht im Produkt-Delivery. Das rechtfertigt:

• ein kanban-artiges, flexibles Modell mit timeboxed Reviews,
• tägliche Abstimmungen, aber nicht zwingend tägliche Zyklen,
• Fokus auf Enabler-Ziele statt funktionale Stories.

SCRUM ist hier fehl am Platz, aber euer Ansatz ist sehr nahe an einer modernen DevOps-orientierten Arbeitsweise, die z. B. von Platform Engineering Teams eingesetzt wird.

Möchtest du ein Beispiel für ein solches Kanban-Board mit passenden Task-Typen und Zielstruktur?

Kanban

ja, gerne!

Hier ist ein konkretes Beispiel für ein Kanban-Board, das speziell auf eure Situation als „Platform/Enablement“-Team mit einem vorhandenen Architekturbild, aber offenem Deployment- und Betriebsdesign zugeschnitten ist.

🎯 Zielstruktur (übergeordnet für 8 Wochen)

Diese formuliert ihr am besten als Capabilities – Fähigkeiten, die das System nachher haben soll:

Diese Capabilities bilden Spalten oder Swimlanes im Board (wenn euer Tool das unterstützt, z. B. GitHub Projects, Jira oder Trello mit Labels).

🗂️ Kanban-Board-Spalten (klassisch)

🏷️ Task-Typen (Labels oder Emojis zur Kennzeichnung)

🧩 Beispielhafte Tasks für Capability „C1 – Deployment automatisieren“

📅 Cadence-Empfehlung

• Daily Standup (15 min): Was läuft, was blockiert? Pull statt Push!
• Weekly Planning (Montag): Priorisieren und Backlog-Grooming (welche Capabilities sind diese Woche dran?)
• Weekly Review (Freitag): Erkenntnisse, Entscheidungen und Dokumentation präsentieren
• Optional: Retrospektive alle 2 Wochen, falls das Team Energie hat

Wenn du magst, kann ich dir ein Beispiel-Board als Markdown-Vorlage oder als CSV-Datei zum Import in Trello, GitHub Projects, Jira etc. machen. Wäre das hilfreich?

Living Docs

kannst du noch etwas mehr zu ‘LivingDocs’ sagen?

Ja, gerne! “Living Docs” (bzw. Living Documentation) ist ein Konzept aus der agilen Softwareentwicklung und DevOps, das sich auf aktuelle, direkt aus dem System oder aus dem Arbeitsprozess generierte Dokumentation bezieht. Ziel ist es, dass die Dokumentation nicht veraltet, sondern so eng mit Code und Systemzustand gekoppelt ist, dass sie sich (teilweise) selbst aktualisiert oder sich mit dem Entwicklungsprozess mitbewegt.

🔍 Was macht “Living Documentation” aus?

🧰 Typische Formen von Living Docs

✅ Best Practices

1. Nutze Markdown + Git: Einfach, versionierbar, lesbar → ADRs, Runbooks, HowTos.
2. Dokumentiere Entscheidungen bewusst: Lieber knappe, saubere ADRs als keine Doku.
3. Verknüpfe Doku mit Code / CI/CD: Beispiel: Build-Tool erzeugt automatisch API-Doku oder ADR-Lint-Checks.
4. Verlinke Logs, Dashboards, Monitoring: z. B. in einem system-overview.md.
5. Behandle Doku wie Code: Reviewpflichtig, Pull Request basiert, CI-checkbar.

🛠️ Tools & Frameworks

🧠 Denkweise: Doku = Gespräch in Zeit

“Dokumentation ist kein Nachtrag, sondern ein asynchrones Gespräch mit deinem zukünftigen Ich – oder dem nächsten Teammitglied.”

Gerade in eurem Kontext (technisches Enablement, Deployment, Betrieb) ist das entscheidungsorientierte, leichtgewichtige Festhalten von Kontext Gold wert. ADRs und docs/runbooks/-Verzeichnisse sind ein idealer Startpunkt.

Möchtest du eine Vorlage für ein ADR oder ein Beispielverzeichnis für eine sinnvolle Living-Docs-Struktur im Repo?