PMI vs. Scrum: Staffellauf oder Rugbyspiel?

Im Projektgeschäft fordern die Kunden messbare Aussagen. Dabei ist zu Projektbeginn oft unklar, welches Ergebnis entstehen soll. Korrekte Aufwandsschätzungen bei gleichzeitiger Zielunsicherheit werden immer seltener. Mit dem ewig gleichen Ende: Das Projekt wird teurer, dauert länger oder scheitert gänzlich.

Dabei könnte durch den Einsatz verschiedener Steuerungswerkzeuge das Zielszenario schneller deutlich werden. Wir haben PMI und Scrum miteinander verglichen und dabei festgestellt: Der wesentliche Unterschied besteht in der Zeitdauer der Iterationen.

Was beim Bau eines großen Hauses funktioniert, das geht bei IT-Projekten schon lange. So oder ähnlich denken manche Projektmanager, wenn sie große Softwareentwicklungen angehen. Und setzen vertrauensvoll auf bekannte Managementmethoden. Die Bauherren großer Gewerke haben gut geplante Projekte vor Augen, Werkzeuge wie PMI kommen zum Einsatz. Durch die Projektplanung und die Modelle des Architekten wissen sie genau, wie das Bauwerk gen Himmel wächst. Meistens jedenfalls - siehe Berliner Flughafen.

Wenn alles bis zur letzten Steckdose geplant werden muss, bieten sich lineare Projektvorgehen geradezu an. Die klassische Methodik ermöglicht eine weltweit standardisierte und erprobte Durchführung, verwendet stets dieselbe Terminologie und kann große Projekte branchenunabhängig strukturieren.

Themen werden linear und wasserfallartig geplant, Teilprojekte werden initialisiert, Anforderungen erhoben, Pläne gemacht und Konzepte geschrieben. Schließlich erfolgen Phasen der Umsetzung, Kontrolle und Übergabe. Und am Schluss haben alle Beteiligten (hoffentlich) viel dazu gelernt. Sie nehmen sich dann vor, es beim nächsten Mal noch besser zu machen.

So bekommt ein Staffelläufer den Stab vom anderen. Und alle laufen vorher festgelegte Strecken. Sie müssen dabei keine weitreichenden Entscheidungen treffen oder Fragen beantworten wie:

• Wie soll das Projekt ablaufen und welche Abhängigkeiten bestehen?
• Welche Arbeitspakete werden mit wie viel Aufwand und in welcher Reihenfolge bearbeitet?
• Welche Ressourcen kommen zum Einsatz und wie wird deren Einsatz kontrolliert?

Meterweise Aktenordner inklusive. Doch finden sich in den Unterlagen „nur“ organisatorische Belange. Angaben zum Gemäuer sind nicht verzeichnet. Man erfährt „nur“ wie der Prozess rundherum organisiert ist. Der Kunde gewinnt an Sicherheit bezüglich des Gesamtaufwandes, verliert aber den Produktnutzen aus den Augen.

Wo bleibt der Produktnutzen?

Bekanntlich produzieren IT-Projekte keine Häuser. So sehr manch IT-Architektur auch einem eindrucksvollen Prachtbau ähnelt. Doch unabhängig vom Projektziel stehen die Beteiligten immer vor den gleichen Fragen: Was passiert, wenn die Vorgaben vorher noch nie umgesetzt wurden? Wenn sich während der Entwicklung die Anforderungen ändern? Wenn der Kunde spontan Funktionalitäten an Bord haben will, über die bei Projektstart nie gesprochen wurde?

Denn Kunden – und das ist keine Seltenheit – sind oft nicht in der Lage die Funktions- und Modulebenen einer Software zu beschreiben. Müssen sie auch nicht sein. Sie haben eine Vision des Produktes vor Augen. Das reicht. Den Rest übernehmen die Spezialisten. Und die setzen zunehmend agile Entwicklungsmethoden wie Scrum ein.

Dabei wird die Produkt-Vision in Module, Objekte und Aufgaben zerlegt. Release-Zyklen werden eingeteilt. Die Rugbyspieler kommen aufs Feld und müssen sportiv nach Situation entscheiden. Aus einfachen ergebnisorientierten Planspielen werden komplexe verlaufsorientierte Projekte. Die Kommunikation mit dem Kunden bezweckt dabei nicht die Definition der Gesamtstrecke sondern das Festlegen von Teilabschnitten. Nicht einmal. Sondern immer wieder.

Frühzeitig soll ein Kundennutzen erzeugt werden. Schneller entstehen klickbare Ergebnisse und abnehmbare Resultate. Die kurzen Iterationen und kleinen Prototypen der agilen Verfahren helfen bei der spielerischen Umsetzung des Tools. Funktionalitäten werden intuitiv vom Kunden verstanden.

Unbeantwortet bleiben anfangs Fragen nach Dauer und Kosten des Projektes. Ohne Vertrauen in die Leistungsstärke des Entwicklerteams geht’s nicht. Alle Beteiligten benötigen ein hohes Maß an Organisationsstärke und Krisenresistenz. Das Scrum-Team arbeitet so autark, dass es von der Technologie über sämtliche Anforderungen und die komplette Umsetzung selbst verantwortlich ist.

Das freut einige Entwickler. Denn ein Projektleiter klassischer Schule macht Druck. Bei Scrum entfällt die Rolle, der Organisationsaufwand jedoch nicht. Der verteilt sich nun auf‘s Team. Das ist die schlechte Nachricht für Entwickler: Sie müssen Leitungsaufgaben jetzt selbst übernehmen: Qualitäts- und Risikomanagement, Projektplanung und -steuerung sind eigenständig durchzuführen.

Bei Scrum geht es darum, in einem kleinen Team zusammen zu arbeiten, um einen Software-Erstellungsprozess zu organisieren. Die im Projekt-Management angedachten Phasen werden durch Scrum-Mechanismen ersetzt.

Das Team trifft sich täglich zum so genannten Daily Scrum: Wo stehen wir? Was ist heute dran? Was morgen? Große Boards an den Wänden dokumentieren den Verlauf. Die Artefakte geben die Aufgaben vor. Jeder sieht alles und jeden. Es gibt keine Kuschelzonen, die Mitarbeiter unterliegen ständiger Beobachtung.

Das Product Backlog enthält die Anforderungen, die im zu entwickelnden Produkt enthalten sein sollten. Das Sprint Backlog gibt eine Übersicht der für den festgelegten Zeitraum zu erledigenden Aufgaben. Ein Sprint dauert in der Regel zwei bis vier Wochen. Dann werden die Ergebnisse mit dem Kunden besprochen. Die weitere Marschroute wird festgelegt.

Der Scrum-Prozess

Mit Scrum hört das Orakeln auf

Als Scrum erstmalig 1995 vorgestellt wurde, beschrieb deren Erfinder Ken Schwaber das Tool mit folgenden Worten: „Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.“

Die Auffassung beruht auf den Ideen der so genannten schlanken Produktion, der lean production. Japanische Unternehmen streben seit den achtziger Jahren eine bessere Wertschöpfung durch stärkeres Teamworking an. Dabei spielt die bestmögliche Organisation der Ressource „Wissen“ eine entscheidende Rolle.

Die effizient systematisierte Produktionsorganisation soll verhindern, dass Schwankungen oder Verschwendungen im Fertigungsprozess entstehen. Die erstrebten Effekte werden vor allem durch das optimierte Zusammenspiel von Mensch und Technik erreicht.

Deshalb ist jedes Scrum-Team auf etwa sieben Mitarbeiter begrenzt. Kleinere Einheiten kommunizieren besser, die Streuverluste sind geringer. Wenn das Produkt es erfordert, arbeiten mehrere Leute in parallelen Scrum-Teams, die dann ihrerseits von weiteren Scrum-Einheiten gesteuert werden.

Die Rollen sind schnell erklärt. Product-Owner, Scrum-Master und das Entwickler-Team übernehmen folgende Aufgaben im Softwareentwicklungsprozess:

Der Product-Owner pflegt die Anforderungen und verhandelt diese mit dem Kunden. Er bewertet die Arbeitsergebnisse und bestimmt das Auslieferungsdatum des Produktes. Als kaufmännischer Projekt-Leiter trägt er finanzielle Ergebnisverantwortung. Die Rolle wird häufig als Flaschenhals gesehen, da dort alle Nachfragen auflaufen. Daher kann sie öfter vergeben werden.

Der Scrum-Master makelt die Kommunikation zwischen dem Management und den Team-Mitarbeitern. Er ist kein Teamchef, sondern Moderator, der täglich mit dem Team als Prozessverantwortlicher zusammenarbeitet. Als so genannter Servant-Leader klärt er offene Fragen, wirkt aber an der Produkterstellung nicht mit. Die Rolle wird in der Regel nur einmal besetzt.

Die Entwickler verfügen über spezielle technische Fähigkeiten, die während des Projektes zum Einsatz kommen. Sie arbeiten zusätzlich in den Bereichen Risikoabschätzung sowie Qualitäts- und Testmanagement. Ebenso führen sie Dokumentationen durch.

Die Aufgabe bestimmt die Methodik

Die Erfahrung zeigt, dass unerfahrene Entwickler nur schwer in Scrum-Teams zurechtkommen. Die Mitarbeiter müssen sofort mit Verantwortung umgehen können, denn sie kontrollieren sich selbst. Unschwer auszurechnen, dass ein Scrum-Team viel schneller auf Probleme bei der Umsetzung stößt als der klassische Projektleiter.

Darum müssen die Mitarbeiter fit sein im aktiven Selbstmanagement. Wie gehe ich mit Zweifeln, Denkhürden oder Produktivitätsproblemen um? Was tun, wenn die Kollegen blockiert sind? Diese Fragen offen zu diskutieren, erfordert eine besonders Teamleistung.

Speziell die jungen Entwickler wünschen sich gerne super agile Methoden. Schnell wundern sie sich darüber, wie viel Planungs- und Steuerungsaktivitäten sie selbst leisten müssen. Nach welchen Qualitäts- und Akzeptanzkriterien wird die Software beurteilt? Nach welchen Maßstäben getestet? Das muss im Detail durchdekliniert werden. Schließlich muss man sich an den eigenen Zielen messen lassen. Diese Selbststeuerungsaufgabe bedingt eine trennscharfe Bestimmung der eigenen Grenzen.

Scrum und PMI sollten nicht im Versus-Denken gegeneinander ausgespielt werden. Die Entscheidung für eine Methode hat mit der Aufgabenstellungen zu tun. Es existiert kein entweder oder. Beide Verfahren können auch parallel laufen. Das eine zieht hauptsächlich organisatorisch, das andere eher inhaltlich-technische Fäden. Sie ergänzen sich mit ihren jeweiligen Stärken.

Klassische Methoden eignen sich am besten für Projekte, in denen wenig oder keine Änderungen der Anforderungen zu erwarten, die Anforderungen klar sind und von allen Team-Mitgliedern gut verstanden werden. Agile Verfahren werden am besten für Projekte eingesetzt, die eine schnelle Reaktion auf Veränderungen und eine kontinuierliche Kommunikation mit den Kunden erfordern.