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.
- Bauanleitung für Startups: Der Kunde ist König (8. Mai 2009)
- Bauanleitung für Startups: Die Summe der Teile (18. Mai 2009)
- Bauanleitung für Startups: Projektmanager-Inflation (3. Juni 2009)
- Bauanleitung für Startups: Projektmanagement mit Scrum (22. Juni 2009)
- Bauanleitung für Startups: Wiki statt Office (10. Juli 2009)
- Bauanleitung für Startups: Prozesse und Kontrolle mit Jira (24. Juli 2009)
- Bauanleitung für ein Startup: Share Nothing Architecture (11. August 2009)
- Bauanleitung für Startups: Automation – Keiner da… (19. August 2009)
- Bauanleitung für Startups: Virtualisierung – wirklich keiner da… (8. September 2009)
- Bauanleitung für Startups: Irren ist menschlich, Testing nötig (7. Oktober 2009)
- Bauanleitung für Startups: Eine Nation von Netzwerken (15. Oktober 2009)
Artikel per Feed
Artikel per E-Mail
Artikel bei Twitter
Facebook-Seite
Als weiteres Problem bleibt die Rechtschreibekontrolle welche nach jedem Schritt konsequent durchgeführt werden sollte. Besonders nach dem Verfassen von Blogartikeln. ;-)
Als einen mindestens ebenso wichtigen Kerngedanken wie den eindeutigen Ansprechpartner sehe ich bei sämtlichen Agilen Entwicklungsmodellen eben die Agilität an. Das kam mir ein wenig zu kurz bei deinem interessanten Post ;)
Die dem Wasserfall zugrundeliegende Vorstellung, eine das gesamte Projekt beinhaltende Roadmap ließe sich zu Beginn eines Projekts aufstellen, wird ein »Embrace Chaos« entgegengesetzt. Kundenwünsche ändern sich während des Projektverlaufs, das ist Fakt. Agile Modelle wie Scrum setzen statt dem »Big Plan Upfront« auf kurze Iterationen. So wird das Risiko eines Komplettfehlschlags minimiert – immer wieder lässt sich stattdessen der Kurs feinkorrigieren. Auf Basis von Erfahrungen aus der Realität, bspw. veröffentlichten Features, nicht von spekulativen Annahmen vorab.
Hmpf, nachdem die meisten Rechtschreibefehler kommentarlos entfernt wurden steht mein erster Kommentar natürlich etwas arrogant da… Bitte ignorieren.
@Christian: Ich freue mich in den Blogs über die aktive Mitarbeit der Leserschaft. Konkrete Hinweise wären allerdings deutlich hilfreicher als knappe Bemerkungen – auch bezüglich der “meisten” Rechtschreibefehler.
Ergänzung: Die Fehler stammen übrigens von mir, Dorian Selz’ Postings werden jeweils von mir übersetzt. Er ist also absolut unschuldig.
Meiner Meinung nach ist die Kommata-Konzentration noch etwas hoch: Im zweiten Absatz sind meinen Schätzungen zufolge etwa 3 Kommas zu viel. Das zieht sich weiter durch den Text.
Grins, jetzt stehe ich schon wieder arrogant und rechthaberisch da, das war eigentlich nicht meine Absicht.
Inhaltlich finde ich den Scrum-Ansatz interessant. Ihn selber anzuwenden fände ich in meinem Umfeld übertrieben. Deshalb die Frage an den Originalautor: Wieviele Mitarbeiter arbeiten bei euch jeweils in einzelnen Scrum-Projekten?
Im zweiten Absatz hat’s kein Komma – es sei denn, Du zählst den Lead als ersten Absatz. Und bevor ich eine zweite Meinung kriege, lösche ich kein Komma. Wir haben sowieso eher zu wenig davon in unsern Blogs…
@Christian: Im neuen Setup sind wir zur Zeit nur 5 Personen. Werden aber hoffentlich bald viele mehr! Bei local.ch haben wir agile Setups mit weit über 50 involvierten Personen gefahren. Problem dabei waren die unterschiedlichen Niveaus bezüglich agiler Projektmethodik. Insgesamt, scheint mir aber der Weg allemal gangbar auch für grössere Firmen.
@Julia: Wir haben uns ein grosses Jahresziel gesetzt. An der Strategie halten wir fest. Richtig, unterwegs sind wir in der Lage, uns taktisch immer wieder an die Situation anzupassen. Dieser Zusammenhang – wie er in Scrum abgebildet ist – von übergreifendem Ziel (Strategie) und täglich angepasstem Vorgehen (Taktik), ist nicht neu. Militärstrategen denken darüber seit Jahrtausenden nach.
@Peter: Danke für Deine Unterstützung beim Publizieren!