Die gewünschten Vorteile der agilen Entwicklung sind vielfältig:
Hört sich doch gut an, oder? In der Praxis stehen bestimmte Verhaltensweisen den genannten Vorteilen im Weg. Weil ich als Scrum Master und agiler Coach dieselben Muster in vielen Firmen immer wieder sehe, schreibe ich in dieser Artikelserie darüber.
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.
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.
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.
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ß!
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.
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.
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.
“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.
Die Motivation
Kennen Sie die folgenden Situationen?
Diese Probleme resultieren häufig daraus, dass es kein einheitliches Konzept gibt, wie Anforderungen systematisch und möglichst direkt im Code abgebildet werden.