Mit agilen Methoden weniger Ressourcenkonflikte?
Ressourcenmanagement wird in Ihrem Unternehmen zwar als sehr wichtig eingestuft, aber sowohl Sie als Projektleiter als auch Ihre Teammitglieder und selbst die Geschäftsführung sind unzufrieden mit der aktuellen Praxis? Damit sind Sie nicht allein. Bis vor fünf Jahren ging es uns bei TPG genauso. Lesen Sie folgende Erfahrungen, wie Ressourcenmanagement besser gelingen kann.
Mit agilen Methoden weniger Ressourcenkonflikte?
Ressourcenmanagement wird in Ihrem Unternehmen zwar als sehr wichtig eingestuft, aber sowohl Sie als Projektleiter als auch Ihre Teammitglieder und selbst die Geschäftsführung sind unzufrieden mit der aktuellen Praxis? Damit sind Sie nicht allein. Bis vor fünf Jahren ging es uns bei TPG genauso. Lesen Sie folgende Erfahrungen, wie Ressourcenmanagement besser gelingen kann.
Die Frage im Titel dieses Beitrags kann ich mit einem klaren "JA" beantworten. Agile Methoden verringern Ressourcenkonflikte – aber nur, wenn Sie die dafür nötigen Voraussetzungen etablieren! Seien Sie also auf einen echten Paradigmenwechsel gefasst.
Ressourcenmanagement hat drei Ebenen
Für ein agiles Ressourcenmanagement brauchen Sie dieselben drei Betrachtungsebenen wie im klassischen Bereich:
- kurzfristig operative (Tage / Wochen)
- mittelfristig taktische (Wochen / Monate) sowie
- langfristig strategische (Monate / Jahre).
Diese Anforderung gilt für Unternehmen aller Branchen und Größen. Nur die Umstände und die dazu passenden Lösungen sind nicht überall gleich. Die größten Gemeinsamkeiten gibt es bei der langfristigen Betrachtung. Dort wird die Unternehmensstrategie der Geschäftsleitung über Projekte vorausschauend geplant und umgesetzt. Hier beginnt auch – unabhängig ob agile oder klassische Methoden genutzt werden – das gemeinsame Dilemma, das Sie sicher auch kennen: Es wird immer versucht, mehr ins Portfolio hineinzupressen, als tatsächlich leistbar ist.
Bei Ihnen ist auch immer alles Prio A? Dann müssen Sie auf jeden Fall zunächst ganz oben ansetzen. Sie müssen eine realistische Reihung der Vorhaben in Ihrer Produkt- und Projektlandschaft schaffen. Nachdem es derzeit immer zu viel Arbeit für zu wenig Mitarbeitende gibt, werden Sie auf keiner Ebene des Ressourcenmanagements ohne Prioritäten auskommen.
Geht nicht, gibt´s nicht?
Dieses Credo der Experten ist für die inhaltliche Umsetzung natürlich immer zu begrüßen. Aber eben nicht im Sinne des Ressourcenmanagements: Wenn alle Mitarbeitenden bereits voll ausgelastet sind, dann muss man bei weiteren Forderungen vorher auch was weglassen. Das ist doch ganz einfach. In einen vollen Bus kann erst dann jemand einsteigen, wenn vorher jemand aussteigt. Ein Teammitglied fragt in so einem Fall immer "welchen Teil von NEIN verstehst Du nicht?".
Wenn das Verständnis für die beiden genannten Punkte bei den strategischen Entscheidern fehlt, können Sie im taktischen und operativen Bereich nicht mehr gewinnen. Sie können sich dann höchstens noch irgendwie "durchwurschteln". Spaß macht die Überlastung keinem und die Qualität leidet dabei ganz sicher.
Klassisches Ressourcen Ping-Pong
Im klassischen Projektmanagement führt das dann dazu, dass Teamleiter und Projektleiter in einer Matrixorganisation mit den Ressourcen Ping-Pong spielen. Man hängt immer hinterher und ist ständig damit beschäftigt umzuplanen. Mitarbeitende müssen Aufgaben aus verschiedenen parallellaufenden Projekten erledigen; deswegen müssen sie immer wieder umdenken, das Team wechseln, sich neu zurechtfinden.
Außerdem werden Budgets für Arbeitspakete von Sales oder dem Projektleiter vorgegeben, die den zugeteilten Personen oft nicht ausreichen, weil sie bisher vielleicht ähnliche, aber nicht genau diese Art von Aufgaben erledigt haben. Sie benötigen deshalb länger als geplant oder werden zwischendurch zu noch dringlicheren Aufgaben gerufen. Und so hören die Probleme im Ressourcenmanagement nie auf.
Mit agilen Methoden werden auf der kurz- und mittelfristigen Ebene viele dieser Probleme abgefedert oder sogar ganz vermieden. Das führt dann ganz automatisch zu besserem Ressourcenmanagement.
Aber Achtung: das gilt nur unter der Voraussetzung, dass Sie die folgenden Bedingungen erfüllen.Agile, feste Teams
Wie Sie wissen, werden bei klassischen Methoden zuerst Aufgaben zur Erreichung fester Ziele geplant. Und dazu wird dann versucht, die jeweils geeigneten Personen zu finden, die alle Aufgaben bis zum gesetzten Endtermin erledigen sollen. Es wird solange daran gearbeitet, bis das Ziel erreicht ist.
Im Gegensatz dazu werden bei agilen Methoden zuerst feste Teams gebildet. Das Team arbeitet das selbst geschätzte Backlog in festen Iterationen so ab, dass zwischendurch und am Ende der gegebenen Zeit Ergebnisse vorliegen. Die Ergebnisse müssen nutzbar sein, aber es bleibt bis zum Schluss möglicherweise offen, wie sie genau aussehen.
Festes Team bedeutet, dass es einmal zusammengestellt wird und während der Durchführung unverändert bleibt. Das ist für die auf Dauer angelegte Weiterentwicklung von Produkten recht einfach, für wechselnde Kundenprojekte schon schwieriger. Generell ist dies umso einfacher, je länger das Vorhaben dauern soll und umso wichtiger das Vorhaben ist. Aus Sicht des Ressourcenmanagements ist das auch schon die wesentliche Änderung.
Wenn Sie also drei Produkte haben, bilden Sie drei Teams in passender Größe und lassen diese machen. Sie müssen dann nur noch den strategischen Teil weiter betrachten, also welche und wie viele Produkte Sie künftig entwickeln wollen. Entsprechend sind Teams zu bilden, und fertig.
Wir haben bei TPG seit mehr als fünf Jahren feste Teams in der Produktentwicklung und müssen uns nur um die Neueinstellung von weiteren Mitarbeitern und um die Betreuung innerhalb der Teams kümmern. Ping-Pong spielen wir in der Freizeit, nicht mit unseren Produktentwicklern.
Agiler Ergebnispoker
Ressourcenkonflikte aus der klassischen Welt wandeln sich zu Ergebnisoffenheit in der agilen Welt. Klingt doch auch gleich viel freundlicher. Wird aber in der Praxis genauso hart diskutiert. Nur eben mit anderen Personen und mit vielen Vorteilen.
Die Diskussion bezüglich Ergebnisse erfolgt im Rahmen der Releaseplanung zwischen Produktmanagement, Entwicklungsteam, Consulting und Sales. Aber eben nicht bezüglich Personen im Rahmen der Ressourcenplanung zwischen Teamleitern und Projektleitern.
Im festen Zyklus von zwei Monaten planen wir die Features des jeweils nächsten Releases, die in vier zweiwöchigen Sprints umgesetzt werden sollen. Der Vorteil ist, dass das Team selbst geschätzt hat und sehr gut weiß, was es leisten kann. Außerdem sind alle Teammitglieder eingearbeitet und auf ein Produkt fokussiert, denn interne ungeplante Ablenkungen werden ferngehalten. Das macht mehr Spaß und führt automatisch zu mehr Durchsatz und Qualität.
Das ist für die intern gesteuerte Produktentwicklung natürlich einfacher als für extern beauftragte Kundenprojekte. Es denken aber immer mehr Kunden auch in diese Richtung, weil sie mittlerweile intern auch so arbeiten. In einem weiteren Beitrag werde ich dieses Thema noch näher beleuchten.
{node/1133928}Ressourcenmanagement ist am Ende eine Kulturfrage
Je nach Unternehmenskultur ist Ressourcenmanagement eine recht heikle Angelegenheit – oder auch nicht. Mit klassischen Methoden sind Sie mehr damit beschäftigt, die richtigen Personen für gegebene Projekte zu finden. Mit agilen Methoden sind Sie mehr damit beschäftigt, die besten Ergebnisse mit dem gegebenen Team zu finden.
Die Auswahl von Methoden, Prozessen und Tools spielt dabei natürlich auch eine wichtige Rolle. Die Zufriedenheit mit dem großen Thema Ressourcenmanagement können aber letztlich nur die beteiligten Personen mit entsprechendem Umgang untereinander selbst herstellen.
Was sind Ihre Erfahrungen zum Thema Ressourcenplanung im agilen Umfeld? Ich freue mich über Ihren Kommentar hier im Blog oder auch per Mail an johanns@theprojectgroup.com.
Dieter Bertsch
09.11.2018
 
Auf den „kurzfristigen operativen“ Kapazitätsbedarf sind Sie dann aber weder bei der klassischen Projekt-Sicht noch bei der agile Produktorientierung eingegangen.
 
Hier passieren m.E. bei der Einführung agiler Methoden (z.B. Scrum) ein erster großer Fehler: Pilotteams werden nur um die Neuentwicklung eines Produktes herum aufgesetzt. Die, die die Wartung und den Betrieb machen, lassen wir erst einmal heraus…
 
Diese leider viel zu oft beobachtete Herangehensweise führt aber gleich zu mehreren Problemen: 1. Klassenbildung – Wir sind die (guten) Produktentwickler, die im Rampenlicht stehen; ihr seid ja nur die, die gucken, das (zumeist alte) „Haus vor dem Zerfall bewahren“ (Ohne denen würde der ganze Laden aber nicht laufen…) 2. Die Neuentwickler machen; und andere machen die Fehler weg… Die Bindung zum täglichen Alltag geht verloren 3. … weitere Fehlentwicklungen
 
Mein Tipp: Zu den Produkt-Teams gehört Neuentwicklung, Fehlerbehebung und Wartung; wobei die beiden letzteren ggf. weniger gut zu planen sind. Ich verwende für die „un-planbaren Anforderungen“ immer gerne eine vorher mit dem PO vereinbarten Anteil an der Kapazität des Teams, dessen Verbrauch in einem eigenen Burndown Chart dargestellt wird. (In meinem leichtgewichtigen Sprint Burndown-Excel lasse ich die Kurve „geplante Aktivitäten“ von oben gegen die Kurve „ungeplante Aktivitäten“ zur Null-linie hinlaufen. So sind der zeitliche Werdegang und insbesondere Ausreißer sofort transparent.)
 
Und dann spielen wir auch kein Ping-pong zwischen Neuentwicklung (klassisch: Projekten) und Betrieb: Es liegt in der Hand des PO, sauber die Anforderungen zu priorisieren und damit die Kapazitätsverteilung zu steuern…
 
Diesen Aspekt wollte ich gerne noch nachtragen.
Johann Strasser
09.11.2018