Agile Lastenhefte

In meiner aktiven Zeit als Troubleshooter habe ich über 10 Jahre lang internationale Entwicklungsprojekte gerettet: Dafür habe ich zunächst das Team wieder aufgebaut und die Lasten an das zu entwickelnde System geprüft. Für eine sinnvolle Strategie, die in den folgenden, harten Verhandlungen mit den Stakeholdern notwendig war, brauchte ich schließlich Klarheit über die Anforderungen. Das Ziel war stets, das Projekt in den nächsten sechs Monaten wieder auf die Gleise zu stellen und zum Erfolg zu führen.

An diesem Punkt hatten alle Projekte eines gemeinsam: Entweder gab es kein (erwähnenswertes) Lastenheft oder es gab einen meterhohen Stapel von Dokumenten, der nur mit einem Hubwagen bewegt werden konnte. Beide Situationen waren denkbar schlecht, denn in der ersten hatte ich nichts und in der zweiten hätte ich alleine für das Sichten sechs Monate gebraucht. Hinzu kommt, dass Ingenieure ungern Spezifikationen unterschreiben. Häufig muss man den Entscheidern hinterherlaufen und versuchen, eine Freigabe zu erhalten – oftmals mit dem Ergebnis, dass anstatt einer Unterschrift neue Anforderungen hinzugefügt werden sollen. Ich brauchte also einen anderen Weg, um innerhalb von zwei Wochen ein freigegebenes Lastenheft in der Hand halten zu können.  

Was ist ein Lastenheft – und was gehört da nicht rein?

Ein Lastenheft ist das „Wünsch-Dir-Was“ des Kunden. Es beschreibt die technischen Anforderungen an ein zu entwickelndes System. Es gibt zwei Arten von Anforderungen, wobei der Unterschied einfach, aber wesentlich ist: Die Projektanforderungen und die Systemanforderungen.

Projektanforderungen sind Anforderungen, die während des Projektes relevant sind, direkt nach dem Abschluss jedoch historisch werden, beispielsweise Budget, Meilensteine, benötigte Kapazitäten etc. Systemanforderungen hingegen sind die Anforderungen, die nach Abschluss des Entwicklungsprojektes bestehen bleiben. Anders ausgedrückt: Die Anforderungen an das Projekt vor zehn Jahren interessieren mich heute nicht mehr, aber das technische System ist noch immer beim Kunden im Einsatz.

In ein Lastenheft gehören die technischen Anforderungen an das System, während die Projektanforderungen in einem Projekthandbuch oder Projektauftrag festgehalten werden können.

Ein Lastenheft ist kein Pflichtenheft!

Ein Pflichtenheft hat eine ganz andere Funktion als ein Lastenheft, es ist sozusagen die Antwort eines Projektes auf das Lastenheft. Dort kläre ich die Anforderungen aus dem Lastenheft, kann sie ablehnen, übernehmen oder weiter detaillieren. Das Pflichtenheft kann klassisch als „System Requirements Specification“ oder im agilen Umfeld als „User-Stories“ und „Epics“ vorliegen.

Diese beiden Spezifikationen dürfen nicht miteinander vermischt werden: Das Lastenheft liegt in der Verantwortung des Kunden (des Marketing-/Produktmanagements) und das Pflichtenheft ist die Antwort des Entwicklungsprojektes.

Bei Vermischungen entstehen zwei Probleme: Erstens verliere ich die Möglichkeit, gewünschte von umzusetzenden Anforderungen zu trennen. Zweitens sind Lasten- und Pflichtenhefte oftmals rechtliche Bestandteile eines Vertrags – wenn ich sie nicht trenne, kann ich also rechtliche Probleme bekommen.

In zwei Wochen zur Freigabe

Wenn ich als Systemingenieur ein Lastenheft schreibe, benötige ich nach aller Kunst des Handwerks zwischen zwei und sechs Monaten. Um dies in zwei Wochen zu schaffen und eine Freigabe zu erhalten, brauche ich einen anderen, pragmatischeren Weg. Und so habe ich ein Vorgehen entwickelt, mit dem ich in zwei Wochen, fünf Schritten und mit zwei Regeln zu einem freigegebenen Lastenheft komme.

• Schritt 1: Erfassen – die Anforderungen sammeln

In einem Kickoff-Workshop sammle und visualisiere ich mit dem Projektteam, was das System und was die Anforderungen an das System sind. Anschließend halten wir mit Checklisten fest, welche Dokumente und Unterlagen existieren.

• Schritt 2: Sortieren – den Inhalt strukturieren

Jetzt sichte ich alle Informationen, bewerte, was sinnvoll ist, und fülle anschließend mein Lastenheft-Template. Danach arbeite ich das Ergebnis auf, prüfe die Requirements, die Grammatik etc.

• Schritt 3: Füllen – vorhandene Lücken schließen

In diesem Schritt kann ich die sichtbar gewordenen Lücken schließen, indem ich weitere Anforderungen recherchiere, sie bewerte, übertrage und anschließend wieder aufarbeite.

• Schritt 4: Prüfen – das Ergebnis reflektieren

Nun gebe ich das Lastenheft für einen Peer-Review in die Hände der Wissensträger, die es durchgehen und kommentieren. Häufig kommen noch viele Zusätze und Informationen zurück, aus denen ich neue Zwischenstände des Lastenhefts erstelle. Das Charmante an dieser Phase ist, dass zum Ende alle Beteiligten das Lastenheft inhaltlich kennen und Ihre Anmerkungen bereits gemacht haben. Somit ist hier schon fast alles geklärt – und genau das ist meine Strategie.

• Schritt 5: Freigabe – den finalen Stand erstellen

Mit dieser mehrfach geprüften Version gehen das Projektteam und ich in einen moderierten Review-Workshop und lesen noch einmal alles durch. Im Review-Protokoll wird alles, was uns aufgefallen ist, festgehalten und zudem für jede Änderung eine Empfehlung abgegeben. Sind schließlich alle Änderungen aus dem Review-Protokoll übertragen, erfolgt automatisch das Release und die Freigabe.

Es liegen nun ein Lastenheft und ein Review-Protokoll mit allen abgestellten Auffälligkeiten vor. Da alle ihren inhaltlichen Beitrag geleistet haben, sind für den Release keine weiteren Unterschriften nötig.

Die zwei Regeln

Um mit diesen fünf Schritten innerhalb von zwei Wochen durchzukommen, nutze ich zwei klar kommunizierte Regeln:

1. Wer da ist, ist da. Wer nicht da ist, stimmt zu. Durch diese Regel vermeide ich, dass nach den Workshops irgendwelche Macht-Strategen versuchen, das Lastenheft zu zerschießen. Ihr nachträglich und lauthals eingebrachter Beitrag kann gerne bei einem späteren Release berücksichtigt werden – für den jetzigen Stand ist die Tür zu.
2. Keine Rückmeldung ist Zustimmung. Wenn ich Peer-Review-Stände mit der Bitte um Rückmeldung herausgebe und im vereinbarten Zeitraum keine erhalte, wird das als Zustimmung gewertet. Wenn andere Aufgaben wichtiger sind, kein Problem – auch hier können nachträgliche Rückmeldungen gerne in einen späteren Release-Stand aufgenommen werden.

Klare Schritte – klare Regeln – und hohe Geschwindigkgeit

So können sich alle Beteiligten klar entscheiden, wie wichtig ihnen das Lastenheft ist. In der Praxis funktioniert das wunderbar, es gab sogar Kunden, die parallel ISO-9000-zertifiziert wurden und dank meiner Regeln trotzdem rechtzeitig wertvollen Inhalt geliefert haben.

Kann ein Lastenheft agil sein?

Ich werde oft gefragt, wie „agil“ so ein Lastenheft sein kann. Die Antwort ist einfach.

Ein Lastenheft ist ein wichtiges Artefakt im Umfeld eines Entwicklungsprojektes. Als Systemingenieur kann ich es in der klassischen Vorgehensweise erstellen – oder mich an die Prinzipien des agilen Manifests halten, denn das Wort „Software“ lässt sich hier sehr gut durch „Lastenheft“ ersetzen.

So kann ich ein Lastenheft auch im agilen Umfeld einsetzen: Ich erstelle einen ersten Stand, setze diesen z.B. mit Scrum um und schreibe zu einem wesentlichen Meilenstein im Projekt schnell einen nächsten Stand des Lastenheftes, der die neu gewonnen Erkenntnisse berücksichtigt.

Ein Lastenheft muss kein statisches Dokument sein. Es beschreibt nach bestem Wissen und Gewissen den aktuellen Stand der Wünsche und Anforderungen an ein System, nicht mehr – und nicht weniger!

Fazit

Ein in zwei Wochen erstelltes Lastenheft kann nicht den gleichen inhaltlichen Reifegrad haben wie ein Lastenheft nach der klassischen Vorgehensweise in zwei bis sechs Monaten. Das ist aber auch nicht das Ziel, denn bei einem agilen Lastenheft steht die pragmatische Vorgehensweise im Vordergrund. Ich brauche schnell ein korrektes, freigegebenes Lastenheft, um damit in die Umsetzung gehen zu können.

Aber auch der Einsatz in agilen Projekten ist möglich, denn ich kann über die Zeit mehrere Durchläufe starten und jeweils einen neuen Stand des Lastenheftes erstellen. So fügt sich diese Vorgehensweise wunderbar in ein agiles Umfeld ein.