Warum ist das Management mehr besorgt über die JIRA-Stunden als über die Einhaltung der Scrum-Werte?

Wie in vielen anderen Projekten nutzen wir auch JIRA zur Verwaltung von Aufgaben und User Stories sowie Scrum als agile Methodik. Am Ende jedes Tages stellt der ScrumMaster dem PMO-Team das Burndown-Diagramm zur Verfügung.

Die ersten Fragen, die bei jedem wöchentlichen Treffen mit dem PMO-Team gestellt werden, sind jedoch:-

  • Warum verbrennt das Team in JIRA nicht richtig Stunden - 5 Stunden pro Tag?
  • Wenn jedes Teammitglied Stunden verbrennt (~ 5-6 Stunden pro Tag) und diese ordnungsgemäß in JIRA protokolliert, warum kommt dann die rote Linie (der verbleibenden Werte) im Burndown-Diagramm nicht so nahe an die Richtlinie heran ?
  • Wer im Team erfasst keine Stunden?
  • Warum muss das Team jeden Tag daran erinnert werden, Stunden in JIRA zu erfassen?

Ehrlich gesagt, das ganze Team hat all diese dummen Fragen ziemlich satt, und wir alle fragen uns, ob wir tatsächlich den Scrum-Werten folgen oder stattdessen nur JIRA beibehalten, um dem PMO zu zeigen, dass wir alle Scrum folgen und eine fast-zu- Perfektes Burndown-Diagramm.

Für mich habe ich mich immer über drei Punkte gewundert: -

  • Warum kümmert sich das Management mehr um das JIRA-Burndown-Diagramm als um die Einhaltung der Scrum-Werte in der Projektentwicklung?
  • Warum mögen einige Teammitglieder nicht jeden Tag fleißig Stunden in JIRA eintragen?
  • Gibt es irgendetwas, was das Team tun kann, um diese Stundenerfassung (von jedem Teammitglied) einfacher zu gestalten, damit uns das Management nicht mit solch schlechten Fragen stört?

Kann jemand von Ihnen bitte meine oben genannten drei Zweifel klären, damit wir alle ein besseres Scrum-Team werden können?
Ich danke Ihnen allen im Voraus, und ich schätze Ihre Zeit und Vorschläge, um mir zu helfen!

Ich bin mir nicht sicher, ob wir beantworten können, warum Ihr Management eher an A als an B interessiert ist - es scheint mir produktiver zu sein, sie zu fragen, als uns.
Ich glaube, hier gibt es eine gute Frage zur Interaktion mit Managern, die Metriken für das Projektmanagement verwenden. Bitte erstellen Sie es in dieser Richtung neu.

Antworten (3)

Ich kann die Frustration in Ihrem Beitrag spüren. Als jemand, der den Übergang von einem PMO zu einer agilen Rolle vollzogen hat, kann ich beide Seiten der Medaille verstehen.

Ihre Frage hat mehrere Komponenten, die ich der Reihe nach aufgreifen werde, aber alle haben im Kern eine effektive Kommunikation .

Warum ist das Management mehr daran interessiert, Stunden zu protokollieren?

Dies kann eine Reihe von Dingen sein, aber das Management muss die geleisteten Arbeitsstunden unbedingt nachverfolgen. Dies kann einer oder eine Kombination der folgenden Gründe sein.

  • Das Unternehmen muss Rechenschaft über den investierten Shareholder Value ablegen. Die effektive Lieferung ist nur eine Möglichkeit, den Wert zu verfolgen. Es muss auch sichergestellt werden, dass die Lieferung ungefähr der Menge der prognostizierten Arbeitsstunden entspricht.
  • Einhaltung externer Audits und Governance. Wenn es sich bei Ihrem Unternehmen um eine SPS handelt, erhöht sich der Prüfungs- und Regulierungsaufwand, und die erfassten Stunden sind eine entscheidende Komponente dieses Prozesses. Erinnern; wenn jemand sein monatliches Gehalt erhält, das die Investition eines Anteilseigners ist, der übertragen wird, und dieser Anteilseigner eine Mindestrendite für die Zahlung dieses Gehalts erwartet. Es ist nicht unvernünftig, die geleisteten Stunden einfach zu protokollieren, oder?
  • Zeiterfassung . Wenn Sie mit einem PMO verbunden sind, hat das Entwicklungsteam wahrscheinlich mehrere Projekt- oder Programm-Workstreams, die eingehen. Die Abteilung ist keine kostenlose Ressource, Ihre Entwickler müssen für die Arbeit, die sie leisten, einer Kostenstelle zugeordnet werden, damit Projekte durchgeführt werden können nachverfolgt, um sicherzustellen, dass sie innerhalb des Budgets liegen.
  • Ressourcenbedarf . Unterschätzen Sie nicht, dass die Hauptentscheidung des Managements zur Auf- und Abwärtsskalierung von Ressourcen darin besteht, den geplanten Aufwand in Manntagen / Mannstunden einem festen Dead-Drop-Zeitplan gegenüberzustellen. Wenn die Ressourcenanforderungen die Frist überschreiten, werden Ressourcen hinzugezogen. Das Protokollieren von Stunden ist ein entscheidender Teil der Sicherstellung, dass die Planung effektiv und genau ist. Sie erhalten bei Bedarf zusätzliche Entwickler und Tester, aber die Protokollierung von Stunden ist für die Erstellung dieses Business Case von entscheidender Bedeutung.
  • Vertrauen. Im Moment scheint das Management einige Vertrauensprobleme in Bezug auf die Abteilung zu haben. Es ist möglich, dass Sie ein junges Scrum-Team sind, der Prozess neu für sie ist, nicht richtig verkauft wurde oder sie die Vollzeitressourcen der Abteilung kontrollieren müssen. All diese Symptome sind ein Mangel an Vertrauen.

Die harte Wahrheit ist, dass ich niemals zulassen würde, dass ein Mitarbeiter auf die Erfassung seiner Stunden verzichtet, wenn er es nicht einmal schafft, seine Stunden zu erfassen. Ist das sinnvoll?

Beim Militär hatten wir früher ein Sprichwort -

"Wenn Sie sich selbst verwalten können, geben wir Ihnen ein Gewehr. Wenn Sie Ihr Gewehr verwalten können, geben wir Ihnen ein Fahrzeug. Wenn Sie ein Fahrzeug verwalten können, geben wir Ihnen Untergebene ..."

Wenn Ihr Team nicht einmal Stunden nachverfolgen kann , warum um alles in der Welt sollte es von der Aufgabe befreit werden? Es ist ein einfaches Element, das weniger als 5 Minuten dauert. Ich bin überrascht, dass das Management nicht bereits strengere Maßnahmen ergriffen hat. Wenn Ihr Team Unabhängigkeit will, muss es sich diese verdienen.

Warum protokolliert mein Team keine Stunden?

Dies ist teilweise ein psychologisches Problem, weist aber auch darauf hin, dass ihnen der Wert der Stundenerfassung nicht erklärt wurde. Wenn ihnen der Wert erklärt wurde und sie weiterhin einen Prozess ablehnen, den das Management für wertvoll hält, dann haben Sie ein dysfunktionales Team , das sich möglicherweise auf ein oder zwei starke Charaktere konzentriert, die den Rest der Gruppe antreiben.

In diesem Fall müssen Sie Maßnahmen ergreifen, um Disziplin im Team zu verbreiten. Ein Scrum Master ist der Diener des Teams. Die meisten Menschen konzentrieren sich auf den Teil der Diener, um Demut zu zeigen, aber vergessen nicht die Rolle des Herrn. Zwingen Sie dem Team Ihren Willen auf, um sicherzustellen, dass es genau versteht, was toleriert wird und was nicht.

Teilen Sie das dem Team mit

  • Stunden müssen am Ende eines jeden Tages protokolliert werden
  • Sie konsolidieren täglich alle Protokolle und melden die fehlenden
  • Bei wiederholten Straftätern wird dies bei ihrer jährlichen Beurteilung gemeldet
  • Konsequente Übertreter lassen das Team im Stich, denn je früher sie sich daran halten, desto eher kann das Management dem Team vertrauen und den Prozess entfernen

Es ist immer einfach, dem Managementprozess die Schuld zu geben, anstatt eine Ursachenanalyse durchzuführen. Meiner Erfahrung nach haben die meisten Manager fundierte Argumente für die von ihnen angeforderten Berichte und Prozesse. Wenn Sie in Zukunft Planungsschätzungen vergrößern oder in Frage stellen müssen und keine Protokolle haben, die Ihren Geschäftsfall unterstützen, dann erwarten Sie, dass die Ressourcen an einen Abteilungsleiter gehen, der die Protokollierung durchsetzen kann.

Viel Glück, selbst wenn Sie dieses Problem in PM.SE aufwerfen, zeigt dies, dass Sie einige hervorragende Eigenschaften haben, um das Problem zu beheben.

2019-Aktualisierung

Diese Antwort stellt eine Momentaufnahme dessen dar, wo ich gearbeitet habe und wie ich Agility angegangen bin. Ich sollte sagen, dass ich heutzutage die Arbeitszeiterfassung absolut nicht unterstütze, und die Arbeitszeiterfassung selbst ist symptomatisch für einen Projektgeruch, der eine Ursachenanalyse erfordert. Es weist auf mangelndes Vertrauen in ein Team oder auf mehrere Lieferungen verteilte Ressourcen hin. Kurz gesagt, es ist ein schrecklicher Weg, um die Softwareentwicklung zu erleichtern.

Darüber hinaus ist funktionierende Software die wichtigste Methode, um den Wert zu demonstrieren . Alle anderen Artefakte sind Rauch und Spiegel.

Ich stehe zu meiner Antwort, da sie den Weg zeigt, den wir alle zu den agilen Werten gehen, aber ich unterstütze sie nicht mehr als Ratschlag für die Entwicklungs- oder Projektmanagement-Community.

Ich weiß Ihre Zeit für die Beantwortung meiner Fragen wirklich zu schätzen, und jeder Ihrer Punkte ist bis ins Mark wahr – ich stimme dem voll und ganz zu.
Ich habe aber noch eine Frage. Ich überprüfe manchmal das Burndown-Diagramm von JIRA (v 6.4) und berichte, wie viele Stunden für den Tag protokolliert wurden. Aber ich finde keine Möglichkeit, eine Liste der Mitglieder zu haben, die für keinen Tag Stunden protokolliert haben. Können Sie mir bitte mit einem geeigneten JQL (JIRA Query Language) oder auf andere Weise helfen? Danke nochmal!
Leider verwende ich JIRA nicht, obwohl andere Abteilungen in meiner Organisation dies tun. Ich könnte ihnen die Frage stellen, ob Sie bereit sind, 24 Stunden zu warten? Ich vermute, dass CodeGnome oder Niels ein besseres Verständnis für JIRA haben werden, und ich würde empfehlen, sich an sie zu wenden.
Venture2099 - Überhaupt keine Probleme, ich habe gestern die Lösung erhalten:- 1. Navigieren Sie zum gewünschten Projekt. 2. Wählen Sie Zusammenfassung (Registerkarte) > Abschnitt Berichte > Zeiterfassungsbericht. Danke schön!
Ich mag die Betonung darauf, dass dem Team der Wert nicht erklärt wird. Oft finde ich, dass der Stress rund um die Stunden der Berichterstattung im Kern ein Kommunikationsproblem ist.
Sofern die Stunden nicht abrechenbar sind, ist deren Meldung im Allgemeinen Zeitverschwendung. Bei der Anforderung, dies zu tun, geht es oft um den relativen Status, nicht um den Wert. In Organisationen, in denen jeder Stunden meldet, ist dies wahrscheinlich nicht der Fall. Aber diese Organisationen sind rar gesät. Für Organisationen, die Berichtszeiten benötigen, diese Berichte aber nicht veröffentlichen, ist der Wert für die Berichterstatter mit ziemlicher Sicherheit negativ.
@AndrewProck - offensichtlich hast du meine Antwort nicht gelesen. Wir werden zustimmen müssen, dass wir anderer Meinung sind. Bei der Anforderung, Stunden in Rechnung zu stellen/nachzuverfolgen, geht es fast IMMER um den Nachverfolgungswert.
Ich habe deine Antwort gelesen. Ich bin mir nicht sicher, warum Sie davon ausgehen würden, dass ich es nicht getan habe. Das ist eigentlich ein bisschen unhöflich.
@AndrewProck Es ist überhaupt nicht unhöflich anzunehmen, dass Sie meine Antwort nicht gelesen haben. Ich bin aus ganz konkreten und triftigen Gründen zur Nachverfolgung von Stunden gekommen. Der Beitrag wird am meisten positiv bewertet und wurde als „die Antwort“ markiert. Ihre Antwort war jedoch ein paar Wegwerfzeilen, die im Wesentlichen besagten: "Diese Antwort ist falsch, Meldestunden sind ein negativer Wert." Also ja ... Ich nehme an, Sie haben nicht wirklich gelesen, was ich geschrieben hatte.
Während es hier gültige Argumente für die Zeiterfassung gibt (auch wenn ich vielen von ihnen widersprechen würde), geht es nicht auf das Problem von JIRA ein. Und das ist eigentlich ein riesiger Schraubenschlüssel. Viele Führungskräfte möchten JIRA als Zeiterfassungstool verwenden – was es einfach nicht ist. Und in vielerlei Hinsicht bringt es den agilen Prozess durcheinander, bei dem JIRA eigentlich helfen soll.
Was meine Meinung zur Zeiterfassung betrifft: youtube.com/watch?v=_ogxZxu6cjM
Ähnlich wie Andrew müsste ich diesem Top-Down-Ansatz widersprechen. Insbesondere "Es ist immer einfach, dem Managementprozess die Schuld zu geben, anstatt eine Ursachenanalyse durchzuführen. Meiner Erfahrung nach haben die meisten Manager eine solide Begründung für die von ihnen angeforderten Berichte und Prozesse." Meiner Erfahrung nach führt die Ursachenanalyse dieses Szenarios fast immer zu Managern mit schlechten Begründungen wie „Mein Chef will es“ oder „Ich traue den Entwicklern eigentlich nicht“. Wenn Sie aktuelle Beweise für die negativen Auswirkungen dieses "weil ich es gesagt habe"-Führungsstils wollen, googeln Sie es, da draußen gibt es eine Menge - Drive usw. :)
Wenn ich dies weiter lese, stimme ich tatsächlich fast allem zu, was Venture empfiehlt, im Grunde Top-Down-Mikromanagement und das Gegenteil moderner agiler Werte. Der Scrum Master ist kein Meister des Teams im wahrsten Sinne des Wortes, er ist zu 100 % ein dienender Leiter und wenn überhaupt, ein Herausforderer des Status quo (was in diesem Fall eine herausfordernde Stundenerfassung bedeutet). Ich würde sogar argumentieren, dass die meisten modernen agilen Unternehmen jeden außerhalb der Lieferteams – einschließlich des Managements – als Diener des Teams betrachten. Im Ernst Venture, ich empfehle wirklich die Lektüre von Drive, Joy Inc., Leaders Eat Last, etc
Du hast einen fundamentalen Fehler gemacht @JeffLindsey. Sie sind davon ausgegangen, dass ich persönlich die Arbeitszeiterfassung unterstütze. Ich tu nicht. Ich habe mich dagegen gewehrt und diesen kleinen Sieg für mein Team errungen. Allerdings glauben zu viele Menschen in der Agile-Community, dass alle Schlachten gegen die Geschäftsleitung gewonnen werden können, was einfach nicht stimmt. Manchmal gewinnen „sie“ und agile Prinzipien treten in den Hintergrund. Das ist Realität. Also begann meine Antwort von dort. Sie können mir widersprechen, aber Sie können nicht die Welt und jede Corporate-Governance-Struktur ändern. Mein Führungsstammbaum ist ziemlich gut informiert und ich lese viel.
Wenn Sie zu einem behördlichen Audit für eine SPS kommen und sie nach Stundenzetteln fragen, sollten Sie sie besser haben. Die agilen Prinzipien werden Sie nicht daran hindern, an diesem Tag arbeitslos zu sein und einen neuen „Agile PM“ einzuberufen, der in der Lage ist, die Anforderungen einer schnellen Lieferung mit den normalen Arbeitspraktiken eines Program Management Office zu verbinden. Wir können den ganzen Tag damit verbringen, über die erstrebenswerten Arbeitspraktiken zu plaudern, die wir uns wünschen, aber versuchen Sie nicht, dies als die Realität der Welt darzustellen, weil dies einfach nicht der Fall ist. Außerdem ist der ScrumMaster absolut der Master-Servant des Teams.
Zeigen Sie mir in den agilen Werten, wo es heißt, dass jeder einzelne Mitarbeiter hochgradig selbstmotiviert ist und immer Wert liefert und nach beruflicher Entwicklung strebt ... zeigen Sie mir, wo es heißt, dass einzelne Ressourcen, die auf mehrere Projekte verteilt sind, nicht die Stunden erfassen sollten, die sie damit verbringen, diese unterschiedlichen zu unterstützen Projekte ... zeigen Sie mir, wo es heißt, Agile sei mit einem regulatorischen Umfeld unvereinbar. Das tut es nicht. Es ist eine Reihe von Werten, die in jeder Umgebung einzigartig interpretiert werden müssen.
Ich habe meine Karriere von einem PM zu einem Entwickler geändert, jetzt weiß ich, wie scheiße diese Idee der Protokollierung von Stunden ist. Wenn ich meine Stunden, die ich jeden Tag für jede Aufgabe aufwende, protokollieren muss, ist das gültig und machbar. Jira zwingt die Leute jedoch, die Startzeit zu protokollieren, was ein Problem sein wird ... Es ist sehr schwierig, die genaue Zeit am Ende des Tages herauszufinden, und wenn Sie es wagen, die Zeit nach jeder Arbeit zu protokollieren, wird es schwierig sein, damit umzugehen Multitasking und verzögern den Vorgang.
Vielen Dank für das Update @Venture2099

Warum ist das Management mehr besorgt über das JIRA-Burndown-Diagramm als über die Einhaltung der Scrum-Werte in der Projektentwicklung?

3 häufige Gründe für diese Art von Verhalten sind:

  1. Mangel an Vertrauen
  2. Schlechtes Verständnis agiler Methoden; immer noch in Wasserfallbegriffen denken
  3. Lieferteam erfüllt Verpflichtungen nicht

Warum mögen es einige Teammitglieder nicht, jeden Tag fleißig Stunden in JIRA zu protokollieren?

Es wird entweder als Zeitverschwendung empfunden, oder das Teammitglied versteht den Wert der Durchführung der Aktivität nicht, oder es hat keine Bestätigung erhalten, diese Übung fortzusetzen.

Gibt es irgendetwas, was das Team tun kann, um diese Stundenerfassung (von jedem Teammitglied) zu vereinfachen, damit uns das Management nicht mit solch schlechten Fragen stört?

  • Vertrauen aufbauen
  • Verpflichtungen einhalten
  • Bilden Sie das PMO in agilen Methoden aus
  • Zeigen Sie ihnen eine alternative Möglichkeit, den Arbeitsfortschritt zu verfolgen
  • Feuern Sie das aktuelle PMO ab und stellen Sie eines ein, das Agilität versteht ;)

Um das Protokollieren von Stunden in Jira zu vereinfachen, können Sie das Worklog-Assistentenprogramm verwenden. Der Worklog-Assistent holt sich alle Filter aus Jira, man bekommt zum Beispiel eine Liste der aktuellen Sprint-Issues. Es warnt Sie, wenn keine Zeit erfasst wird. Es ist möglich, automatisch oder manuell zu veröffentlichen und bei Bedarf einige Protokollierungen zu korrigieren. Erstellen Sie einige Platzhalter-Tickets für Ausfallzeiten wie Sprint-Meetings und/oder andere Nicht-Sprint-Overheads.

Nicht sicher, ob Sie das tun, aber schätzen Sie die Aufgaben nicht in Stunden, sondern wechseln Sie zu Story Points (dies wird von Jira unterstützt). Für das Management ist es schwieriger, geleistete Arbeit in Stunden umzurechnen und zu vergleichen. Die Arbeit ist erledigt, wenn sie erledigt ist, nicht, wenn das Team sie eingeschätzt hat. Einige Aufgaben dauern länger, andere kürzer. Das Burn-down gibt Aufschluss darüber, ob Sie Ihre Prognose abschließen und entsprechend anpassen, wenn der Plan nicht aufgeht.

Ich denke, das Management macht sich Sorgen um die Stunden, weil sie Entwickler pro Stunde bezahlen. Jede Stunde ist zusätzliches Geld. Erklären Sie, wie Scrum den Entwicklern mehr Fokus gibt und dass es schwieriger ist, von unwichtigen Dingen abzulenken.

Ich war einmal bei einer Scrum-Einführung von Jeff Sutherland und er sagte, dass das erste, was er in einem Unternehmen ändert, darin besteht, die Zeiterfassung zu entfernen. Lesen Sie auch seinen Blog-Beitrag Time Tracking is Anti-Scrum: What do you do you do if you need it for billing?

In einer Scrum-Schulung gestern in Kopenhagen mit erfahrenen Projektleitern, die auf CMMI Level 5 bei IBM und anderswo tätig sind, wurde allgemein vereinbart, dass das Auffordern von Entwicklern, Stundenzettel auszufüllen, die Teamproduktivität um mindestens 10 % verringert. Sie hassen es, es ist Doppelarbeit, es ist offensichtlich „Verschwendung“, und wird nur von Unternehmen gemacht, die keine Ahnung von schlanker Produktentwicklung haben

Niels - Ich denke, das wird zwei Dinge tun. Das Management wird eine Umrechnungstabelle von Punkten in Stunden verlangen (und wäre damit richtig, obwohl Punkte relativ sind). Die zweite ist, dass ein flüchtiger Blick auf die Stunden-gegen-Punkte-Debatte den Blog von Mike Cohn enthüllen wird, in dem er erfolgreich argumentiert, dass alle Sprintaufgaben in Stunden geschätzt werden sollten. Der Versuch, das Management mit agiler Esoterik zu umgehen, wird das Problem in meinen Augen noch verschlimmern.
Das Hauptproblem, das ich mit Stunden habe, ist, dass Entwickler sich unter Druck gesetzt fühlen, die anstehende Aufgabe in diesem Zeitfenster zu erledigen. Führt zu Abkürzungen und Stress. Sie sollten sich auf Qualität konzentrieren und es wirklich erledigen, anstatt zu denken, dass die Zeit für diese Aufgabe abgelaufen ist. Persönlich messe ich gerne in Manntagen, wie viele Manntage es braucht, um diese Aufgabe zu erledigen, ist einfacher zu beantworten und weniger genau. Haben Sie einen Link zum Blog von Mike Cohn, googeln führt zu mehreren Ergebnissen. Ich würde gerne mehr lesen und darüber nachdenken. Da es immer der gleiche Kampf mit dem Management ist ... :)
Hallo Niels – dies ist der relevante Blog-Beitrag und Mike ermutigt zur direkten Herausforderung über die Kommentare, also bin ich sicher, dass er Ihre Gedanken zu schätzen wissen würde. mountaingoatsoftware.com/blog/…
@NielsvanReijmersdal, ich denke, das Problem, dass sich Entwickler unter Druck gesetzt fühlen, innerhalb des Zeitfensters fertig zu werden, hat mehr damit zu tun, wie Schätzungen präsentiert werden, als mit den Einheiten der Schätzung. Mein Team schätzt in "idealen Personentagen" und ich betone, dass es a) meine Aufgabe ist, dies für das Management in Kalendertage umzurechnen, und b) es wichtig ist, im Laufe der Zeit besser beim Schätzen zu werden, anstatt innerhalb von zu enden schätzen.
Dies ist ein nettes Gegengewicht zu der akzeptierten Antwort, die immer wieder sagt, mgmt wolle "Wert" sehen. Der Wert ist die funktionierende Software. Es nützt nichts, 80 Stunden zu arbeiten, wenn nichts gut genug funktioniert, um in die Produktion zu gehen. ++
Warum ist das Management mehr besorgt über die JIRA-Stunden als über die Einhaltung der Scrum-Werte?
AntwortenHierDatenschutz-Bestimmungen1y, 0v