Agile Transformation: Ein agiles Mindset alleine macht noch kein effizientes Team!

Szenario 3

Randbedingungen

Dieses Szenario zeichnet sich durch folgende Randbedingungen aus:

  • Ein einziger Microservice enthält die zur Umsetzung der Vision komplette Funktionalität.
  • Jeder der Layer Frontend, Businesslogik und Persistenz wird von einem separaten Team betreut.

Ablauf

Mit diesen Randbedingungen könnte der Ablauf für unsere Beispielvision wie folgt aussehen:

Der Product Manager formuliert die Features (Die Vision von Scrum entspricht in etwa einem EPIC oder Feature in SAFe):
Unsere Kunden können ihre Rechnungsart selbständig im Kundencenter auf Direct debit, eBill oder Papierrechnung wechseln.
- Jedes Team sollte sein eigenes Feature zugewiesen bekommen. Also müssten eigentlich drei Features formuliert und mit dem zugehörigen Team besprochen werden. Ebenfalls muss der Produktmanager den Fortschritt aller drei Features im Auge behalten, da die Teams aus verschiedenen Gründen die Priorisierung ändern könnten.
- Ein Feature sollte klar formuliert sein, sodass der Auftrag für das Team möglichst unmissverständlich ersichtlich ist. Der Produktemanager ist jedoch kein Techniker und sollte sich auf fachliche Beschreibungen beschränken. Sind die Teams jedoch wie in diesem Szenario horizontal geschnitten, können die Features nicht mehr auf fachlichem Level unterschieden werden. Hier entsteht ein erheblicher Mehraufwand und auch eine Unsicherheit, da der Produktemanager die Abgrenzung der Features selber nicht mehr versteht.
Die Product Owner der Teams akzeptieren und priorisieren die Features oder weisen sie zurück.

Frontend Team
Experience Designer und Requirements Engineer kreieren das Experience Design und erstellen folgende User Stories:
- Als Kunde kann ich meine Zahlungsart auf paper bill wechseln (Frontend)
- Als Kunde kann ich meine Zahlungsart auf eBill wechseln (Frontend)
- Als Kunde kann ich meine Zahlungsart auf Direct debit wechseln (Frontend)

Businesslayer Team
Experience Designer und Requirements Engineer kreieren das Experience Design und erstellen folgende User Stories:
- Als Kunde kann ich meine Zahlungsart auf paper bill wechseln (Business Layer)
- Als Kunde kann ich meine Zahlungsart auf eBill wechseln (Business Layer)
- Als Kunde kann ich meine Zahlungsart auf Direct debit wechseln (Business Layer)

Persistenzlayer Team
Experience Designer und Requirements Engineer kreieren das Experience Design und erstellen folgende User Stories:
- Als Kunde kann ich meine Zahlungsart auf paper bill wechseln (Backend)
- Als Kunde kann ich meine Zahlungsart auf eBill wechseln (Backend)
- Als Kunde kann ich meine Zahlungsart auf Direct debit wechseln (Backend)
Die Scrum Master weisen die User stories einem Sprint zu und stellen sicher, dass die Abhängigkeiten zwischen den Stories korrekt berücksichtigt werden.


Entwickler, Tester, Sicherheitsverantwortliche und der Betriebsverantwortliche arbeiten gemeinsam an der Implementierung der User Stories, den Tests und stellen sowohl Sicherheit wie Betrieb sicher.

Zahlen zur Effizienz

Folgende Kennzahlen geben Aufschluss über die Effizienz dieses Szenarios:

  • Vision: 1
  • Geschriebene Features: 3
  • Geschriebene User Stories: 9+
  • Benötigte Sitzungen / Abstimmungen (Total: 13-22+)
    • 3 zwischen dem Produktmanager und den drei product ownern
    • 3 zwischen den Produkt Ownern und den Requirements Engineers und dem Experience Designern
    • 3 zwischen dem Systemarchitekten und den Requirements Engineers
    • 1 zwischen den Requirements Engineers aller Teams.
    • 3-9+ zwischen dem Requirements Engineer und den Entwicklern/Testern/Verantworlichen für Security und Betrieb
  • Potentielle Lieferung der Funktionalität: in 6 Wochen
  • Involvierte Personen: 41 (3 Teams x 13 + Product Manager + System Architect)
  • Verantwortlichkeitsgefühl der involvierten Personen: tief

Fazit

Das Szenario 3 zeigt eine äusserst unglückliche und höchst ineffiziente Art, wie man Teams organisieren kann. Umso erstaunlicher ist es, dass ich genau diesen Fall in der Praxis am häufigsten antreffe!

Um dieselbe Funktionalität umzusetzen werden

  • Statt einer Vision müssen nun 3 Features geschrieben und deren Abhängigkeiten berücksichtigt werden. Allerdings lassen sich die Features nicht fachlich formulieren, da sie nur technische Teilartefakte des eigentlichen Features enthalten.
  • Statt 12 Personen sind nun ganze 40 Personen beteiligt! Ein hoher Abstimmungsaufwand ist die Folge.
  • Statt 2-4 Meetings werden nun bereits 10-16+ Meetings benötigt und die Erfahrung zeigt, dass oft nach der Übergabe noch weitere Fragen von Seite Entwicklung aufkommen, welche zu noch mehr Meetings führen.
  • Statt 3 User Stories werden nun 9+ User Stories mit starken Abhängigkeiten benötigt! Da die Abhängigkeiten Teamübergreifend sind, werden in der Praxis oft auch noch User Stories für sogenannte Mocks erwartet, welche diese Abhängigkeiten etwas lindern.
  • Statt rein fachlich formulierter User Stories müssen die Stories nun technische Details wie Interfacedefinitionen enthalten. Wenn der Requirements Engineer diese nicht selbständig erstellen kann, kommen hier noch weitere Meetings hinzu!
  • Weil die Interfaces bereits vom Requirements Engineer vorgegeben werden müssen, sind die Entwickler in der Umsetzung bereits eingeschränkt und müssen allenfalls unnötige Mappingfunktionalität implementieren.
  • Frühester Lieferzeitpunkt in 6 Wochen: Weil die User Stories starke Abhängigkeiten haben, werden sie in der Praxis oft in aufeinanderfolgende Sprints verteilt. Somit werden in unserem Fall mindestens 3 Sprints benötigt.
  • Weil die eigentliche Funktion über mehrere Entwickler und auch noch über mehrere Teams verteilt ist, kann niemand mehr so richtig die Verantwortung übernehmen. Ein hin und herreichen von aufkommenden Bugs ist oft die Folge einer solchen Aufteilung.