Stellen Sie sich gefälligst hinten an!
Wer den Song der Ersten Allgemeinen Verunsicherung über einen misslungenen Banküberfall kennt, kann die Formulierung einordnen. Die energische Dame bringt damit den Bankräuber aus dem Konzept.
Die Regel, dass man sich bei einer Warteschlange nicht vordrängen darf, gilt für zahlreiche Alltagssituationen. Sie klingt einfach, ist es aber nicht. Sie wird auch oft missachtet, nicht nur von Bankräubern.
Im Supermarkt wird manchmal eine zusätzliche Kassa eröffnet und dann stellt sich die Frage, ob ich zu dieser wechseln soll und ob es OK ist, dass ich damit andere überhole. Lasse ich Leute vor, die nur sehr wenige Artikel haben und was ist, wenn gleich zwei solche hinter mir stehen? Im Autoverkehr gilt das Reißverschlussprinzip als Empfehlung beim Zusammenführen von zwei Kolonnen, ist aber keine verbindliche Regel.
Bei diesen Entscheidungen mischen sich Fragen der Effizienz mit solchen der Moral oder zumindest des guten Benehmens. Aber selbst die Effizienfrage ist nicht klar zu beantworten. Zählt die Effizienz des Gesamtsystems (durchschnittliche Wartezeit aller Kunden und Umsatz je Kassa) oder die einer einzelnen Person (meine persönliche Wartezeit)? Was ist gerecht oder aus anderen Gründen moralisch geboten (etwa beim Zahnarzt Personen mit akuten Schmerzen vorzulassen und dafür selbst eine längere Wartezeit in Kauf zu nehmen)?
Ich breche hier ab, denn es ist ein unendliches Thema mit hoher Emotionalität. Ich wollte damit nur demonstrieren, dass der Umgang mit Warteschlangen bei weitem nicht nur ein mathematisch komplexes Feld ist, wie es etwa der Wikipedia-Eintrag zur Warteschlangentheorievermuten ließe.
Agil = Backlog? Oder doch nicht?
Agile Vorgehensmodelle haben die Frage der Reihung von Anforderungen in einer Weise sichtbar gemacht, wie es in klassischen Vorgehensmodellen nicht der Fall war. Ein Lasten- oder Pflichtenheft beinhaltet eine vollständige Beschreibung der Anforderungen, jedenfalls ist das der Anspruch. Dort gibt es natürlich auch Aussagen zur Wichtigkeit und Dringlichkeit von Anforderungen, meist in Form einer Zuordnung zu Meilensteinen oder Phasen der gewünschten Umsetzung.
Scrum hat mit dem Konzept des Backlogs als einer geordneten Reihe von einzelnen Anforderungen (Backlog-Items, meist immer noch als User-Stories bezeichnet) ein Modell des Umgangs mit Anforderungen geschaffen, das vielfach mit agilem Vorgehen gleichgesetzt wird. Dabei wird übersehen, dass andere agile Ansätze kein so striktes Warteschlangen-Konzept kennen. Natürlich verlangen auch XP oder Lean von den „Kunden“ Aussagen über Wichtigkeit und Dringlichkeit von Anforderungen, aber es wird nicht erwartet, dass diese vom Kunden gereiht werden. Bei XP ist das ausdrücklich Gegenstand eines ständigen Dialogs, Kanban optimiert den Durchsatz, nicht zuletzt durch Vermeiden von Überlastung des Systems (WIP-Limit: Work in Progress wird auf die verfügbare Kapazität abgestimmt).
Womit der Scrum-Guide zweifellos recht hat ist die Klarstellung, dass in einem Projekt Entscheidungen getroffen werden müssen, was in welcher Reihenfolge erledigt werden soll: es muss priorisiert werden. Das ins allgemeine Bewusstsein gehoben zu haben, ist ein Verdienst des Scrum-Frameworks. Die Lösung ist allerdings höchst unvollständig.
Was ist Priorisierung?
Priorisierung soll sicherstellen, dass Ressourcen wie Zeit, Geld oder Personal für diejenigen Aktivitäten eingesetzt werden, die den höchsten Beitrag zur Erreichung der gesetzten Ziele liefern.
Dabei werden meist zwei Aspekte unterschieden: Wichtigkeit und Dringlichkeit.
Als Standard für den Umgang mit diesen beiden Aspekten gilt die sogenannte Eisenhower-Matrix (benannt nach dem ehemaligen US-Präsidenten). Sie teilt Aufgaben in vier Kategorien auf, die grafisch als Quadranten dargestellt werden.
Die Mutter aller Priorisierungsregeln: Die Eisenhower-Matrix
So lauten die Empfehlungen zur Anwendung dieser Matrix:
Wichtig und dringend (Quadrant 1): Höchste Priorität. Diese Aufgaben sollten sofort erledigt werden, da sie einen direkten Einfluss auf die Erreichung der Ziele und den Umgang mit dringenden Problemen haben.
Wichtig, aber nicht dringend (Quadrant 2): Zweithöchste Priorität. Sie tragen zur Erreichung der langfristigen Ziele bei. Diese müssen besonders beachtet werden, weil sie leicht aufgrund von Belastungen durch operative Aufgaben (siehe nächste Kategorie) vernachlässigt werden.
Nicht wichtig, aber dringend (Quadrant 3): Diese sollten nach den wichtigen Aufgaben erledigt werden. Nach Möglichkeit sollten diese delegiert (bzw. outgesourct) werden.
Nicht wichtig und nicht dringend (Quadrant 4): Diese sollten möglichst eliminiert oder mit minimalem Aufwand erledigt werden.
Die Matrix, selbst schon eine starke Vereinfachung der realen Herausforderungen, ergibt allerdings keine eindimensionale Reihung, wie sie für einen Backlog gefordert wird.
So einfach und klar das Modell auch scheint, allein die Frage der Entscheidung, was wichtig oder nicht wichtig ist, ist alles andere als trivial. Gleiches gilt für die Dringlichkeit. Wer trifft diese Entscheidung? Nach welchen Kriterien werden Anforderungen als mehr oder weniger wichtig oder dringlich klassifiziert?
Scrum: Es darf nur einen geben!
Scrum macht es sich leicht. Wie die „Reihenfolge des Product Backlogs“ zustande kommt, ist eine Entscheidung des/der Product Owner:in, die von der gesamten Organisation zu respektieren ist, so der Scrum Guide 2020. Diese Allmacht des Product Owners klingt gut, in Wirklichkeit ist es aber eine Folge des Ursprungs von Scrum aus einer rein technischen Perspektive. Die Entwickler wollen die Entscheidung, in welcher Reihenfolge die Anforderungen zu erledigen sind, nicht in ihre Verantwortung übernehmen. Sie wollen wissen, was sie zu tun haben und dabei nicht gestört werden. Insofern propagiert Scrum – ich sage das immer wieder – ein Paradies für Entwickler und das erklärt die Beliebtheit dieses Frameworks in der technischen Community. Der Erfolg eines Projektes oder Programms hängt allerdings nur zu einem Teil von der Effizienz der Entwicklungsarbeit ab und insofern ist Scrum in einer gefährlichen Weise unvollständig. Dazu habe ich schon in einem früheren Blogbeitrag mehr gesagt.
Erste Komplikation: Das Ganze ist mehr als die Summe seiner Teile
Es ist eine gute Idee, große Aufgaben in kleine Einheiten herunterzubrechen und diese dann schrittweise abzuarbeiten. Wenn man allerdings zu früh mit der Zerlegung beginnt oder überhaupt nur mit der Sammlung von User-Stories beginnt, sieht man den Wald vor lauter Bäumen nicht mehr. Die Backlog-Items stehen in Wechselwirkung, sie gehören möglicherweise zu unterschiedlichen Teilsystemen. Ich habe immer wieder erlebt, dass sich agile Projekte mit Releaseterminen schwer tun, die völlig unabhängig von den konkreten Inhalten fixiert werden, weil das aus organisatorischen Gründen, wegen der erforderlichen Inormations- und Schulungsaufwände, der Aufwände für Fachtest und Abnahmen etc. nur so lösbar ist. Bei der Entscheidung, welche Backlog-Items im nächsten Sprint bearbeitet werden, kann nicht nur ihr Business-Nutzen isoliert betrachtet werden, auch weniger wertvolle Items müssen manchmal umgesetzt werden, weil sonst das Deployment eines Releases nicht funktionieren würde.
Hier muss man anerkennen, dass SAFe sich dieser Herausforderung stellt und systematisch abhandelt. Neben der Team-Ebene (in der Wahrnehmung von Agilität meist die einzige) kennt SAFe mehrere weitere Ebenen, die unterschiedliche Aspekte der Organisation und Koordination von großen Programmen und Portfolios abdecken. Hier sind die wichtigsten Ebenen im SAFe-Framework:
1. Team-Ebene:
Ziel: Hier arbeiten agile Teams (Scrum, Kanban oder XP) und liefern in kurzen Iterationen (Sprints) inkrementelle Wertschöpfung.
Elemente: Agile Teams, Iterationen, Scrum Master, Product Owner, Backlog, etc.
2. Programm-Ebene:
Ziel: Diese Ebene koordiniert mehrere agile Teams, die zusammenarbeiten, um ein gemeinsames Produkt oder System zu liefern.
Elemente:
Agile Release Train (ART): Ein Zug (Train) aus mehreren agilen Teams, die synchronisiert arbeiten, um regelmäßig wertvolle Inkremente zu liefern.
Program Increment (PI): Ein Zeitrahmen (typischerweise 8-12 Wochen), innerhalb dessen der ART inkrementelle Wertschöpfung liefert.
Release Train Engineer (RTE): Ein Coach und Manager des ART.
Program Backlog: Eine Sammlung von Features und Enablern, die für den ART priorisiert werden.
3. Solution-Ebene (optional):
Ziel: Diese Ebene wird verwendet, wenn ein Unternehmen sehr große, komplexe Lösungen entwickelt, die mehrere ARTs umfassen.
Elemente:
Solution Train: Koordiniert mehrere ARTs und Lieferanten, um eine umfassende Lösung zu entwickeln.
Solution Architect/Engineering: Verantworlich für die technische Vision und Architektur der Lösung.
Solution Management: Verantwortlich für die Priorisierung der Solution Backlog und die Wertmaximierung.
Solution Backlog: Eine Sammlung von Capabilities, die die großen Funktionsblöcke einer Lösung darstellen.
4. Portfolio-Ebene:
– Ziel: Diese Ebene steuert die gesamte Produktentwicklung und Ausrichtung der Geschäftsinvestitionen auf die strategischen Ziele der Organisation.
Elemente:
Lean Portfolio Management (LPM): Verwalten des Portfolios an Programmen und Budgets.
Epic Owners: Verantwortlich für die Steuerung von Epics (große Initiativen, die mehrere ARTs betreffen).
Portfolio Backlog: Eine Sammlung von Epics und anderen Initiativen, die die strategische Ausrichtung der Organisation unterstützen.
– Strategic Themes: Leitende Geschäftsziele, die die Prioritäten des Portfolios beeinflussen.
5. Enterprise-Ebene (oft „Large Solution“ genannt):
Ziel: Diese Ebene befasst sich mit der gesamten Organisation und deren strategischen Zielen. Sie sichert die Ausrichtung aller Ebenen auf die Unternehmensstrategie.
Elemente:
Enterprise Architect: Stellt sicher, dass die technische Architektur und die Entwicklungsausrichtung mit den Unternehmenszielen übereinstimmen.
Enterprise Portfolio: Ein übergeordnetes Portfolio, das alle wichtigen strategischen Initiativen des Unternehmens umfasst.
Es wird hier klar, dass jede Priorisierung auf einer Ebene Kriterien der übergeordneten Ebenen berücksichtigten muss. Das ohne inhaltliche Festlegungen der Willkür eines Product Owners (noch dazu mit der Auflage, dass es nur eine Person und kein Team sein darf) zu überlassen, wird den Herausforderungen großer Organisationen offenbar nicht gerecht. Dass SAFe auch dazu führen kann, viel Overhead aufzubauen, ist auch korrekt. Wir sind wieder bei der bekannten Forderung, das Vorgehen der konkreten Situation anzupassen. Dazu in einem früheren Blogbeitrag mehr.
Zweite Komplikation: Wir arbeiten auch für die Tribüne
Ich habe die Emotionalität beim Umgang mit Warteschlangen zu Beginn am Beispiel von Alltagssituationen erwähnt. Aber auch in einem professionellen Umfeld geht es nicht nur um die pure Ratio. Als Projektmanager habe ich mit Stakeholdern zu tun und diese haben Erwartungen, die man nicht mit Verweis auf die Ergebnisse einer mathematisch untermauerten Priorisierung ignorieren kann.
Um das Vertrauen in die Projektarbeit aufrecht zu erhalten oder wieder zu reparieren, muss man manchmal „etwas herzeigen“. Nicht immer ist das aus Sicht der Gesamteffizienz das wichtigste und dringendste Ergebnis, es muss „nur“ nachvollziehbar und überzeugend sein. Dafür muss man Aufgaben priorisieren, die in einer streng rationalen Betrachtung noch nicht auf der Agenda stehen.
Dritte Komplikation: Die Erfolgskriterien sind weder konsistent noch stabil
Es gibt keinen Ansatz im Projektmanagement, der die Pririsierung so hoch gewichtet wie CCPM (Critical Chain Project Management, basierend auf der Theory of Constraints). Wir lernen daraus, dass es geradezu naturgesetzliche Regeln gibt, Aufgaben zu priorisieren, wenn man ein definiertes Ziel erreichen will. CCPM geht davon aus, dass es darum geht, den Durchsatz eines Systems zu erhöhen. Tatsächlich ist die Menge an erledigter Arbeit der wichtigste Hebel, um ein Projekt zum Erfolg zu führen.
Auch wenn dank der ausgefeilten Methodik von CCPM „Doing the things right“ optimal funktioniert, bleibt die Herausforderung von „Doing the right things“ auf strategischer Ebene bestehen. Ich gehöre selbst dem Netzwerk „Dolphin Universe“ an, weil ich dieses Know-How unglaublich wertvoll finde. Aber ich muss darauf hinweisen, dass im magischen Dreieck von Ergebnis, Termin und Aufwand die Gewichtung in jedem Projekt unterschiedlich ist und sich auch im Verlauf eines Projektes ändert. „Whatever it takes“ gilt manchmal auch in Projekten, in anderen ist wiederum das Budget ein limitierender Faktor. Und zudem sind die offiziellen Aussage nicht immer identisch mit den tatsächlichen Kriterien. Ein rational zweifellos allen Ansätzen überlegenes Verfahren wie CCPM kann in einer Welt voller Irrationalität keine umfassende Orientierung bieten.
Wie man die Prioritäten in einer konkreten Situation bestimmen soll, hängt also von Kriterien ab, die nicht immer klar und oft auch widersprüchlich sind.
Hier bietet wiederum SAFe einen interessanten Ansatz, weil die Funktion des Product Owners durch die des Product Managers ergänzt wird und zwischen einer strategischen und einer operativen Betrachtung unterschieden wird.
Product Manager:
Strategisches Niveau: Der Product Manager ist hauptsächlich für die strategische Ausrichtung des Produkts verantwortlich. Dies umfasst die Entwicklung der Produktvision, die Erstellung der Produkt-Roadmap und die Priorisierung von Features und Epics auf höherer Ebene.
Marktorientierung: Der Product Manager agiert auf einer übergeordneten Ebene und arbeitet eng mit Kunden, Marktanalysten und anderen Stakeholdern zusammen, um sicherzustellen, dass das Produkt die Marktanforderungen erfüllt und strategische Geschäftsziele unterstützt.
Program Backlog: Der Product Manager verwaltet das Program Backlog und priorisiert Features, die in den Agile Release Trains (ARTs) umgesetzt werden sollen.
Product Owner:
Operatives Niveau: Der Product Owner ist auf operativer Ebene tätig und verantwortlich für die Umsetzung der Vision und Strategie des Product Managers in konkrete Arbeitspakete (User Stories).
Teamorientierung: Der Product Owner arbeitet eng mit den Entwicklungsteams zusammen, um sicherzustellen, dass die Anforderungen klar definiert sind und die Teams die richtigen Aufgaben priorisieren und umsetzen.
Team Backlog: Der Product Owner verwaltet das Team Backlog und ist dafür verantwortlich, User Stories zu priorisieren und detaillierte Anforderungen zu spezifizieren, die während der Iterationen bearbeitet werden.
Man muss sich nicht den ganzen Overhead von SAFe einhandeln, um die Abwägung von strategischen und operativen Priorisierungen umzusetzen.
Vierte Komplikation: Wir wissen nicht alles und haben keine Zeit, unseren Informationsstand zu perfektionieren
Schon in Zusammenhang mit der Eisenhower-Matrix habe ich angemerkt, dass es in der Praxis nicht so einfach festzustellen ist, was wichtig und was dringend ist. Das gilt schon für die Selbstoptimierung, erst recht gilt es für komplexe Systeme wie z.B. Unternehmen, Programme und Projekte.
Erfreulicherweise ist das nicht unbedingt ein Nachteil. Bernd Gigerenzer und sein Forschungsteam haben zeigen können, dass relativ simple Heuristiken oft mehr Erfolg bringen als aufwändige Verfahren zur Entscheidungsfindung. Ich habe das in einem Blogbeitrag beschrieben.
Für alle, die lieber einem erfolgreichen Manager vertrauen als der Wissenschaft (hier sind wohl nur Leute, die beides tun), hier noch ein Beitrag von Gerhard Zeiler, dem international erfolgreichen Medienmanager.
Wir müssen einfach akzeptieren, dass jede Priorisierungsentscheidung die wir treffen besser ist als keine Entscheidung. Just do it! Das ruft mir das Logo meiner Laufschuhe zu und es ist ein guter Rat, nicht perfekt, aber hlfreich!