Scrum - auf einer Seite erklärt

\cite{Cetinkaya2010}

• Rahmenwerk, aber kein Werkzeug
  • Scrum verrät nichts über den Aufbau der Einträge der Backlogs
  • die Sprint Plannings sind unausgereift
• Sprintdauer
  • bei den Sprints (Iterationen) und deren Dauer ist die Methodik (bzw. die Umsetzung von Scrum) zumeist deutlich mangelhaft
  • für ein Rahmenwerk, welches sehr stark auf die Mikro-Organisation fokussiert ist, sind 4 Wochen eine lange Zeit (kürzere Sprints werden kaum verwendet, wenn man aus dem klassischen PM kommt)
• Planung und Design
  • Planung und Design in Scrum sind "unfassbar"
  • in der Scrum-Methodik gibt es keine unterstützenden Merkmale zu adequater Businessanalyse und der anschließenden Anforderungsanalyse
  • Sprint Planning ist in vielerlei Hinsicht inadequat
  • Sprint Planning ist ein Alibi für Design und Planung
• Scrum Master
  • in den meisten Unternehmen ist der Scrum Master Nachfolger des klassischen Projekt-Managers und nimmt aktiven Einfluss auf die Planung, verteilt Tasks und Aufgaben, zweifelt Entwicklungsaufgaben an, mahnt bei Refaktorisierungsaufgaben zur Beachtung des "Business Values" und erklärt sich selbst zum "Manager des Teams"
  • ist oft V-Mann und Sklave des konservativen Managements und muss Executive Summaries und Projektpläne aufstellen
  • kann aber auch ein Entwickler sein, der dann Tasks ändert, bei Estimations der Führende ist und den anderen "seinen Programmierstil" (unbewusst) vor die Nase setzt
• Skalierung
  • Scrum in seiner ersten und "reinen" Form ist eher für ein einzelnes Team konzipiert, maximal ein paar Teams
• Sonstiges
  • viele denken, sie praktizieren Scrum, dabei machen Sie kleine Wasserfall-Iterationen
  • Scrum ist oftmals ein Ausreden-Paket für Entwickler

\cite{Martin2010}

• Scrum gibt den Entwicklern keine praktischen Hilfsmittel (z.B. TDD, Continuous Integration, Acceptance Testing, Pair Programming, Refactoring)
• 4 Wochen sind zu lang für einen Sprint
• der Scrum Master wird häufig zum Projektleiter
• der Scrum Master ist eine Rolle (die von mehreren Teammitgliedern abwechselnd eingenommen werden sollte), wird aber häufig mit einer einzelnen Person in Verbindung gebracht
• Scrum gibt keine Struktur für die Backlogs vor
• der Fokus auf selbstorganisierende Teams ist zu groß, Teams müssen auch geführt werden
• Scrum erwähnt nie automatisierte Tests, obwohl sie die Grundlage jedwedes agilen Vorgehens sind
• Scrum bietet keine Lösung zur Arbeit mit mehreren (verteilten) Teams

\cite{Starr2010} nennt einige Anhaltspunkte, wann Scrum wahrscheinlich nicht der richtige Prozess für ein Team ist:

• The person who developed the application is responsible for keeping it running in production.
• Software developers have duties that call them into tactical fire-fighting situations like bringing up a dead network, or troubleshooting an ailing Exchange server.
• The organization does not think in terms of "Products".