Entwickler in meinem Unternehmen protokollieren Stunden in JIRA. Manager/Scrum Master protokollieren Stunden nicht so religiös. Sie würden sich nur für Scrum-Zeremonien anmelden. Als Manager sehe ich den Grund dafür, dass ich meine Aufgaben nicht zum Sprint hinzufüge, da Treffen mit Stakeholdern, dem Team bei technischen Schwierigkeiten helfen, mit Kunden in Kontakt treten usw. keine guten Kandidaten für einen Entwickler-Sprint sind. Diese können weder geplant noch präpariert werden noch dergleichen. Und das Team muss die Details davon nicht kennen, da dies nicht die Art von Aufgaben ist, die jedes Mitglied ausführen können sollte. Nur ich werde diese Aufgaben erledigen, und obwohl ich mein Team um Feedback bitten kann, müssen wir diese Aufgaben nicht als solche pflegen.
Wir haben kürzlich mit der Personalabteilung darüber gesprochen, wie wir die Arbeit von Managern protokollieren können. Wir können natürlich JIRA-Aufgaben für unsere Arbeit erstellen, aber da sie dann nicht zum Sprint hinzugefügt werden, werden sie nicht für die Menge der für ein bestimmtes Projekt abgeschlossenen Arbeit gezählt.
Können Sie uns bitte einen Einblick geben, wie Sie dies in Ihrem Unternehmen handhaben? Erstellen wir projektübergreifend einen separaten Sprint für Manager? Oder erstellen wir in jedem Sprint eine Story für jede Aufgabenkategorie, die ich als Manager während des Sprints erledige? Wir haben 6-10 Manager mit unterschiedlichen Teamgrößen, die jedem von ihnen zugewiesen sind.
HR wird die Aufschlüsselung verwenden. Meistens wäre es eine Prüfung der aufgewendeten Zeit und einige Einblicke in Bereiche, in denen Menschen Zeit verbringen.
Dies ist ein bekanntes Antimuster. Wenn das Team erfolgreich ist, dann trägt der Scrum Master (als Teil des Teams) zu seinem Gesamterfolg bei. Wenn das Team scheitert, dann scheitert der Scrum Master (wiederum als Teil des Teams) mit ihm.
Das Team ist als Ganzes erfolgreich oder scheitert. Der Versuch, die individuelle Leistung für teambasierte Frameworks herauszukitzeln, ist ein Anti-Pattern. Der Weg, damit umzugehen, besteht darin, die Organisation darüber aufzuklären, wie sie die Leistung des gesamten Teams effektiv bewerten kann, und nicht Ticketing-Systeme wie JIRA zu kapern, um die Arbeitsstunden zu verfolgen.
Wenn Sie sich nicht ermächtigt fühlen, dieses Gespräch zu führen, ist das auch ein Problem. Sprechen Sie mit Ihrem direkten Vorgesetzten, agilen Coach oder anderen Projektsponsoren und stellen Sie sicher, dass sie die teamorientierte Kultur von Scrum voll unterstützen. Alles andere ist ein Verzicht auf Ihre Verantwortung als Scrum Master.
Wenn das Team seine Sprint-Ziele routinemäßig nicht erreicht, dann ist dies ein Problem, das das gesamte Scrum-Team während der Sprint-Retrospektiven angehen muss. Weder ein traditionelles Project Management Office (PMO) noch Human Resources (HR) – und um Himmels willen, warum ist Human Resources überhaupt in diesem Bild?! – sollten in die Bewertung von teaminternen Prozessen oder Auslastung einbezogen werden.
Während eine agile Community of Practice immer eine gute Quelle für Ratschläge und Informationen ist, sollte die Organisation eher auf Ergebnisse achten (z. B. „Erreicht das Team seine Sprint-Ziele öfter als nicht?“) als auf Nutzungsmetriken. Der Versuch, einzelne Stunden in ein Wertversprechen umzuwandeln, widerspricht den zentralen agilen Prinzipien.
Das Verfolgen von Arbeitsstunden innerhalb des Projekts ist an sich eine Nutzungsmetrik und in geringerem Maße eine Kostenverfolgungs- oder Kostenrechnungsmetrik. Wenn es auf Programmebene richtig gemacht wird, hat Scrum normalerweise eine durchschnittliche Run-Rate pro Sprint, die im Wesentlichen fest ist. Die Erfassung von Arbeitsstunden anstelle von Ergebnissen passt einfach nicht zu diesem Modell, es sei denn, die Organisation verstößt gegen die Kernprinzipien, indem sie Teams matriziert oder Personen (ein zweites Anti-Muster) mehreren Teams zuweist (ein drittes Anti-Muster). Tun Sie diese Dinge nicht.
Ermöglichen Sie keine organisatorische Dysfunktion und unterstützen Sie keine bekannten Anti-Patterns. Die Organisation darüber aufzuklären, wie das Framework angewendet werden soll und wie sie in ihrem Geschäftsansatz und ihren Interaktionen mit dem Team agiler sein kann, ist ein wesentlicher Bestandteil der Arbeit des Scrum Masters.
Wenn die Personalabteilung wissen möchte, wie viele Stunden die Mitarbeiter am Tag arbeiten oder wann sie frei nehmen, sind das vernünftige lohnbezogene Anfragen, die wenig mit Scrum als Projektmanagement-Framework zu tun haben. Granular Time Tracking ist jedoch ein Anti-Pattern, stellen Sie also sicher, dass Sie hier kein X/Y-Problem haben.
Sagen Sie „nein“ zu Auslastungsmetriken, aber verwenden Sie auf jeden Fall Techniken wie die 5 Warums , um das wahre Problem zu verstehen , das die Personalabteilung zu lösen versucht. Sie können ihnen vielleicht helfen, nach X anstatt nach Y zu suchen, ohne Ihre Scrum-Implementierung zu beschädigen.
Erik
Shaibee