12 hartnäckige agile Mythen
Agiler Mythos vs. Realität
frei nach Thierry Delestre
Die meisten Schmerzen beim agilen Arbeiten entstehen, weil der Kern der Agilität nicht verstanden wurde. Da hilft es nicht, dass sich die verschiedensten Mythen hartnäckig halten und oft reproduziert werden. Grund genug, mit den 12 – die uns am häufigsten über den Weg laufen – aufzuräumen:
1. Es gibt keine Planung
Ganz im Gegenteil. Wir machen eine leichtgewichtige, initiale Planung, die wir fortlaufend überprüfen und kontinuierlich anpassen.
2. Es gibt keine Dokumentation
Wir dokumentieren Anforderungen schlank und ihre Umsetzung so, dass alle relevanten Informationen leichtgewichtig und übersichtlich verfügbar sind.
3. Es gibt keine Führung
Auch im Agilen gibt es Führung, deren Aufgabe ist allerdings nicht Anweisung und Kontrolle, sondern Rahmenbedingungen zur Verfügung zu stellen innerhalb derer die Mitarbeitenden sich selber organisieren können.
4. Es gibt keine Architektur
Architektur entsteht emergent und ist modular. Sie wird gemeinsam von den Umsetzungsbeteiligten definiert und nicht von einer einzelnen Person.
5. Funktioniert nur in kleinen Projekten
Ganz im Gegenteil, agile Frameworks sind genauso gut dafür geeignet, große, komplexe Projekte zu meistern. Die Herausforderung ist, agil zu bleiben, während man skaliert.
6. Während eines Sprints wird nichts verändert
Im Sprint lernt man jeden Tag dazu, weshalb sich auch die Sicht auf die Anforderungen und die Planung im Sprint verändert. Stabil hingegen bleibt das Sprintziel, das es zu erreichen gilt.

7. Product Owner = Vermittler zwischen Stakeholdern und dem Entwicklungsteam
Der Product Owner sollte stattdessen einen direkten Kontakt zwischen den Stakeholdern und dem Team fördern.
8. Der Scrum Master führt das Team
Seine Aufgabe ist nicht die disziplinarische Führung, sondern durch laterale Führung und Coaching dem Scrum-Team dabei zu helfen, seine Arbeitsweise zu verbessern.
9. Das Team entscheidet während eines Sprints alles alleine
Teammitglieder benötigen den konstanten Austausch mit den Stakeholdern und dem Product Owner, um gute Arbeitsergebnisse zu erzielen.
10. Wir müssen in jedem Sprint etwas veröffentlichen
In jedem Sprint sollte ein potenziell nutzbares Produkt-Inkrement erschaffen werden, dieses kann jedoch sowohl am Ende eines Sprints oder nach mehreren Sprints veröffentlicht werden.
11. Je mehr Vorbereitung, desto besser
Wenn Arbeit früh und in großem Umfang vorbereitet wird, wird nicht mehr iterativ gearbeitet, sondern man verfällt in eine unflexible Wasserfall-Arbeitsweise.
12. Agilität ist zwar cool – aber nichts für uns!
Agil arbeiten kann jeder, der es will. Abhängig von der Ausgangssituation kann der Weg dorthin jedoch unterschiedlich lang und fordernd sein.
Neueste Blogposts

Design Thinking: Entdecken, Verstehen, Umsetzen – Lean Startup: Testen, Anpassen, Wachsen
Design Thinking und Lean Startup haben die Art und Weise verändert, wie Unternehmen Innovationen entwickeln und Produkte erfolgreich auf den Markt bringen. In diesem Artikel

Ist man nur mit 4-Tage-Woche und 100 % Homeoffice ein guter Arbeitgeber?
Nach knapp 3 Jahren Erfahrungen mit der 4-Tage-Woche und nahezu 100 % Remote-Arbeit haben wir zum Jahresanfang unsere Arbeitsweise erneut umgestellt. Diesmal auf eine 4,5 –

Design Thinking im UX Design: Nutzerorientierte Lösungen für nachhaltigen Unternehmenserfolg
In der digitalen Ära gewinnen herausragende Benutzererlebnisse immer mehr an Bedeutung. UX Design spielt eine entscheidende Rolle für den Erfolg von Produkten und Dienstleistungen. Unternehmen,