Ein Sprint ist auf 10 Arbeitstage mit mehreren Storys angelegt. Man nimmt an, dass die Ressource – Hans Castorp – eine 40 Stunden-Woche hat und an nichts anderem arbeitet als an einer Story. Hier hat er sich 5 Story Points eingetragen und aufgrund der Metrik von einem Story Point gleich 8 Arbeitssunden kann in der Ressourcenplanung von 40 Stunden Arbeit innerhalb der 10 Arbeitstage des Sprints ausgegangen werden.
Person mit 40 Stunden in 2 Wochen geplant
In einer optimalen Scrum-Welt kann diese Person nun noch weitere Storys für diesen Sprint bekommen. Er hat ja noch 5 Personentage (=10 Tage lang 4 Stunden/pro Tag) zur Verfügung.
Solange das nicht überschritten wird, gibt es keine Probleme. Auch die Berechnung der Kapazität ist einfach, jedes Paket, sprich jede Story, ist ja gleich lang und beginnt auch am gleichen Tag.
Problematischer wird es, wenn eine andere Arbeit für diese Person geplant wird, die nicht diesen exakt gleichen Rahmenbedingungen entspricht. Zum Beispiel wird für Hans Castorp ein Workshop geplant, der an einem Tag stattfindet und auch einen Tag dauert.
Paralleles Arbeitspaket mit 100% an einem Tag, also 8 Stunden
In nahezu allen Ressourcenmanagementsystemen wird jetzt eine Überlastung angezeigt. Diese Systeme berechnen Überlastungen nach Zeitintervallen, beispielsweise täglich oder wöchentlich.
In dem Beispiel käme die Software zum Ergebnis, dass Herr Castorp am 29. Juli 12 Stunden arbeiten muss, also 8 Stunden für den Workshop und 4 Stunden an der Story. Damit wäre er natürlich überlastet. Würde die Software die zeitliche Perspektive vergrößern, also mit einer Granularität von einer Woche arbeiten, gäbe es keine Überlastung.
Sind dann aber parallele Arbeitspakete noch länger, müsste die nächste Granularitätsstufe genommen werden, also Monate, dann Quartale, Jahre und am Ende Lebensarbeitszeit.
Dieser Berechnungsansatz ist für Menschen grundsätzlich falsch. Denn Herr Castorp ist zu keiner Zeit überlastet. Er wird die Arbeit in der Story einfach selbstständig umorganisieren.
An dem besagten Mittwoch wird er nicht daran arbeiten, weil er mit dem Workshop beschäftigt ist. Diese „fehlenden“ vier Arbeitsstunden macht er in irgendeiner Einteilung vor oder nach dem Workshop. Herr Castorp führt also seine detaillierte Arbeitseinteilung selbst agil je nach Situation durch. Vielleicht hat er am Montag auch einfach keine Lust, an der Story zu arbeiten. Er wird dann diese verlorene Menge später versuchen aufzuholen.
Warum aber rechnen die Systeme unrealistisch, also falsch?
Hier gibt es zwei Gründe.
Erstens basieren viele der Berechnungsmodelle auf der Kapazitätsplanung von Maschinen.
Maschinen organisieren sich aber nicht selbst. Bei einer Fertigungsmaschine wäre eine Überlastung wie oben gezeigt richtig. Ein Mensch würde dann eingreifen und den Einsatz der Maschine anpassen. Das macht Herr Castorp selbst ja auch.
Der zweite Grund liegt in der Tabellen- (oder besser noch Excel-)Fixiertheit einiger Planer.
Hier geht es darum, immer schön pro Spalte (Zeiteinheit) auf 8 Stunden pro Tag oder 40 Stunden pro Woche zu kommen. Wenn es so passt, scheint dies alles im Reinen und im Projekt kann angeblich nichts schief gehen.
In anderen Worten: Kann Herr Castorp seine Arbeiten so organisieren, dass er, ohne überlastet zu werden, den Workshop an diesem einen Tag macht und die Arbeiten für die Story bis zum Sprintende auch schafft? Ja, das kann er schaffen, also gibt es keine Überlastung.
Anders sieht es aus, wenn der Workshop wesentlich länger dauert, beispielsweise acht Tage.
Der Workshop dauert wesentlich länger, jetzt ist die Person überlastet
Hans Castorp hat nun keine Chance, die Arbeitsmenge so neu zu organisieren, dass er beides schafft, die Warnlampen links in roter Farbe zeigen das auch an.
Dieses Beispiel ist bewusst einfach gehalten. Bei der Kleinteiligkeit der Arbeit in modernen Firmen wird das aber sehr schnell zu kompliziert für einen Menschen.
Außerdem darf man nie vernachlässigen, dass Menschen ihre Arbeiten in einer Priorität bearbeiten, die für sie selbst richtig und angenehm ist.
Wie oben gesehen arbeitet Can Do mit einem anderen Algorithmus. Das Verfahren wird unter dem Namen „Watermodel“ zusammengefasst und simuliert jede denkbare Kombination, wie ein Mitarbeiter sich sinnvollerweise organisieren kann.
Sinnvoll heißt hier, das nicht exakt simuliert wird, dass die Person 7 Minuten an etwas arbeitet oder 6,23 Stunden, sondern in realistischen Modellen. Hier können Millionen von Kombinationen entstehen, das ist aber egal. Wichtig ist nur, dass es erfolgreiche Möglichkeiten gibt, dann schaltet sich auch keine Warnlampe ein.
Wird in Can Do ungenau geplant, vervielfachen sich die Möglichkeiten, da ja unterschiedliche Situationen mit unterschiedlichen Wahrscheinlichkeiten eintreten können. Daran, dass die Prozessoren von Can Do-Servern mit 2.000 Anwendern glühen, sieht man, welche unfassbare Komplexität in der Planung von Menschen steckt. Dies manuell mit Excel zu machen, kann bestenfalls ein schlechter
Näherungswert sein.
Die Voraussetzung für hybride Planung mit Ressourcen ist also, dass die
Ressourcenplanung ebenfalls agil durchgeführt wird. Dies ist ein oft übersehenes Problem in den Betrieben, wenn versucht wird, Scrum mit klassischer Netzplanung zu verbinden.
