3. 10 Working Software
Die wenigsten Teams schaffen es,
am Ende jedes Sprints wirklich
„working software“ zu liefern.
4. 9 Self-organizing Team
Die meisten Teams haben Probleme
damit, sich effektiv selbst zu
organisieren. Sie haben ein falsches
oder kein Verständnis über die
Methodik bzw. agile Prinzipien.
Plötzlich fehlt das „Command-and-
Control-Manangement“.
5. 8 Development Equipment
Es ist nicht möglich, mit veralteter
und lückenhafter Entwicklungsum-
gebung hoch agil und innovativ zu
arbeiten. Continuouse Integration
und Testautomation müssen von
Anfang an vorhanden sein.
6. 7 Cross-functional Team
Die wenigsten Teams sind wirklich
„cross-functional“ besetzt. Es fehlen
meist wichtige Projektrollen und die
damit verbundene Expertise im
Team. Konflikte im Team werden
nicht ausgeräumt.
7. 6 Integration
Es wird vergessen, dass die Inte-
gration der Arbeitsergebnisse Zeit
benötigt und/oder Nachbesserung
erfordert. Continuous Integration
alleine genügt nicht.
8. 5 Technical Excellence
Es wird angenommen, das Scrum-
Team verfügt bereits über
„Technical Excellence“. Der Aufwand
für Aus- und Weiterbildung wird
meist unterschätzt. Spikes sind
unbekannt.
9. 4 Daily Scrum
Das Daily Scrum wird nicht als
Replanning Meeting genutzt. Das
Development-Team schafft keine
Transparenz. Das Prinzip „start
finnishing – stop starting“ wird
nicht verfolgt.
10. 3 Feature Teams
Das Team bleibt nicht lange genug
in gleicher Besetzung zusammen,
um nötige Kompetenz zur Um-
setzung von E2E-Kundenfeatures
aufzubauen.
11. 2 Definition of Done
Eine formale Verifikation der
Sprintergebnisse gegen die DoD
findet meist nicht statt. Transparenz
geht verloren.
12. 1 Release
Zu wenig Mut, um sich das Feed-
back vom Markt einzuholen, indem
häufig an den Kunden geliefert
wird. Angst vor Ernüchterung in
allen Aspekten.