Scrum an sich macht niemanden zu einem besseren Software-Entwickler!
Und (Software-)Kanban macht als solches ebenfalls niemanden zu einem besseren Software-Entwickler (und ist – nebenbei bemerkt – auch kein Ersatz für Scrum! )
Und – nur um es noch mal deutlich zu machen – Scrum ist kein Synonym für "Agil" oder "Agile". Unter den Agilen Methoden sorgt zum Beispiel eXtreme Programming (XP) meiner Ansicht nach sehr wohl für gute Softwareentwicklung, solange man es ausreichend ernst nimmt.
Aber zurück zu Scrum. Das Schöne an Scrum ist ja gerade, dass es so universell einsetzbar ist! Um die deutsche Übersetzung des Scrum-Guide zu zitieren: „Scrum ist ein Framework, das die Entwicklung komplexer Produkte unterstützt.“ In diesem Satz steht nichts von Software – und wenn man den Scrum-Guide nach „Programm“ oder „Software“ durchsucht, wird man ebenfalls nicht fündig – egal, ob in der englischen Ausgabe vom Juli 2013 oder in der deutschen Übersetzung zum Stand 2011.
Eines der bekannteren Beispiele für die Anwendung von Scrum ausserhalb der Software-Entwicklung ist die Wartung von Formel-1 Wagen mit Scrum[1] – ich bin sicher, dass gerade hier von allen Team-Mitgliedern erwartet wird, dass sie ihr Handwerkszeug perfekt beherrschen.
Die Dinge, die dabei helfen, bessere Software-Entwickler zu werden, sind andere: Wissen über Entwurfsmuster (siehe auch: Wikipedia), Kenntnis von Architektur und Entwurfsprinzipien (z. B. SOLID (siehe auch: Wikipedia) und Co.), Einsatz von testgetriebenem Design, Programmieren in Paaren, kontinuierliche Integration und letztendlich – auch wenn aus einem gewissen Blickwinkel die konkrete Programmiersprache nicht so entscheidend sein mag – die Beherrschung der für die Umsetzung notwendigen Sprachen, Bibliotheken und Frameworks.
Wenn diese Elemente erfüllt sind, dann helfen Prozesse wie Scrum und Prozessverbesserungsmethoden wie die Kanban Methode (oder als englische Kurzübersicht) dabei, wirklich das zu entwickeln, was einen Wert für den Kunden darstellt, und sich nicht in Technikalitäten zu verlaufen, in der Analyse stecken zu bleiben oder in eine der vielen anderen Fallen des Projektmanagements zu laufen.
Analog zum alten Rezept für einen guten Grog („Rum muss, Zucker kann, Wasser braucht nicht“) an dieser Stelle daher mein Plädoyer:
- Technische Expertise: Notwendig, aber nicht hinreichend
- Kanban Methode: Sollte, aber nicht als einziges
- Scrum: Kann, aber nicht als einziges
Bis demnächst
Michael Mahlberg
[1] Die „Scrum in der Formel-1“ Geschichte hält sich seit Jahren, ich habe aber leider keine Primärquellen finden können
