Fragen

 
1
0
-1
Ich stosse immer wieder auf die Problematik, dass für die Einplanung von Scrum-Teams in den gängigen PM- und PPM-Tools nicht wirklich eine taugliche Lösung angeboten wird. Wie könnte man die Kapazität bzw. die Auslastung eines Scrum-Teams planen? Die meisten Tools arbeiten mit Stunden oder Personentagen, die Kapazität eines Scrum-Teams wird aber üblicherweise in Storypoints bewertet. Diese Kapazität schwankt von Sprint zu Sprint, je nach dem, ob das Team vollständig oder unvollständig ist. Noch schlimmer wird es, wenn einzelne Team-Mitglieder nur teilweise im Team eingeplant sind und daneben auch noch in anderen Rollen in den Projekten arbeiten. Was ist mit Abwesenheiten, wie können die bei der Team-Kapazität berücksichtigt werden etc. etc. Hat mit dieser Thematik jemand Erfahrungen gemacht?
    CommentKommentar hinzufügen...

    4 Antworten

    1.  
      1
      0
      -1

      Hallo Beat

      Ich kenne Deine Problematik sehr gut - ich sehe mich oft in einem Spagat zwischen einer klassischen Projekt-Governance und dem Einführen von agilen Methoden. 

      Zum Tool: Für mich stellt sich die Frage, ob du diese Tools mit Personentagen nutzen musst, oder du sie nutzen kannst. Im letzteren Fall könnte man mit einer Cloudversion von JIRA, Meistertask oder Trello (es gibt eine Menge anderer Tools) anfangen, die Stories zu planen und die Sprints durchzuführen (jeder sollte es nutzen). Durch die Erstellung der eigenen Aufgaben fällt es den Teammitgliedern nach und nach leichter, die Stories besser einzuschätzen. 

      Bei der Sprintplanung hilft es mir grundsätzlich, wenn ich weiss, wann welche Ressourcen aufgrund geplanter Urlaubstage, Zuweisung zum Projekt (3 Tage die Woche oder 20%) verfügbar sind und wenn ich ihre Skills kenne. Hierbei kann man bei den Planungsmeetings dann nochmals darauf eingehen (Bekommt ihr das wirklich hin, Person x ist ja kaum verfügbar, wer kann das übernehmen?). Insbesondere im Fall von nicht dedizierten Teams - was eigentlich Scrum und die Idee der Produktentwicklung in dieser Form in Frage stellt - ist eine Velocity sehr schwierig zu erstellen. Meine Workaround ist, dass ich vorab Schätzungsstories in einem früheren Sprint lege, wo sich das Team vorab mit dem Thema auseinandersetzen kann. Hierbei können frühzeitig Abhängigkeiten in die Organisation erkannt werden (Scrum Master und PO sind hier gefragt), oder auch Resourcenbedürfnisse. Eine Einplanung der Stories in die Implementierung fällt dadurch schon leichter.

      Falls du noch Fragen hast - wir sind ja beide aus der Schweiz - können wir gerne telefonieren oder uns auf einen Kaffee treffen.

      Viel Erfolg

      Godela

       

       

      1. Beat Flück

        Danke Godela. Dein Input hat mir wieder ein paar Ideen gegeben. Es macht wohl tatsächlich Sinn, jeden Mitarbeiter konventionell einzeln im Tool zu führen. So habe ich als ersten Schritt mal seine Netto-Verfügbarkeit (Brutto-Verfügbarkeit abzüglich Abwesenheiten, bereits geplante Einsätze in anderen Projekten, ggf. Grundlast, etc.). Diese Netto-Verfügbarkeit kann ich dann im zweiten Schritt den als Task geplanten Sprints zuordnen. Damit bekomme ich die maximale Kapazität in Personentagen oder Stunden pro Sprint. Was genau mit dieser Sprint-Kapa schlussendlich geleistet werden kann, ist dann wie Du es beschrieben hast eine Sache der jeweiligen Sprint- und Releaseplanung. Mit diesem Vorgehen lassen sich immerhin die voraussichtlichen Personalkosten je Sprint berechnen und somit auch die Kosten je Release oder Zeitraum/Timebox. Das hilft mir schon mal weiter. Merci nochmals und Grüsse, Beat

      CommentKommentar hinzufügen...
    2.  
      2
      1
      0

      Also wenn du nicht um das Werkzeug herum kommst, und damit die klassische Betrachtung im Vordergrund steht, würde ich das agile Vorgehen in Frage stellen. Die Quadratur des Kreises gelingt hier nicht. Du kannst dir zwar eine Verhältnis von gemessener bzw. angenommener Velocity zu den Arbeitstagen eines Sprints als Basis nehmen, aber das hat kaum Aussagekraft; schon gar nicht, wenn die Updates des Planungstools nicht im Sprint-Rhythmus stattfinden.

        CommentKommentar hinzufügen...
      1.  
        2
        1
        0

        Hallo Beat,

        damit die Betrachtung agiler Teams in dein bisheriges Schema passt, würde ich die Velocity messen, also die Summe an geschätzten Story Points all jener Stories, die der Definition of Done genügen in einem Sprint. Du wirst feststellen, dass in den ersten 3-4 Sprints noch wenig Aussagekraft in den gemessenen Werten vorliegt, die dann in den folgenden 3-5 Sprints einen stabilen Schwankungsbereich erreichen. Je besser das Team unterwegs ist, desto kleiner können die Abweichungen sein. In diesem Wert finden sich dann ganz automatisch Abwesenheiten aller Art (Urlaub, Krankheit, Teilzeit, etc.). Ob du hier dann mit Worst-Case, Standard, Best-Case arbeitest, oder einfach einen Mittelwert nimmst, ist nicht wirklich entscheidend, da im Agilen eher die Trends betrachtet werden.

        Die eigentliche Schwierigkeit für eine Transition von Klassik zu Agil ist das Loslassen von der Idee der berechneten Voraussagen. Im Komplexen funktioniert das nicht mehr. Jede Annahme über die Entwicklung der Leistungsfähigkeit eines Teams ist bezogen auf ihren Zeitpunkt reine Spekulation. Erst die Betrachtung echter Messungen über Zeiträume hinweg, also der empirische Ansatz, hilft für Aussagen der näheren Zukunft. Aber eben auch nicht mehr, da keiner wirklich weiß, was als nächstes alles an Veränderung um die Ecke kommt.

        Vielleicht noch ein Hinweis zur Auslastung: Scrum Teams müssen nicht ausgelastet werden. Die Idee, dafür zu sorgen, dass jeder genug zu tun hat, ist Mikromanagement. Das funktioniert in selbstorganisierten Kontexten überhaupt nicht. Das führt zu Stillstand und verhindert Innovation. Die Leute sind motiviert genug, sich ihre Arbeit selbst zu suchen, wenn sie in dieser einen Sinn erkennen. Das Hauptaugenmerk liegt dabei nicht auf der Planung, sondern auf der Gestaltung eines passenden Arbeitsumfeldes. Die Idee dahinter: wenn der intrinsisch motivierte Mitarbeiter alles hat, was er für die Erstellung eines guten Ergebnisses braucht, und das Umfeld sich ständig weiter entwickelt, ist die Wahrscheinlichkeit hoch das für die Situation optimale Ergebnis treffen zu können.

        Schwierig ist es natürlich beide Denkrichtungen zusammen zu bekommen, wenn ein Hybrid probiert wird, wie in deinem Fall.

          CommentKommentar hinzufügen...
        1.  
          1
          0
          -1

          Hallo Reiner

          Vielen Dank für Deine Inputs. Ich sehe viele Punkte zur agilen Arbeitsweise ähnlich wie Du. Allerdings hilft mir das im Moment kaum weiter. 

          • Velocity ist gut. Aber wie bringe ich das in ein klassisches PM-/PPM-Tool? Die Tools verstehen alle nur Stunden oder Tage (traurig)
          • Mikromanagment ist sicher nicht angebracht. Das Pull-Verfahren ist ok, so lange an den wichtigsten Themen gearbeitet wird. Aber ein Unternehmen braucht ja trotzdem irgendwie einen Plan, was wann mit welchem Aufwand bearbeitet werden soll. So ganz bottom-up lässt sich eine Firma nicht führen. Vielleicht möchte man die Team-Kapazität vergrössern oder verkleinern, mehr oder weniger Teams haben etc. Wie kann man das erkennen, wenn keine Voraussagen möglich sind?
          • Auch wenn die Mitarbeiter hochgradig intrinsisch motiviert sind gibt es Budgets, Termine, Abhängigkeiten etc. Wie soll man das auf Planungsebene im Griff behalten, wenn man bei den Ressourcen keinen Durchblick hat? Für ein einzelnes Projekt lässt sich mit dieser Ungewissheit leben. Bei vielen Projekten dürften die Risiken durch die fehlende Planungssicherheit rasch zu gross werden. 

          Ich bin gespannt, ob es weitere Erfahrungen und Hinweise gibt. 

            CommentKommentar hinzufügen...