Scrum - unvollständig

10.05.2011 Permalink

Seit einigen Jahren drängt sich in Sachen agiler Softwareentwicklung die Methode "Scrum" (Einführung) -- zumindest in meiner Wahrnehmung -- in den Vordergrund. Auf Veranstaltungen und bei Kunden höre ich dagegen sehr selten die Namen eXtreme Programming, Crystal Clear oder Feature Driven Development. Auf der einen Seite ist es mir egal, welchen Namen das Kind trägt. Alle bringen die grundlegenden, sehr wertvollen Eigenschaften mit, die in umfangreichen Softwareprozessen leichter unter die Räder kommen. Darunter sind z.B.: Der Marketingerfolg von Scrum macht mir auf der anderen Seite jedoch etwas Sorge, denn Scrum ist in puncto Handwerkszeug der Softwareentwicklung gewollt still. Offen bleiben daher zunächst Fragen wie: Natürlich findet man Unmengen von Material im Netz und in Büchern, wie man dieses oder jenes mit den Grundelementen von Scrum verknüpft. Doch diese Meinungen sind -- wenig überraschend -- weder vollständig noch widerspruchsfrei. Zunächst steht das Team, das Scrum einführen will, also vor der Aufgabe, Scrum den Rahmenbedingungen entsprechend anzufüttern, denn Scrum nach der reinen Lehre taugt nur etwas für Micky Maus Projekte. Das erinnert mich lustigerweise an die schwergewichtigen Prozesse wie RUP oder V-Modell XT, die auch erst durch Customizing, d.h. Formen und Beschneiden der umfangreichen Prozessbeschreibung, brauchbar werden. Beides erfordert sehr praxiserfahrene Mitarbeiter oder Berater (aha!).

Ich würde trotz meiner Kritik an Scrum eher den einfachen, agilen Prozess als Ausgangspunkt wählen und in diesen Software spezifische Aktivitäten einbetten, als einen Prozess wie RUP zurechtzuschneiden. Denn agile Verfahren sichern, dass man schon nach Wochen die Fähigkeit, laufende Software zu bauen, einschätzen kann, während sich Projekte, die aufwändigen Prozessen folgen, Monate mit sich selbst beschäftigen können, ohne den maßgeblichen Prüfstein "potentially shippable product" zu passieren.