Effizient, erfolgreich – und in zwei Wochen erstellt Agile Lastenhefte für Entwicklungsprojekte

Häufig schon musste Troubleshooter Maik Pfingsten Projekte aus der Krise führen, die ohne Lastenheft gestartet waren. Denn nur mit Lastenheft versteht das Projektteam die Wünsche des Auftraggebers. Pfingsten hat daher über die Jahre eine Methode entwickelt, mit der er innerhalb von zwei Wochen ein hinreichendes Lastenheft erstellt. In diesem Beitrag erklärt er Schritt für Schritt, wie er dazu vorgeht.

 

Effizient, erfolgreich – und in zwei Wochen erstellt Agile Lastenhefte für Entwicklungsprojekte

Häufig schon musste Troubleshooter Maik Pfingsten Projekte aus der Krise führen, die ohne Lastenheft gestartet waren. Denn nur mit Lastenheft versteht das Projektteam die Wünsche des Auftraggebers. Pfingsten hat daher über die Jahre eine Methode entwickelt, mit der er innerhalb von zwei Wochen ein hinreichendes Lastenheft erstellt. In diesem Beitrag erklärt er Schritt für Schritt, wie er dazu vorgeht.

 

Ein Lastenheft leistet immer einen entscheidenden Beitrag zum Projekterfolg, denn es ist das "Wünsch-Dir-Was" des Auftraggebers, d.h. des externen Kunden oder der Marketingabteilung bzw. des Produktmanagements: Erst wenn ich die technischen Erwartungen meines Auftraggebers an das zu erstellende IT-System kenne, kann ich sie auch erfüllen.

Es gibt viele verschiedene Gründe, warum kein Lastenheft vorliegt. Die Erstellung ist zwar eigentlich Aufgabe des Auftraggebers, dieser ist jedoch häufig nicht in der Lage oder willens, die genauen Anforderungen zu spezifizieren, die er an das Projekt hat. Deshalb delegieren viele Auftraggeber diese Aufgabe an die Projektleitung.

Unternehmen, die ein Produkt direkt an den Endkunden verkaufen, haben keinen Auftraggeber, der ein Lastenheft vorgibt. Diese Aufgabe sollte das unternehmensinterne Produktmanagement übernehmen. In der Realität kommt das Produktmanagement dieser Aufgabe häufig jedoch nicht nach. Ein weiterer Grund kann sein, dass Projekte auf einer operativen Ebene vereinbart werden, d.h. die durchzuführenden Tätigkeiten werden abgestimmt, aber es wird versäumt, eindeutige, messbare und realistische Abnahmekriterien zu vereinbaren.

Grundlage für Verständnis über Wünsche und Anforderungen

In den über zehn Jahren als Troubleshooter in der Automobilentwicklung war es stets eine meiner ersten Aufgaben, in kurzer Zeit ein effektives Lastenheft zu erstellen, um eine sinnvolle Strategie aufbauen zu können, mit der ich das Projekt aus der Krise führte . Dementsprechend wurde jedem Mitglied eines Projektteams, mit dem ich begonnen habe, ein Lastenheft zu erstellen, erst durch diese Arbeit wirklich klar, was der Auftraggeber wünscht.

Zudem erhalten alle Beteiligten einen Überblick über das System sowie die Grundlage für Kosten- und Zeitpläne. Dennoch herrscht in vielen Projekten häufig die Meinung vor, dass ein Lastenheft nicht benötigt wird. Diese Ablehnung basiert auf unterschiedlichen Denkfehlern, auf die ich in der Folge näher eingehen werde. Das Resultat ist jedoch meist das gleiche: Das Projekt läuft Gefahr zu scheitern, weil die Wünsche und Anforderungen des Kunden nicht klar sind.

Über die Jahre habe ich einen smarten Prozess in fünf Schritten entwickelt, mit dem Sie für jedes Projekt innerhalb von zwei Wochen ein freigegebenes Lastenheft erstellen können – egal ob Sie im agilen oder im klassischen Umfeld agieren. Zwar erlangt solch ein "agiles" Lastenheft (weil kurzfristig erstellt) nicht die Güte und die Reife eines Lastenhefts, an dem über Wochen oder Monate hinweg gearbeitet wurde, jedoch war das Ergebnis immer wesentlich besser als das, was bis dahin in dem Projekt vorlag. Bei den Krisenprojekten, in die ich gerufen werde, reicht die Bandbreite von kein Lastenheft vorhanden bis hin zu Bergen von Lastenheften, die unbrauchbar waren.

Von Trugschlüssen und Irrtümern

Die Herangehensweise zur Erstellung des agilen Lastenhefts habe ich im Laufe der Jahre verfeinert und die fünf Schritte sukzessive perfektioniert. Bevor ich diese erläutere, möchte ich skizzieren, warum die Erstellung eines Lastenhefts im klassischen wie im agilen Kontext noch immer gescheut wird – und wie Sie als Verfechter agieren können, um dies für Ihre Entwicklungsprojekte zu ändern.

Denkfehler 1: Zeitmangel

"Wir haben schon mit dem Projekt begonnen und können nicht wieder von vorne anfangen." So wurde ich als Troubleshooter häufig begrüßt. Leider ist diese Vorgehensweise im Projektmanagement international sehr verbreitet: Erst einmal anfangen und sich dann Gedanken um die Anforderungen des Kunden machen.

Bildlich lässt sich das so darstellen: Es werden einfach Bagger bestellt, eine Grube ausgehoben und 50 Ingenieure beauftragt, ein Haus zu bauen – gefolgt von großem Staunen, weil die Küche auf dem Dach, die Garage auf der ersten Etage und Zeit und Geld weg sind. Würden Sie auch so vorgehen, wenn Sie 500.000 Euro in Ihr neues Eigenheim investieren wollen?

Denkfehler 2: Pflichtenheft

"Wir haben doch schon ein Pflichtenheft, das reicht." Auch dieser Denkfehler ist fatal, denn Lasten- und Pflichtenhefte haben völlig unterschiedliche Nutzen: Während das Lastenheft auf der Kundenebene angesiedelt ist und die Kundenwünsche beinhaltet, spielt das Pflichtenheft als Antwort auf diese Anforderungen auf der Systemebene eine Rolle. Beide müssen unabhängig voneinander existieren.

Denkfehler 3: Agilität

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
7 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 5
Kommentare 7

Alle Kommentare (7)

Dieter
Bertsch

Zu "Denkfehler 3: Agilität" &nbsp "Das Backlog ist nämlich auf der Ebene der Projektsicht bzw. des Pflichtenhefts angesiedelt – und damit die Antwort auf ein Lastenheft." &nbsp Die Aussage des Autors ist in diesem Punkt zu unspezifisch und verleitet damit zu einer falschen Schlussfolgerung! Im angesprochenen Produktmanagement-Framework Scrum gibt es zwei Ebenen des "Backlogs"; da Product Backlog und das Sprint Backlog (vergl. Scrum Guide von Ken Schwaber und Jeff Sutherland - den Erfindern von Scrum). &nbsp Das Product Backlog enthält dabei alle Anforderungen (das Was?) die zum aktuellen Zeitpunkt zu dem Produkt bekannt sind. Somit entspricht das Product Backlog als Liste von noch zu bearbeitenden Punkten ("Token" als Merkposten, damit nichts vergessen wird; und damit auf einer höheren Ebene als ein über x Wochen hin ausgearbeitetes, dickes Dokument) genau dem Lastenheft. &nbsp Erst beim Sprint Planning, also dem Meeting, bei dem ein Committment zwischen Auftraggeber (Product Owner genannt) und dem Entwicklungsteam über die umzusetzenden Anforderungen für die festgelegte Timebox (Sprint) herbeigeführt wird, werden die Anforderungen (zumeist in Form von User Stories) in Tasks zerlegt die beschreiben, was zu tun ist, um die Anforderung umzusetzen (das Wie?). Das ist dann die vom Autor angeführte "Antwort auf ein Lastenheft". &nbsp Hier scheint m.E. dem Autor einen Denkfehler in seiner Argumentation unterlaufen zu sein. Es geht in Scrum also gar nicht ohne Lastenheft. &nbsp Einen Fehler, den ich jedoch häufiger in Scrum-Umsetzungen beobachte ist, dass User Stories in einem Product Backlog nicht die fachlichen Anforderungen beschreiben (also das Was?), sondern schon einen Schritt weiter gehen und versuchen, die Umsetzung vorzugeben (also das Wie?). &nbsp Sollte diese falschen Anwendung des Scrum-Artefakts Product Backlog den Autor dazu verleitet haben, zu seiner These "Denkfehler Agilität" gekommen zu sein, dann ist es m.E. aber unredlich, diesen Fehler Scrum/Agile zuzuordnen. &nbsp Neben dem zuvor beschriebenen "Denkfehler" ist der gesamte Artikel von klassischer Projektmanagement-Denke geprägt. Woran mache ich das insbesondere fest? An den Ausführungen zu "Agil erfolgreich – ohne sich zu verbiegen": &nbsp Hier wird beschrieben, wie ich in Iterationen "die reife des Lastenhefts" erhöhe. Und am Ende habe ich das perfekte Lastenheft; aber noch nicht eine einzige nutzbare Funktion umgesetzt. Und wenn später für die vollständige Umsetzung kein Budget mehr vorhanden ist oder der Kunde doch nur einen Teil beauftragt, ist der Aufwand für den restlichen Teil des Lastenheftes vollkommen umsonst ausgegeben worden ("Muda" – Verschwendung). Genau das ist der klassische "Staffelstab"-Ansatz (vergl. "The new new product development" von Takeuchi & Nanoka). &nbsp Deshalb passt es m.E. nicht, den Beitrag mit "Agile Lastenhefte" zu betiteln. &nbsp Agil und insb. Scrum (der "Rugby"-Ansatz) beginnt ja sofort nach der Priorisierung der möglichst vollständigen Erfassung der Product Backlog-Einträge, die ja nur einen Token (einen Merker) für noch umzusetzende Anforderungen darstellen, mit der Verfeinerung der Anforderungen, dem Design, deren Umsetzung und Tests in Sprints mit einem multifunktionalen Team. Und so wird nur so viel Geld in das Lastenheft investiert, wie ich es auch für die Umsetzung der Funktionen benötige. &nbsp Dieser agile Ansatz wird für mich in den Ausführungen des Artikels weder allg. noch im Bezug zum Lastenheft transparent.

 

Danke für Ihr Feedback! Grundsätzlich haben Sie recht mit der Aufteilung eines Backlogs. Ich komme aus dem Maschinenbau und habe das leider so in der Industrie nie erlebt. Dort wird immer öfter Scrum eingesetzt, aber i.d.R. werden die Backlogs zusammengeschmissen und sind dann mit einem zusammengewürfelten Lasten- und Pflichtenheft sehr vergleichbar. Der Titel Agil bezieht sich auf die Prinzipien des agilen Manifest. Wenn Sie als Artefakt den Begriff "Software" gegen "Lastenheft" ersetzen, dann ist dieses Vorgehen agil.

 

Tassilo
Kubitz

Ich habe mit der Überschrift und dem dann folgenden Inhalt auch ein Problem. Der Inhalt ist m.E. reine klassische Denkform. Was das mit Agil zu tun hat, erschließt sich mir leider nicht. Den größten Widerstand löste bei mir die konsequente Betonung von Lastenheft und Pflichtenheft aus. Customer collaboration over contract negotiation - Bei "Customer collaboration" denke ich sofort an die gemeinsame Erstellung der "Spezifikation" (klassich) bzw. der "User Stories im Backlogs" (agil). Die Begrifflichkeit Lastenheft vs. Pflichtenheft fällt für mich eindeutig in den Bereich "contract negotiation". Die Begrifflichkeit Lastenheft/Pflichtenheft passt heutzutage nur noch bei Ausschreibungen, wo sich AN und AG physisch gar nicht näher kommen können, sollen, wollen.

 

Danke für Ihr Feedback! Im Maschinenbau ist "contract negotiation" durchaus normal. Hier sind zwei wirtschaftliche Instanzen involviert und sich dabei zu einigen. Mit Ausschreibungen wo sich AN und AG gar nicht näher kommen können, sollen, wollen hat das aber nichts zu tun. Der Titel Agil bezieht sich auf die Prinzipien des agilen Manifest. Wenn Sie als Artefakt den Begriff "Software" gegen "Lastenheft" ersetzen, dann ist dieses Vorgehen agil.

 

Ingo
Geppert

Sehr interessanter Artikel! Ich bin spontan auch über die Aussage gestolpert, dass bei Scrum ein Backlog dem Pflichtenheft entspricht. Meine Meinung dazu: In der Theorie ist das nicht so, in der Praxis sieht das manchmal anders aus. Ergänzend. Manchmal werden in das Backlog auch bewusst "künstliche" Stories aufgenommen, die eher technisch motiviert sind, zum Beispiel Refactoring oder ähnliches. Die Begriffe Lastenheft und Pflichtenheft mögen zwar in der "klassischen" Welt entstanden sein, können meines Erachtens aber auch bei agilem Vorgehen verwendet werden, auch wenn das nicht üblich ist. Für mich sind diese Begriffe recht gut geeignet, um zwei Dinge abzugrenzen: das, was der Kunde will, und das was er bekommt. Für meinen Geschmack wird das zu oft durcheinandergewürfelt.

 

Dieter
Bertsch

@Ingo Geppert zum Unterschied Lasten- & Pflichtenheft: &nbsp. "Das Pflichtenheft beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen des Auftraggebers zu lösen gedenkt – das sogenannte wie und womit. Der Auftraggeber beschreibt vorher im Lastenheft möglichst präzise die Gesamtheit der Forderungen – was er entwickelt oder produziert haben möchte."
Quelle: //de.wikipedia.org/wiki/Pflichtenheft &nbsp. Die Abgrenzung ist also das 'was' & das 'wie'! Die Darstellung als 'Auftrag' vs. 'Lieferung' ist methodisch nicht korrekt. &nbsp. @Ingo Geppert zum Product Backlog & User Stories: &nbsp. Ein Product Backlog (PB in Scrum) nimmt alle Anforderungen auf, die an ein Produkt bekannt sind. Scrum spricht von 'Backlog Items'. Die Technik der User Stories (US) stammt aus XP und dient der Beschreibung fachlicher Anforderungen (gemäß INVEST-Kriterien). &nbsp. Die Verwendung von "bewusst künstlichen Stories, die technisch motiviert sind" weist auf eine unzulängliche Verwendung der agilen Artefakte PB & US hin.

 

Marc
Schwede

Ein sehr interessanter Artikel und dennoch wirft er Fragen auf. Wie auch schon die anderen Leser zuvor schreiben, werden grundlegende Begriffe der Agilität falsch gedeutet und führen dann zu einem verkehrten Denkansatz. Im Abschnitt "Denkfehler 3 Agilität" sprechen Sie von agilen Methoden, die auf eine schnelle Umsetzung zielen, um früherkennbare Ergebnisse zu liefern. Die agilen Methoden, die in Scrum genutzt werden, zielen nicht auf "schnelle" Ergebnisse, sondern darauf "frühzeitig" dem Kunden / Auftraggeber ein Bild davon zu zeigen wie das Produkt aussehen wird. Eine "schnelle" Umsetzung kann gleichbedeutend auch mit nicht vollständig durchdachter Prozess verstanden werden. In vielen Diskussionen mit Beteiligten aus dem klassischen Projektmanagement führt genau dieser Denkansatz "Agilität hat eine Verbindung zu "schneller" Umsetzung" zu falschen Schlussfolgerungen.