- Requirement = nur eine Art bzw. Ebene von Information. In der Praxis wird unter dem Begriff »Requirement« oft genau eine Art oder Ebene von Information verstanden. Übersehen oder negiert wird dabei, dass Vision und Ziele auf hoher Ebene, die User Stories auf mittlerer Detaillierungsebene sowie Use-Case-Szenarien oder sogar ausführbare Prototypen auf einer detaillierten Ebene allesamt Requirements darstellen können. Diese unterscheiden sich hinsichtlich des Detail- bzw. Abstraktionsgrades. Zu berücksichtigen sind auch die Dokumentationsmittel und Tools, die entsprechend der jeweiligen Ebene und Requirements-Art gewählt werden sollten. Nur so wird das Arbeiten mit den Requirements auch effizient möglich.
- Der Blick auf »das große Ganze« fehlt. Der Scrum Guide liest sich (scheinbar) recht einfach und verständlich und wird darausfolgend immer wieder falsch interpretiert. Verlässt man sich nämlich nur auf die Umsetzung der darin beschriebenen Themen, ist das für eine erfolgreiche Softwareentwicklung unzureichend. Nachhaltig und langfristig denkende und agierende agile Teams berücksichtigen weitere Aspekte und setzen diese in ihrem Vorgehen um – z.B. mit Release- & Roadmap-Planung, Kontextanalysen, Risikoanalysen, Ablauf- und Prozessanalysen, User-Interface Design, Teststrategie und Testspezifikation etc. Es ist unerlässlich, auch Aspekte außerhalb des Scrum Guides zu berücksichtigen.
- Informationsüberlastung. Im agilen Vorgehen ist das Ziel eines Sprints, ein für die Kunden:innen brauchbares Ergebnisartefakt zu präsentieren. Werden aber Stakeholder zu diesem Zeitpunkt nicht mit einem lauffähigen Produkt (Prototyp), sondern nur mit (evtl. recht umfangreichen) Spezifikationsartefakten konfrontiert, kann dies zu einer Informationsüberlastung im Review-Meeting am Ende des Sprints führen. Schließlich müssten die Stakeholder in kurzer Zeit eine große Informationsmenge durchsehen und beurteilen. Es ist durchaus legitim, auch Sprints zu planen, deren Hauptziel die Erstellung von Dokumentationsartefakten ist. Dabei sollten aber nicht nur reine Textartefakte erzeugt werden, bei denen meist der Kontext und die Zusammenhänge schwerer erkennbar sind oder verloren gehen. Es ist ratsam, auf Techniken und Artefakte zurückzugreifen, wie beispielsweise Modelle, Prototypen (auch in Papierform), Bilder usw., die den Stakeholdern einen umfassenderen Überblick sowie ein verbessertes Verständnis des Produkts sowie einen höheren Mehrwert bieten.
- Alles inkrementell entwickeln. Themen, die schrittweise an Umfang und Komplexität zunehmen oder in unabhängige Teile oder Schritte aufgeteilt werden können, eignen sich typischerweise für inkrementelle Umsetzung. Dies gilt beispielsweise für Forschungsprojekte, Website-Entwicklungen oder Projekte mit unklaren Anforderungen. Oftmals verstehen Kunde:innen erst durch die ersten Ergebnisse, was ihre eigentlichen Bedürfnisse sind. Themen hingegen, die nur als geschlossene Einheit funktionieren, sind weniger für eine iterative Umsetzung geeignet. Ein Beispiel hierfür ist eine komplexe Berechnungsfunktion, die ein korrektes Ergebnis liefern soll. Wenn zunächst nur Teile der Berechnung spezifiziert und umgesetzt werden, kann eine Berechung des Endergebnisses ungenau oder eventuell gar nicht möglich sein. Ähnlich verhält es sich bei einer Maschinensteuerung, bei der die Maschine insgesamt nur dann korrekt arbeitet, wenn alle notwendigen Sensoren und Aktoren richtig abgefragt und angesteuert werden. Um in diesen Fällen trotzdem iterativ netwickeln zu können, sind manchmal umfangreichere Vorarbeiten wie das Erstellen einer geeigneten Simulationsumgebung (z.B. "Digital Twin") für das Umfeld notwendig.
- Inkrementelle Entwicklung behindert Innovation. Agiles Vorgehen setzt auf einen kontinuierlichen Prozess der inkrementellen Verbesserung, der eine ständige Innovation begünstigt. Allerdings liegt der Fokus nicht primär auf disruptiven oder radikalen Innovationen. Diese entstehen oft durch die Betrachtung, Bewertung und Kombination verschiedener Ideen. Für solche disruptiven oder radikalen Innovationen sollten daher zusätzliche Ansätze wie Design Thinking oder Lean Startup in Betracht gezogen werden.
- Agilität bedingt einen Kulturwandel. In agilen Organisationen wird auf eine kollektive Verantwortung hingearbeitet, was jedoch auch den Verlust individueller "Eigentumsrechte" mit sich bringen kann. Durch regelmäßige Retrospektiven wird eine fortlaufende Verbesserung der Vorgehensweisen und möglicherweise der gesamten Organisation angestrebt. Diese kontinuierlichen Veränderungen erfordern Zeit und qualifizierte Personen, die die Teams und die Organisation in diese Richtung lenken können. Diese Rahmenbedingungen müssen bei der Umsetzung agiler Ansätze berücksichtigt werden.
