Backlog-Geheimnisse für «schlimme Projekte»

Grosse, komplexe und Infrastrukturprojekte erfolgreich managen.

Backlog-Geheimnisse für «schlimme Projekte»

Für grosse, komplexe und für Infrastrukturprojekte ist Scrum ungeeignet. Es gibt bessere Ansätze, um solche Projekte mit Standardwerkzeugen sicher umzusetzen.

Thesen

  • Ungeeignetheit von Scrum für grosse und für Infrastrukturprojekte
  • Zulassungsbedingungen und Infrastruktur-Vorgaben als nicht-funktionale Anforderungen
  • FDD und DA als Alternativen
  • Werkzeuge für das Management komplexer Projekte

Backlog Secrets & schlimme Projekte

Der durchschlagende Erfolg von Scrum erklärt sich nicht zuletzt aus dem einfach anwendbaren Vorgehensmodell, das durch Klarheit und das Herstellen eines gemeinsamen Fokus effizientes und aufeinander abgestimmtes Handeln und durch die Zeitboxen eine zeitnahe Ressourcen- und Zielsteuerung ermöglicht.

Bei sehr grossen Projekten und bei Projekten in stark regulierten Kontexten, sowie bei Infrastrukturprojekten stösst das Vorgehen allerdings rasch an seine Grenzen.

Solche Projekte werden hier in Anlehnung an den Begriff wicked problems (https://en.wikipedia.org/wiki/Wicked_problem) als Schlimme Projekte bezeichnet.

In diesem Beitrag gehe ich Problemursachen nach und zeige bewährte Alternativen für das Projektmanagement auf und wie diese operativ umgesetzt werden können.

Ein Ausgangspunkt bildet dabei der Begriff des “Backlog” und seine Verwendung im Scrum Kontext.

Das Scrum Backlog als Produkt Backlog

Projekte und Technologien zielen auf die optimale Orchestrierung von Ressourcen und Methoden zur Erreichung von Zielen. Ein zentrales Instrument, das Scrum dafür vorsieht, sind gemischt funktionale Teams, eine zeitnahe Kommunikation und das sogenannte “Backlog”.

Das Scrum Backlog ist laut dem Scrum Guide ein “Produkt Backlog”, das alle Bestandteile des gewünschten Endprodukts nach ihrer Wertigkeit für den Kunden auflistet. Diese werden etappenweise in einzelne Sprint Backlogs gepackt und in Iterationen dem sich fortlaufend entwickelnden Arbeitsgegenstand hinzugefügt.

Entgegen der ewas irreführenden Bezeichnung — Backlog, ist ein Scrum Produktbacklog also eine modular aufgebaute Zieldefinition, ein Anforderungskatalog, der die Gestaltung des Produkts festlegt.

Ein Scrum Backlog enthält auch, entgegen der üblichen Hinterlegung in typischen Anforderungsmanagementsystemen wie Jira und Confluence, per se keine Tasks. Die Tasks sollen vielmehr vom gemischt-funktionalen Team aus den Anforderungen abgeleitet werden. Ein Scrum Team soll autonom agieren können und selbst entscheiden, wie es das gewünschte Produkt entwickeln möchte. Das funktioniert ausgezeichnet, wenn das Produkt eine relative Autonomie hat und für sich entwickelt werden kann. Insbesondere die User-Experience und die Ergonomie kann auf diese Weise optimal entfaltet werden.

Die hohe Effizienz, die Ziel- und die Produktfokussierung, die Scrum auf diese Weise bewirkt, wird allerdings durch das Ausklammern von Rahmenbedingungen erkauft. Ist das Produkt Teil einer grösseren Infrastruktur oder muss es bestimmten äusseren Anforderungen hinsichtlich Sicherheit, Robustheit oder Langlebigkeit genügen, wird das so entwickelte Produkt allerdings nicht oder nur schwer die notwendige Marktreife erreichen können.

Zu solchen Rahmenbedingungen gehören allgemein Informationssicherheit und Datenschutz, in regulierten Branchen wie Finanzen, Medizin oder Maschinenbau branchenspezifische technische Standards, bis hin zu sehr strikten Vorschriften für kritische Infrastrukturen (KRITIS).

Regulative als nicht-funktionale Anforderungen / Infrastruktur-Voraussetzungen

Nicht-funktionale Anforderungen wirken auf den ersten Blick nicht wertschöpfend. Sind sie allerdings notwendig, um die z. B. Zulassung eines Medizingeräts zu erreichen oder ein Gerät in einer grösseren Infrastruktur überhaupt erst nutzen zu können, sind sie matchentscheidend und wird ohne ihre Umsetzung lediglich Geld verbrannt (“sunk costs”).

Je früher sie als nicht-funktionale Anforderungen beachtet werden, umso wertschöpfender kann gearbeitet werden.

Solche Anforderungen sind in in der Regel zeitstabil und nicht direkt von möglicherweise volatilen Kundenwünschen abhängig. Sie können deshalb bereits zu Beginn konkret erfasst und für das Projekt aufbereitet werden.

Dafür ist in der Regel einschlägiges Expertenwissen (für Informationsarchitektur, Informationssicherheit, Datenschutz, branchenspezifische Standards, etc.) notwendig, wobei der oder die Expert:in nicht die ganze Projektlaufzeit fix im Team verbleiben muss, sondern auf Abruf bzw. in vordefinierten Intervallen das Thema jeweils nachverfolgen kann.

Verankerung im Projekt

Beschränkungen von Scrum

Scrum ist aus mehreren Gründen nicht die geeignete Methode, um so ein Projekt aufzusetzen:

  1. Nicht-funktionale regulative Anforderungen sind zu komplex und können deshalb nicht jeweils in einzelnen Sprints aufgenommen, beachtet und umgesetzt werden. Dies muss im Vorhinein erfolgen.
  2. Es macht keinen Sinn, die notwendigen Fachexpert:innen in die von Scrum vorgesehen gemischt-funktionalen Teams voll und fortlaufend einzubinden. Es genügt, wenn diese zu Beginn und anschliessend punktuell unterstützen.

Alternative Ansätze zur Umsetzung grosser Projekte und von Projekten in regulierten Kontexten

Feature Driven Development

Feature Driven Development (FDD) wurde zu Beginn der 2000er Jahr von Jeff de Luca entwickelt. Er eignet sich sehr gut für grosse Softwareprojekte. Er sieht vor, dass unter Federführung eines Software-Architekten zu Beginn eines Projekts komponentenbezogen Features definiert, danach in Featuresets organisiert und schliesslich die einzelnen Features implementiert werden.

FDD kombiniert damit ein akkordiertes, stufenweises Vorgehen, das Kritiker als Wasserfallbezug sehen, mit agilen Elementen. Dadurch wird sowohl die projektübergreifende Kohärenz als auch die zielorientierte Umsetz- und Testbarkeit sichergestellt.

FDD eignet sich sehr gut für sehr grosse Projekte und für Projekte, die einen Infrastrukturbezug aufweisen. FDD lässt sich auch problemlos im Rahmen von DA nutzen, das wir als nächstes näher anschauen.

Disciplined Agile

Disciplined Agile (DA, ursprünglich Disciplined Agile Delivery) wurde von den zwei IBM Mitarbeitern Scott Ambler and Mark Lines entwickelt.

DA sieht vor, dass beim Projektbeginn die passenden Rahmenbedingungen für den Projektkontext gesucht und festgelegt werden. Dafür können auch Fachexperten und/oder Lösungsexperten (Solution experts) beigezogen wwerden. Zu den festzulegenden Rahmenbedingungen gehören sowohl firmeninterne Erwartungen, regulative Rahmenbedingungen, als auch Vorgaben seitens einer vordefinierten Infrastruktur und die bevorzugte Arbeitsweise des Teams.

Diese Arbeitsweise wird als “Way of Work” (WoW) bezeichnet, den sich jedes DA-Team zurechtlegen kann. Auf diese Weise ermöglicht DA, dass die bekannten Methoden Scrum, Kanban, Wasserfall etc. eingebettet werden können, wodurch DA sowohl eine konkrete Projektmanagement-Methode als auch eine Meta-Managementmethode darstellt, die sich durch ihre inhärente Skalierbarkeit und die flexible Kombinierbarkeit mehr als jedes andere bisher bekannte Modell zur Skalierung (wie Safe oder Less) von agilen Arbeitsweisen in grossen Projekten und in Konzernen eignet.

DA sieht zum Abschluss eines Projekts auch die Umsetzung und Implementierung im Alltag vor. Nur die Verankerung in der realen (Firmenum-)Welt sichert die nachhaltige Wertschöpfung eines Projekts.

Unterkomplexität von Scrum

Nach Ashby’s Gesetz lässt sich ein komplexes Problem nicht mit einem unterkomplexen Ansatz lösen. Die Problemlösungskompetenz muss grösser sein als die Problemkomplexität, sonst wird das Problem ungelöst bleiben.

Ist die Problemkomplexität wegen der Grösse des Projekts, wegen grosser regulierender oder technischer Rahmenbedingungen zu gross, als dass sie von einem einzelnen Team innerhalb eines begrenzten Zeitraums gelöst werden kann, so erweist sich Scrum zu unterkomplex und damit als ungeeignet, um das Problem zu lösen.

Scrum selbst impliziert diese Beschränkung, weil es dem Team überlässt bzw. das Team sich selbst überlässt, wenn es darum geht, aus den produktbezogenen Anforderungen im “Produkt Backlog” die Art der Lösung und die dafür notwendigen Aufgaben abzuleiten. Scrum erhöht also den Aufmerksamkeitsfokus des konkreten Teams für eine bestimmte Zeit, ohne ihm die vorbereitende Berücksichtigung wichtiger Rahmenbedingungen, die Hinzunahme spezifischer Kompetenzen oder die über einen Sprint hinausgehende Zeitspanne für eien nachhaltige Lösungsfindung (ausnahmsweise) zuzugestehen.

Scrum vermischt im Produkt-Backlog die Zieldefinition des Produkts und die produktbezogenen Anforderungen und überlässt die Ausarbeitung sinnvoller Umsetzungsmassnahmen dem Team im Rahmen der Sprints.

Nicht-produktbezogen und nicht-funktionale Anforderungen werden dabei von Scrum ebenso wenig berücksichtigt wie die Tatsache, dass umso mehr Wertschöpfung entstehen kann, umso früher diese im Projektverlauf berücksichtigt werden.

Verwaiste und nicht anschlussfähige Pilotprojekte oder Proof of Concepts gibt es schon genug.

Empfehlung zur konkreten Umsetzung

Bei komplexeren Projekten reicht die Problemlösungskompetenz eines einzelnen Scrum Teams, das laut dem Scrum Guide nicht mehr als neun Teammitglieder beinhalten sollte, und aus der Zieldefinition selbständig die Anforderungen und die Massnahmen zu ihrer Erfüllung (Tasks) in beschränkten Zeitfenstern ausarbeiten sollen, nicht mehr aus.

In diesen Fällen wird eine mächtigere Problemlösungsmethodik benötigt. Diese wird sorgfältig zwischen Anforderungstypen und -granulierung (z. B. geschäftliche vs. funktionale vs. technische vs nicht-funktionale), darauf bezogenen Anwendungsfällen und Testkriterien sowie den Tasks zur sicheren Zielerreichung unterscheiden müssen.

Während früher ausgefeilte und hochspezialisierte Anforderungsmanagement-Systeme im Einsatz waren (wie z. B. Doors oder MKS), sind heute generische Werkzeuge wie Jira oder Confluence vorherrschend. Auch diese lassen sich so aufsetzen, dass ein nachhaltiger und effizienter Workflow aufgebaut werden kann, der mit mehr Komplexität umgehen kann, als ein einfaches Scrum-Projekt. Neben einer tiefen Werkzeugkenntnis sind auch entsprechende Plug-Ins dafür hilfreich.