Artikel zu Scrum – Was Leute über Scrum schreiben

Boris regt sich auf. Naja, ich rege mich auch manchmal auf aber ich bin ja kein ausgewiesener Experte und überhaupt leicht dabei einen roten Kopf zu bekommen.

Aber jetzt zurück zu Boris: Er hält den Artikel “Run on Scrum” für absolut falsch und möchte ihn am liebsten ignorieren – so schreibt er zumindest in seinem Artikel “Nettes aber unzulängliches Posting“. Interessanterweise hat er zitiert aber nicht verlinkt – wahrscheinlich wegen dem Ignorieren.

Also neugierig wie ich bin gleich Google-Gott befragt und wohl das zitierte Posting (s.o.) gefunden. Zunächst wird das Übliche über agile Entwicklungsmethoden und Scrum geschrieben. Nichts neues, nichts tolles aber auch nicht viel falschen. Naja, Stand vor ein paar Jahren – aber das trifft man heute überall im Netz.

Es fängt an mit Null-Aussagen wie:

Gelegentlich kann es bei agilen Methoden deshalb auch dazu kommen, dass Programme neu erstellt werden müssen.

Dann gibt es ein tolles Versprechen:

„Wassferfall“ Methoden sind eher auf ausführliche Abstimmungsprozesse ausgelegt um die bestmögliche Lösung in wenigen Iterationen zu erreichen.

Wasserfall – mein Traum! Bestmöglich – und dann auch noch in WENIGEN Iterationen. Warum eigentlich Iterationen im Wasserfall? Naja, iterative Projektausbaustufen oder so – geht schon.

Richtig ist die Aussage:

Mit vielen, klar strukturierten Meetings zum Teil auf täglicher Basis wird ein intensiver Kontakt zwischen der fachlichen und der technischen Seite des Projekts hergestellt.

Falsch allerdings:

Diese Gespräche werden nur grob und oft handschriftlich dokumentiert und ersetzten so oft die Dokumentation.

Hey, wenn ich als Product Owner als Teil des Ziels einer Story bzw. des How-to-Demo eine dicke Dokumentation möchte, dann bekomme ich diese auch. Auch in Scrum. Ich trage natürlich dafür die Verantwortung, dass die Dokumentation auch einen Wert (Business Value) hat.

Unter “Komplexe Sachverhalte” wird dann noch über Aktivitäten gesprochen, die unabhängig vom IT-Team sind. Ob diese vom Scrum-Team berücksichtigt werden sollen/müssen hängt natürlich stark von der Ausrichtung ab. Hier sehe ich schon die Option auch parallel zur Entwicklungsmanschafte Arbeitspakete im Projekt voranzutreiben. Übrigends ein Argrument für den agilen Projektleiter als zusätzliche Rolle im Projektgeschäft (neben den Rollen aus Scrum).

Falsch ist wieder, was unter “Pflege der Systeme” geschrieben wird. Einerseits hilft die meiste Dokumentation aus Wasserfall-Projekten nicht weiter (veraltet, inhaltslos, unverständlich) und andererseits soll sich gerade durch die Aufgabenteilung bei Scrum (Team statt Einzelperson) die Verfügbarkeit von Experten verbessern. Achja – und falls wirklich fachliche Dokumentation fehlen sollte, dann hat der Product Owner diese nicht bestellt und deshalb auch nicht bezahlt. Eine Entscheidung des Business eben.

Zur Aussage bzgl. interdisziplinären Teams habe ich eine ambivalente Haltung. Ich glaube bei IT-Entwicklungen hilft Scrum, weil es viele verschiedene IT-Experten (Rollen) in einem Team vereint. In vielen Projekten ist der Scope jedoch viel breiter und in diesem Fall wird IMHO in der klassischen Literatur zu Scrum zu stark vereinfacht: Der Product Owner kapselt die ganze Komplexität und gibt die Ansagen ans Entwicklungsteam. Es wird damit ausgeblendet, dass die eigentliche Wertschöpfung nur bedingt in der Entwicklung stattfinden (da diese ersetzbar ist).

Aber egal, letztendlich schließe ich mich Boris an. Wir vergessen manche Artikel lieber wieder, richtig?

Übrigens ist dies hier meine private Meinung. Ich habe keine Ahnung und behaupte einfach irgendwelches Zeug. Bitte nicht glauben. Am besten diesen Artikel nicht lesen oder gleich wieder vergessen ;-)

One thought on “Artikel zu Scrum – Was Leute über Scrum schreiben

  1. Der Artikel ist wirklich … hmmm …. miserabel und entspricht leider den häufig anzutreffenden Vorurteilen gegenüber agilen Vorgehensweisen.

    Trotzdem oder gerade deswegen: Aus Fairness dem Autor des Artikels gegenüber solltest Du Deine Kritik zumindest in seinem Blog als Kommentar zu verlinken.

Comments are closed.