Toyota hat es vorgemacht: Autos produziert man heute "Lean". Hergestellt wird nicht "auf Halde", sondern auf Bestellung, angeliefert werden nur die Teile, die sofort verbaut werden. Aber kann man auch Software so programmieren, wie man Autos herstellt? Ja, man kann! Ziel der schlanken Softwareentwicklung ist, die Durchlaufzeit von der Anforderung bis zur Inbetriebnahme der fertigen Software zu minimieren. Dabei reicht es aber nicht aus, Lean Software Development nur im Entwicklerteam anzuwenden: Auch der Anforderungs- und Konzeptionsprozess muss "Lean" organisiert sein. Erfolgskritisch ist hier der Aufbau und die Aufrechterhaltung eines gleichmäßigen "Kunden-Pulls", der effizientes Lean Software Development erst ermöglicht.

Dieser zweiteilige Artikel legt den Fokus genau auf die Schnittstelle zwischen den Anwendern und dem Entwicklerteam. Es wird gezeigt, wie Projektleiter und Auftraggeber die Projektmannschaft für ein Lean-Projekt ideal aufstellen, wie der Anforderungs- und Konzeptionsprozess schlank gesteuert wird und was es dabei zu beachten gilt. Auch wenn die ersten Erfahrungen mit diesem Vorgehen in Softwareprojekten bei Automobilherstellern gesammelt wurden, steht einer Anwendung der hier beschriebenen Konzepte auf andere Arten von Entwicklungsprojekten und Branchen methodisch nichts im Wege.

Der erste Teil beschreibt, was sich hinter Lean Management verbirgt und welche Anwendungen von Lean-Konzepten es in der Softwareentwicklung gibt. Es wird eine Projektaufbauorganisation beschrieben, die eine schlanke Softwarekonzeption ermöglicht und es wird das wichtigste Gremium – das Kernteam – und die wichtigste Rolle – die der Mandatsträger – dieser Organisation im Detail beschrieben. Der zweite Teil vervollständigt die Beschreibung der einzelnen Gremien und Rollen, wie z.B. des Projektleiters, und erläutert anhand eines Praxisbeispiels den Projektablauf. Der Artikel schließt mit Empfehlungen, die sich aus der Erfahrung mit diesem Vorgehen in Projekten ergeben haben.

Ich habe mit dem vorgestellten Projektvorgehen und der -organisation in meinen Projekten sehr gute Erfahrungen gemacht. Die Idee, die hinter diesem Vorgehen steht, ist aber nicht nur auf Projekte anwendbar, die ausschließlich nach Lean-Prinzipien durchgeführt werden, sondern auch auf Projekte, bei denen die nachgelagerte Realisierung der Konzepte nach anderen agilen oder sogar traditionellen Vorgehensmodellen (z.B. Wasserfall) erfolgt. Die Motivation für ein schlankes Vorgehen im Anforderungsmanagement und der Konzeption ist natürlich umso größer, wenn auch die übrige Projektdurchführung agil und schlank ist. Die hier vorgestellte Methodik soll als Anregung dienen, eine schlanke Projektorganisation für sich zu nutzen und weiterzuentwickeln.

Vorteile des Vorgehens

Die Vorteile des in diesem Beitrag gezeigten Vorgehens kommen erst bei einem ausreichenden Projektumfang zum Tragen: Die Laufzeit sollte mehr als sechs Monate betragen und das Projektteam mindestens zehn Vollzeit-Projektmitarbeiter umfassen. Andernfalls übersteigt der Aufwand für den Aufbau und die Etablierung der Projektorganisation, inklusive der Schulung der Projektmitarbeiter, den Nutzen des Vorgehens.

Um diesen Nutzen zu verdeutlichen, ist der Vergleich des geplanten Realisierungsumfangs mit den tatsächlich abgearbeiteten Leistungsumfängen pro Planungsintervall (in der Regel ein Jahr) aufschlussreich: Dabei zeigt sich, dass die pro Jahr erbrachte Entwicklungsleistung etwa doppelt so hoch war wie die ursprünglich geplante. Anders ausgedrückt: Mit den verfügbaren Kapazitäten für die Fachkonzeption ließen sich etwa doppelt so viele Themen konzipieren wie geplant. Die Planung basierte bei diesen Projekten im Wesentlichen auf Erfahrungswerten aus traditionellen Projekten: Wie viele Themen können in einem Jahr eine ausreichende fachliche Konzeptionsreife für die Realisierung erreichen? Natürlich lässt sich aus dieser Zahl nicht ableiten, dass das hier vorgestellte Vorgehen doppelt so gut ist wie beispielsweise das Wasserfall-Modell; es ist aber ein deutlicher Hinweis, dass das Arbeiten mit Lean-Konzepten wesentlich effizienter sein kann als traditionelle Vorgehensmodelle.

Das typische Projektumfeld, in dem dieses Vorgehen angewendet wurde, waren Projekte zur (Weiter-)Entwicklung und/oder Konsolidierung bestehender IT-Landschaften bei Automobilherstellern. Die Stärken des Vorgehens haben sich insbesondere dann gezeigt, wenn die umzusetzenden Anforderungen noch nicht vollständig Fachkonzeptreife hatten, sondern nur auf "Überschriften-Ebene", also z.B. nur grob in Form einer Themenaufstellung in einer Excel-Tabelle, bekannt waren. Für die Festlegung eines Budget- und Zeitrahmens, mit dem das Projektteam arbeiten kann, waren aber immer die Projekt-/Business-Ziele klar formuliert ("SMART") und es lag ein Projektstrukturplan mit definierten Arbeitspaket-Überschriften vor.

Die Leistungserbringung der einzelnen Arbeitspakete konnte stets in hinreichend kleine, unabhängige Losgrößen geschnitten werden. Dies ist eine wichtige Voraussetzung, da sich nur so eine kurze und gleichmäßige Projekttaktung erreichen lässt. Für die Projektdurchführung mit den Phasen Fachkonzeption, IT-Konzeption, Realisierung, Integrations- und Abnahmetests und Inbetriebnahme standen sowohl eigene Mitarbeiter der Fach- und IT-Abteilungen, als auch externe Berater und Lieferanten von IT-Dienstleistern zur Verfügung.