Bauanleitung für Startups:Projektmanagement mit Scrum

Mit dem Projektmanagement-System Scrum lassen sich IT-Projekte so vorantreiben, dass immer alle wissen, wer wofür verantwortlich ist. Der Wasserfall wird umgedreht.

Von Dorian Selz, Nektoon

Die Erfindung von Computern war dicht gefolgt von ihrem Zwillingsbruder: Dem Scheitern grosser IT-Projekte. Die Informatik-Geschichte ist voll von den Trümmern solcher Ereignisse.

In den fünfziger und sechziger Jahren erledigten die Abteilungsleiter genau die Arbeit, die ihrer Abteilung zugedacht war, und warfen dann den Ball in die IT-Abteilung in der Hoffnung, dass jemand in der IT-Entwicklung das Projekt auffangen würde. Dann wuschen sie ihre Hände in Unschuld, für den Fall, dass etwas schiefgehen würde.

Die IT-Abteilung erklärte üblicherweise die Vorgaben für ungenügend und schob die Verantwortung zurück. Wie auch immer:

Das eigentliche Problem war, dass der Kunde keinen eindeutigen Ansprechpartner hatte.

Diese Debatte brachte ein paar bemerkenswerte Bücher hervor (Affiliate-Link). Eins, das mir besonders gefällt, ist Fred Brooks’ “The Mythical Man-Month: Essays on Software Engineering”. (Affiliate-Link) Es basiert auf seiner Erfahrung bei der Leitung des IBM OS/360-Projekts.

In den neunziger Jahren haben einige Leute angefangen, über den Zaun auf die japanische Art des Engineering zu zu gucken. Eine solche Technik heisst „Sashimi“. Aus dieser Sichtweise heraus entstand Scrum.

Das grundlegende Problem mit der traditionellen Wasserfall-Projektführung ist der Fokus auf Qualität und tiefe Kosten. Die Scrum-Erfinder haben erkannt, dass Software-Projekte zusätzlich Geschwindigkeit und Flexibilität brauchen. Und sie haben entdeckt, dass es Leute gibt, welche die Projektarbeit erledigen und andere, die ein anders gelagertes Interesse an der Umsetzung haben:

„Ein Schwein und ein Huhn spazieren die Strasse entlang. Das Huhn schaut zum Schwein auf und sagt: Hey, warum eröffnen wir nicht ein Restaurant?“ Das Schwein blickt das Huhn an und sagt: Gute Idee, und wie nennen wir es?“ Das Huhn denkt nach und sagt: „Warum nennen wir es nicht ‚Schinken und Ei‘?“ – „Nur über meine Leiche: Ich wäre mit Haut und Haar dabei, während Du nur involviert wärst.“ (Englischer Originaltext: „I’d be committed, but you’d only be involved.“)

Die „Schweine“ opfern sich auf für ein Softwareprojekt, während alle anderen – die „Hühner“ – zwar interessiert sind, aber dem Resultat unberührt gegenüber stehen: Sie würden sich nie ganz einsetzen.

Diese Unterscheidung und das speziell agile Setup der Methode sind die Kennzeichen von Scrum.

Inzwischen gibt es haufenweise Beweise, dass flexible Methoden die Softwareentwicklung sehr positiv beeinflussen. Bei local.ch haben wir solche Methoden benutzt, wobei wir die Plattform in Release-Zyklen von etwa vier Wochen entwickelt haben. Mit der Zeit begannen erste Teams, Scrum zu benutzen. Bei Nektoon planen wir, Scrum von allem Beginn an einzusetzen.

Wie das geht?

Zuerst haben wir im letzten Jahr die strategischen Ziele für 2009 gesetzt. Sie wurden aufgeteilt in eine Roadmap für den Jahresverlauf. Beispiel: Wir haben uns zum Ziel gesetzt, einen Beta-Release im späten Frühling zu veröffentlichen. Heute sind wir einen zweiwöchigen Sprint davon entfernt.

In einem nächsten Schritt definieren wir die Produktlinie. Wir bezeichnen sie als Stories. Jede Story kriegt eine Punktzahl als Indikator für die Komplexität und Schwierigkeit.

Jeden zweiten Montag setzen wir uns zusammen und gehen die Liste durch. Wir setzen die Prioritäten und wählen die Stories für den nächsten zwei Wochen Sprint aus. Gleichzeitig wird jede Story in Aufgaben aufgeteilt. Für jeden Auftrag bestimmen wir die Zahl der nötigen Arbeitsstunden. Dann machen wir uns an die Arbeit.

Wichtig: Das Verfahren wenden wir nicht nur für die Ingenieursaufgaben an, sondern auch für die Unternehmerstories. Zum Beispiel haben wir für Marketingzwecke die Produktion eines Videos in eine Story überführt. Diese Story und die damit verbundenen Aufgaben sind Teil des aktuellen Sprints.

Dann gibt es die Problematik des Controlling: Jeden Morgen besprechen wir kurz drei Fragen: Was habe ich gestern erledigt, was werde ich heute erledigen, und was sind die Hindernisse, die mich blockieren? Um den Überblick zu behalten, schreiben wir ein Status-Update für jede Person in unser Wiki.

Am Ende jedes Sprints gehen wir jede Story durch, führen die entwickelten Features vor oder präsentieren die verknüpften Business-Stories. Das ist wichtig, um ein zusammenhängendes Feedback zu kriegen.

Man könnte sagen, das sei zu aufwändig für ein Startup mit nur grade fünf Leuten. Wir halten dagegen. Das Tempo und der Rhythmus, die wir jetzt vorgeben, werden Tempo und Rhythmus der ganzen Firma bleiben.

Wir wollen einige simple Dinge mit dieser Methode erreichen:

• Den Überblick darüber, woran wir grade arbeiten und was es zum ganzen beiträgt.
• Das Team mit den Erfolgschancen auszustatten
• Eine klare Kommunikationsstrategie einzuführen. und den klaren Fokus auf unser Hauptziel zu wahren.

Scrum

[postlist „Startup-Bauanleitung“]