In unserem CARS-Training diskutieren wir viele Themen, unter anderem: wie dokumentiert man Anforderungen langfristig, im agilen Umfeld?
Diese Frage ist für uns deshalb so wichtig, weil der Wert der Dokumentation mit der Zeit zunimmt.
Die abgespeckte Sprint-Retrospektive
Wenn Sie als Scrum Master arbeiten, dann erleben 
Sie wahrscheinlich auch, dass die Retrospektive nicht zu den heiß geliebten Scrum-Events gehört. Ich habe aber die Erfahrung gemacht, dass Retrospektiven wirklich etwas bringen, nämlich Reflektion und Kommunikation darüber, was verbessert werden kann.
Ich bin daher ständig auf der Suche nach neuen Formaten, die von den Teams als nützlich empfunden werden. Das strikte Festhalten an 5 aufeinander folgenden Phasen ist meiner Erfahrung nach nicht notwendig, und manchmal sogar kontraproduktiv.
Wenn der Sturm sich nicht legt, dann bauen wir eben Windmühlen
Aufblende: Seit einem halben Jahr diskutieren Sie nun ein fachliches Thema mit mehreren Fachabteilungen. Aber der Sturm der Konflikte will einfach nicht aufhören. „Soll ich etwa eine Windmühle bauen?“ denken Sie, schon fast verzweifelt.
Scrum – the hard parts 2: sprint harder
Quelle: pixabay
Im ersten Teil dieser Serie habe ich meine persönliche Favoritenliste der „hard parts“ von Scrum vorgestellt und wie Sie diese gekonnt umschiffen können.
Auch im zweiten Teil möchte ich Ihnen einen bunten Strauß an Bad Practices und Workarounds anbieten – aus der Praxis, für die Praxis. Scheitern garantiert.
Viel Spaß!
Mut zur Lücke
Wikipedia
Das erste iPhone erschien 2007, und war ein gigantischer Erfolg. Apple-Kunden mussten allerdings noch bis 2009 warten, bis eine Basis-Funktionalität endlich ihren Weg in das Produkt fand: Copy & Paste.
YASFA: Yet Another Scaling Framework For Agility
Im Kontext größerer Unternehmen stellt sich bei der Einführung agiler Ansätze meist sofort die Frage nach Skalierbarkeit. Häufig wird dann diese Skalierbarkeit durch den Einsatz entsprechender Frameworks, wie z.B. SAFe, institutionalisiert. Dieser Ansatz scheint bei genauer Betrachtung nicht gerade im Sinne des agilen Manifests, welches in seinen Prinzipien Verbesserung durch Reflexion und Selbstoptimierung vorsieht.
Scrum – the hard parts
Meine persönliche Favoritenliste der „hard parts“ von Scrum und wie Sie sie gekonnt umschiffen. Weitere Inspirationen finden Sie hier: https://www.scrum.org/ScrumBut.
Nur die Entwickler schätzen
Laut Scrum Guide dürfen nur die Mitglieder des Entwicklungsteams Aufwände schätzen, also weder Scrum Master, noch Product Owner.
Optimierung der Vorhersagbarkeit
„In welcher Zeit und mit welchem Budget kann ich die Umsetzung meiner Anforderungen geliefert bekommen?“
Dieser Wunsch nach Vorhersagbarkeit kann eventuell erfüllt werden, wenn die Märkte berechenbar sind, die Anforderungen konsolidiert und stabil, und der Prozess der Umsetzung bekannt.
Dokumentation von Anforderungen mit Code Based Modeling
Die Motivation
Kennen Sie die folgenden Situationen?
- Wenn es auf ein Release zugeht, werden Good Practices wie das präzise Beschreiben der Anforderungen über Bord geworfen und alle Aufmerksamkeit auf das Fertigstellen der Software gelenkt.
- Die Anforderungsdokumentation ist nach einiger Zeit nicht mehr auf dem aktuellen Stand, sie hinkt der Software hinterher.
- Wenn die ursprünglichen Entwickler nicht mehr verfügbar sind oder viele Teams am selben Produkt arbeiten, wird es zusehends schwieriger herauszufinden, welche Teile der Software angepasst werden müssen um eine bestimmte Funktionalität zu ändern.
Diese Probleme resultieren häufig daraus, dass es kein einheitliches Konzept gibt, wie Anforderungen systematisch und möglichst direkt im Code abgebildet werden.
Sind Product Owner Teams eine Alternative?
Kunde: Aktuell gibt es bei uns im Haus die Diskussion, ob statt einer Person auch eine Gruppe von Personen die Product Owner Rolle übernehmen könnte. Haben Sie eine Meinung dazu?