NBA04: Scrum: Warum es Zeit ist, ein anderes agiles Vorgehen zu erwägen
Ist Scrum noch Agile? Kanban, Management-Tool, Vergleich Scrum und Kanban.
Shownotes
Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://podcasts.social/@nobullshitagile.
Fragen und Anregungen gerne hier: https://forum.no-bullshit-agile.de/d/6-nba04-scrum-warum-es-zeit-ist-ein-anderes-agiles-vorgehen-zu-erwaegen
-
Letzte Folge „NBA03: Open Space“ - https://no-bullshit-agile.podigee.io/3-open-space
Folge 1 „Das große Ganze“ - https://no-bullshit-agile.podigee.io/1-das-grosse-ganze
Agile & Scrum - https://richardwbown.com/dave-farley-and-allen-holub-agile-scrum-what-doesnt-work/
Why Scrum sucks - https://techbeacon.com/app-dev-testing/why-scrum-sucks
Zusammenfassung
In Folge 4 von No Bullshit Agile wirft Thomas einen kritischen Blick auf Scrum und diskutiert, warum es sinnvoll sein könnte, andere agile Methoden in Betracht zu ziehen. Hier sind die Kernaussagen:
Scrum als Management-Tool: Thomas sieht Scrum eher als Werkzeug für das Management, das bei der Planung und Durchführung von Projekten hilft, als ein echtes Entwicklungsframework. Er hebt hervor, dass Scrum stark auf Rollen, Prozesse und Reporting fokussiert ist, was es mehr zu einem Management-Framework macht als zu einem Werkzeug zur Verbesserung der Softwareentwicklung.
Erfahrungen mit Scrum: Nach fast fünf Jahren intensiver Nutzung von Scrum im Team stellt Thomas fest, dass Scrum oft auf Projekte und weniger auf die tatsächliche Softwareentwicklung fokussiert ist. Dies kann in der Praxis dazu führen, dass die tatsächliche Lieferung funktionierender Software in den Hintergrund tritt.
Kritik an der Velocity und Iterationen: Thomas beschreibt, dass die Velocity-Messung und das Commitment auf Iterationen in der Praxis schwierig sein können, besonders bei neuen oder unbekannten Aufgaben. Die Geschwindigkeit, mit der ein Team arbeitet, kann durch Storypoint-Schätzungen und Task-Splitting besser verstanden werden, ist jedoch nicht immer zuverlässig, wenn sich die Rahmenbedingungen ändern.
Vergleich zu Kanban und Extreme Programming: Andere Methoden wie Kanban und Extreme Programming stehen näher an der Realität der Softwareentwicklung. Sie erkennen an, dass die Entwicklung oft unbekanntes Terrain ist und bieten daher flexiblere Ansätze, die besser an die tatsächlichen Bedürfnisse der Softwareentwicklung angepasst sind.
Positives an Scrum: Thomas räumt ein, dass Scrum klare Regeln und Strukturen bietet, was es anfänglich leichter macht, agile Praktiken zu implementieren. Es kann als Einstiegspunkt für Agilität dienen, aber es ist nicht immer die beste Lösung für alle Anforderungen.
Kanban als flexible Alternative: Im Vergleich zu Scrum bietet Kanban mehr Flexibilität, da es sich auf den kontinuierlichen Flow von Entwicklungsanforderungen bis zum Release konzentriert, ohne feste Zyklen oder Iterationen. Dies kann besonders nützlich sein für die Unterstützung von älterer Software und die Priorisierung von Support-Tätigkeiten.
Insgesamt sieht Thomas Scrum als nützliches, aber begrenztes Werkzeug. Er empfiehlt, das Agile Manifest als Grundlage für Agilität beizubehalten und offen für alternative Methoden wie Kanban und Extreme Programming zu bleiben.
Transkript
Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche hier jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt dabei immer auf der Praxis, daher auch der Name No Bullshit Agile.
In der letzten Folge habe ich über das Thema Open Space, also eine Art Barcamp, gesprochen. Dabei ging es vor allem um den Wissensaustausch in der Firma. Heute ist Folge Nummer 4, und es geht um Scrum. Scrum ist sicherlich das große Thema, das uns allen als erstes einfällt, wenn wir über Agilität sprechen. Ich möchte heute einen kritischen Blick darauf werfen und meine Sichtweise darlegen.
Ich muss sagen, dass ich Scrum mittlerweile etwas kritischer sehe. Ich bin mir nicht mehr sicher, ob Scrum das beste agile Framework ist. Ein Hauptgrund für diese Zweifel ist die Frage, ob Scrum wirklich den fundamentalen agilen Prinzipien entspricht. Zu diesen Prinzipien werde ich sicherlich auch noch eine Folge machen, aber es gibt ein paar Punkte, bei denen ich denke, dass Scrum eher ein Management-Framework ist. Scrum neigt meiner Meinung nach dazu, eine gute Möglichkeit für das Management zu bieten, um Reporting zu erhalten.
Vielleicht noch ein kurzer Überblick zu meiner Erfahrung: Ich habe mit einem Team fast fünf Jahre lang sehr strikt nach Scrum gearbeitet, also so, wie es im Scrum Guide beschrieben ist. Ich bin daher der Meinung, dass ich mich mit Scrum ziemlich gut auskenne. Wir haben alle Prozesse und Rituale durchlaufen, haben sie für uns angepasst und optimiert, und deshalb würde ich sagen, dass ich schon Erfahrung mit Scrum habe.
Scrum orientiert sich stark an der Planung und Ausführung von Projekten. Der Fokus liegt auf Projekten und nicht auf der Software selbst. Der große Unterschied für mich liegt darin, dass der Blick auf die Entwicklung funktionierender Software viel wichtiger ist als der auf Projekte. Projekte beziehen sich immer auf Timings, Umfang und Kosten – wichtige Informationen für Projektmanager und Kunden. Aber letztendlich geht es darum, funktionierende Software zu liefern, egal wie.
Deswegen bin ich der Meinung, dass Scrum eher als Management-Tool betrachtet werden sollte. Es geht darum, zu klären, wer wann wofür verantwortlich ist. In Scrum gibt es klare Rollen: den Product Owner, der die Produktvision hat, das Team, das sich verpflichtet, in einem Sprint eine Leistung zu erbringen, und den Scrum Master, der vor allem eine organisatorische Rolle hat und dem Team helfen soll, sein Sprint-Commitment einzuhalten.
Der Scrum Master hat natürlich viele positive Eigenschaften. Er schützt das Team vor äußeren Einflüssen. Es gibt ja diese Witze, dass jemand mit einem Donut ankommt und fragt, ob man etwas schnell erledigen kann, und der Scrum Master antwortet, dass es für einen Donut nichts wird – das müssen schon zwei sein. Spaß beiseite, aber ihr versteht, was ich meine.
Wenn es um Projektplanung geht, kann ich aus meiner Erfahrung sagen, dass man durch die Velocity ein Gefühl dafür entwickelt, was die Geschwindigkeit des Teams ist. Diese wird im Laufe der Zeit zuverlässiger, es sei denn, es ändern sich die Parameter, wie zum Beispiel bei komplett neuen Aufgaben. Dann ist die alte Velocity nicht mehr belastbar, und man muss eine neue Prognose treffen. Es ist hilfreich, Stories in kleine Teile zu zerlegen und im Task-Splitting die Komplexität der Aufgabe zu bewerten und die Velocity anzupassen. Aber grundsätzlich basiert Scrum auf Iterationen, und das Team verpflichtet sich, die Aufgaben der Iteration umzusetzen. In der Praxis zeigt sich jedoch oft, dass dies schwierig ist.
Repetitive Tätigkeiten machen die Velocity verlässlicher und sind ein gutes Mittel zur Prognose. Aber wenn man an etwas arbeitet, das nicht bekannt ist, und die Velocity durch Storypoint-Schätzung ermittelt, wird es schwierig, das Commitment einzuhalten. Aus Managementsicht ist es angenehm zu sagen, dass das Team sich verpflichtet hat, eine bestimmte Velocity zu erreichen, aber dieser Ansatz zeigt sich bei unbekannten Aufgaben als problematisch.
Andere Methoden wie Kanban oder Extreme Programming sind näher an der Softwareentwicklung und damit an der Realität. Diese Methoden erkennen an, dass Softwareentwicklung oft unbekanntes Terrain ist, da es sich in der Regel um Individuallösungen handelt. Kanban und Extreme Programming sind daher dichter an der Softwareentwicklung als Scrum, das eher auf Projektmanagement fokussiert ist.
Was ich positiv über Scrum sagen kann, ist, dass der Guide klare Regeln vorgibt: Rollen, Rituale, Zeiträume für Daily, Refinement und Sprint Planning sind definiert. Das System ist relativ verlässlich. Im Vergleich dazu beschreibt der Kanban-Guide nur das grundlegende Vorgehen und setzt auf evolutionäres Change Management, das die aktuellen Prozesse berücksichtigt und kontinuierlich verbessert.
Ein schönes Gedankenspiel ist, dass Scrum als Gateway-Droge zur Agilität betrachtet werden kann. Die klaren Regeln machen es einfacher, zu starten, und später kann man Scrum möglicherweise hinter sich lassen. Wir hatten zum Beispiel das Problem, neben neuer Software auch ältere Software zu unterstützen, und mussten Anpassungen vornehmen. Das ist etwas, das Scrum nicht direkt vorsieht. Aber es gibt theoretische Ansätze und Firmen, die solche Anpassungen nutzen.
Kanban konzentriert sich auf den Flow und hat keine festen Zyklen oder Iterationen. Es ermöglicht, den Flow von der Entwicklungsanforderung bis zum Release zu optimieren und ist daher flexibler. Kanban ermöglicht auch eine transparente Steuerung von Support-Tätigkeiten und Prioritäten.
Zusammenfassend sehe ich Scrum als nützliches Werkzeug, aber auch als begrenzt. Die Gefahr der Verwässerung durch zusätzliche Features und Zertifikate ist groß. Mein Fazit ist, dass das Agile Manifest nach wie vor relevant ist und als Grundlage für Agilität dienen sollte.
Ich freue mich auf euer Feedback zu diesem Thema. Vielleicht habt ihr andere Erfahrungen gemacht oder nutzt Scrum anders als wir. Wenn ihr Feedback habt, könnt ihr mir eine Mail an nobsagile@gmail.com schicken oder mich auf Mastodon erreichen.
Habt eine tolle Woche und bis zum nächsten Mal!
