10 wahrscheinliche Gründe warum
agile Methoden scheitern können
10 Working Software
Die wenigsten Teams schaffen es,
am Ende jedes Sprints wirklich
„working software“ zu liefern.
9 Self-organizing Team
Die meisten Teams haben Probleme
damit, sich effektiv selbst zu
organisieren. Sie haben ein falsche...
8 Development Equipment
Es ist nicht möglich, mit veralteter
und lückenhafter Entwicklungsum-
gebung hoch agil und innovat...
7 Cross-functional Team
Die wenigsten Teams sind wirklich
„cross-functional“ besetzt. Es fehlen
meist wichtige Projektroll...
6 Integration
Es wird vergessen, dass die Inte-
gration der Arbeitsergebnisse Zeit
benötigt und/oder Nachbesserung
erforde...
5 Technical Excellence
Es wird angenommen, das Scrum-
Team verfügt bereits über
„Technical Excellence“. Der Aufwand
für Au...
4 Daily Scrum
Das Daily Scrum wird nicht als
Replanning Meeting genutzt. Das
Development-Team schafft keine
Transparenz. D...
3 Feature Teams
Das Team bleibt nicht lange genug
in gleicher Besetzung zusammen,
um nötige Kompetenz zur Um-
setzung von ...
2 Definition of Done
Eine formale Verifikation der
Sprintergebnisse gegen die DoD
findet meist nicht statt. Transparenz
ge...
1 Release
Zu wenig Mut, um sich das Feed-
back vom Markt einzuholen, indem
häufig an den Kunden geliefert
wird. Angst vor ...
Evolution der agilen Softwareentwicklung
Herzlichen Dank für
die Aufmerksamkeit
Scrumster
Nächste SlideShare
Wird geladen in …5
×

Scrumster

216 Aufrufe

Veröffentlicht am

Wer Erfolg haben will, muss wisen, was schiefgehen kann

Veröffentlicht in: Leadership & Management
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
216
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Scrumster

  1. 1. 10 wahrscheinliche Gründe warum agile Methoden scheitern können
  2. 2. 10 Working Software Die wenigsten Teams schaffen es, am Ende jedes Sprints wirklich „working software“ zu liefern.
  3. 3. 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“.
  4. 4. 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.
  5. 5. 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.
  6. 6. 6 Integration Es wird vergessen, dass die Inte- gration der Arbeitsergebnisse Zeit benötigt und/oder Nachbesserung erfordert. Continuous Integration alleine genügt nicht.
  7. 7. 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.
  8. 8. 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.
  9. 9. 3 Feature Teams Das Team bleibt nicht lange genug in gleicher Besetzung zusammen, um nötige Kompetenz zur Um- setzung von E2E-Kundenfeatures aufzubauen.
  10. 10. 2 Definition of Done Eine formale Verifikation der Sprintergebnisse gegen die DoD findet meist nicht statt. Transparenz geht verloren.
  11. 11. 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.
  12. 12. Evolution der agilen Softwareentwicklung Herzlichen Dank für die Aufmerksamkeit

×