This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Scrum = Gesunder Menschenverstand mit hübschen englischen BegriffenScrum = Instinktives Teamverhalten in kritischen ProjektsituationenUnd dieses Verhalten besteht oft aus…
Das Wichtigste zuerstRückversicherung beim KundenÜberschaubare ZyklenSachen gleich „richtig“ fertig machenEffiziente KommunikationStändiges OptimierenKein Prozess-SchnickschnackAlle für einen – einer für AlleLauffähige SoftwareDéjà-vu?
Begreift sich nicht als Teil des TeamsNicht greifbar für Team (zu „busy“ für Daily Scrum?)Nicht willens/fähig zu Entscheidungen („Dinner-Test“)Sieht Kunden als Feind anstatt LebensversicherungSchlampt bei Product Backlog(Sabotagedetails folgen später)
Grooooße Teams sind behäbig(Worst Case: > 9 Entwickler)Tools anstatt MundwerkMut zur De-Spezialisierung nehmen (Rockstars)Keine Chance zur Eigenverantwortung geben„Querulanten“ (Tester, DB-Admins) aus Team fernhaltenBloß kein Pair Programming (z.B. Junior / Senior)„Big Picture“ verheimlichen
Vorgesetzter? („Augentest“)Arbeitsverteiler im Daily ScrumVertrauen in Team ist überflüssigLöst Probleme selber anstatt Hilfe zur SelbsthilfeNicht greifbarLässt Hindernisse versanden („Whiteboard-Test“)Nicht streng genug (!)
Nicht aktuell im Sprint Planning MeetingIn Komponenten / Dokumenten formuliertZu große User StoriesUser Story ersetzt komplettes Pflichtenheft MNicht streng priorisiertPriorisierung nicht mit Kunden abgestimmtTop-Manager betreiben „Hintenrumming“Kein zyklisches „Grooming“Nichtssagende User Stories [Beispiel…]
Beschreibung:Als Administrator will ich die Benutzerzahlen der Weblösung XY auswerten können um bei Lastspitzen zusätzliche Hardware aktivieren zu können
Akzeptanzkriterien:Textdatei genügtListet max. Anzahl der gleichzeitigen Benutzer je StundeLetzte 30 Tage genügenAktualisierung 1x je TagZugriff nur für Admins und Site-Manager
Beschreibung:Als Webservice will ich die Benutzer aus der Tabelle CurrentUsers aus der Datenbank auslesen und per Filestream in die Datei myLog.txt schreiben
Akzeptanzkriterien:Name der Komponente: myWebserviceKVA.B auch in 2.01 nötigWeitere Details wie besprochen
Altlasten aus vorherigem Sprint nicht mitführen („Debt“ / „undone work“)Keine Tasks für selbstverständliche ArbeitenDrag-Factor ignorierenNicht sichtbar im Daily ScrumViele Tasks „in progress“Nicht visualisieren, warum „in progress“(z.B. überall fehlt nur noch der Test)So würden Scrum-Fans es vielleicht machen [Beispiel…]
Nicht sichtbar im Daily ScrumAls Management-Kontrollinstrument anstatt als Team-Helferlein nutzenKeine Konsequenz aus ungünstigem Burndown ziehen [Beispiel…]
Warum nicht gleich 9 Wochen anstatt 3?Karenzzeit zwischen Sprints zum „Fertigmachen“Takt häufig wechselnUmpriorisieren während SprintSprint auch im Notfall nie abbrechen
Product Backlog nicht aktuell (kein Grooming)Diskussionen über den Sinn von User StoriesProduct Owner „anschießen“Große Stories nicht herunterbrechenLead Developer / Rockstar schätzt alleine abPlanning Poker ist eh kindischEndlos-Meetings (was heißt schon „time boxed“?)
Was heißt schon „täglich“?„Hinsetzmeetings“ mit KaffeeSprint Backlog nicht sichtbar im RaumKeine Konzentration auf die 3 FragenZu „sanfter“ Scrum MasterAlle lieben technische DetaildiskussionenBurndown nicht „live“ pflegen, Konsequenzen nicht mit Product Owner diskutierenHindernisse (Impediments) versanden lassen
„Stuhlkreis“-Atmosphäre schafft Unbehagen ;-)Einfach mal den Chef dazunehmenAuf keinen Fall strukturiert vorgehenNichts aufschreiben / nichts nachverfolgenNach ersten Erfolgen nicht weiter optimieren
Scrum-Regeln: Definition of Done lächerlich machen
Diktat vom Management anstatt durch TeamUnsinnige Inhalte (z.B. Einchecken nicht Teil der DoD)Definition of Done weder leben noch nachjustierenWas heißt schon fertig (z.B. Verdächtige Source Labels)?