Wo endet die Autorität des Scrum-Teams und wo beginnt die des Entwicklungsleiters?

In einem Scrum-Team hat das Team entschieden, dass es seine morgendlichen Standups um 10 Uhr abhalten möchte. Das Team befindet sich in London und behauptete, dass 9:30 geringfügig früh sei, in dem Sinne, dass die öffentlichen Verkehrsmittel manchmal nicht richtig funktionieren, viel Verkehr usw.

Der Scrum Master hat die Nachricht übermittelt, dass das Team beschlossen hat, ihre morgendlichen Standups um 10 Uhr abzuhalten. Die Antwort des Managers war: "Nein ... warum? Damit alle um 10 Uhr reinkommen können? Nein, ich möchte, dass die Stand Ups um 9:30 Uhr stattfinden."

Wer sollte am Ende des Tages anrufen, wann finden Standups statt und ähnliches?

Antworten (4)

Dinge, die mit diesem Bild nicht stimmen:

  • Scrum hat keinen „Entwicklungsmanager“. Das klingt nach einem Unternehmen, das die Vergangenheit nicht loslassen will. Zugegebenermaßen kann dies ein schwieriger und langwieriger Prozess sein. Diese Rolle könnte also ein Zugeständnis sein, das notwendig war, um Scrum überhaupt erst in Gang zu bringen. Aber die Rolle sollte nicht benötigt werden. (Vielleicht ist das der Grund für diesen Konflikt - das Gefühl der bevorstehenden Veralterung)
  • Niemand außer dem Team muss am Stand sein. Optionale Teilnehmer sind möglich, aber ihre zeitlichen Präferenzen sollten die des Teams nicht überwiegen
  • Das Scrum-Team soll sich selbst organisieren. Dies ist eines der Dinge, die in diese Kategorie fallen.
  • Das agile Manifest stellt „Individuen und Interaktionen über Prozesse und Tools“. Konsens sollte dem Anspruch auf Autorität vorgezogen werden.
  • Die Antwort des Managers deutet darauf hin, dass er davon ausgeht, dass sein Standpunkt wichtiger ist als der des Teams. Diese Einstellung ist schädlich für den Aufbau eines zusammenhängenden und gesunden Teams.

Aus ideologischer und praktischer Sicht ist dies also die Entscheidung des Teams. Realistisch gesehen geht es nicht darum, wo die Autorität sein sollte, sondern darum, wo die Autorität tatsächlich ist. Wenn der Manager die Macht hat, das Team dafür zu tadeln, dass es um 9:30 Uhr nicht zum Meeting erschienen ist, dann findet das Meeting zu dieser Zeit statt. In diesem Fall ist das Beste, was Sie tun können, herauszufinden, warum 10 ein Problem für ihn ist, und einen Weg auszuhandeln, um seine Bedürfnisse auf eine Weise zu befriedigen, die für das Team bequemer ist.

Scrum doesn't have a "development manager". This sounds like a company who's unwilling to let go of the past.Nicht unbedingt. Die meisten Organisationen brauchen Management (1:1, Einstellung und Entlassung, Leistungsbewertung, Unterstützung bei der Karriereentwicklung). Dies ist keine Scrum-Rolle, aber es ist keine Rolle, die veraltet ist, weil eine Organisation Produkte innerhalb des Scrum-Frameworks erstellt.
Ich denke, die Sorge des Managers ist, dass er annimmt, dass, wenn dem Team gesagt wird, dass wir um 10 Uhr morgens aufstehen, alle gerade rechtzeitig dafür auftauchen (sagen wir 9:50 Uhr). Daher sorgt ein (formelles) Teammeeting dafür, dass alle pünktlich sind. FYI, der SM hat sich sehr dafür eingesetzt, aber die Antwort des Managers war ein solides "Nein, das kann ich nicht, tut mir leid". Um auf das Thema des Threads zurückzukommen, wie stark sollte der SM jemanden drängen, der technisch über ihm steht, dh seinen direkten Vorgesetzten? Das hängt auch damit zusammen, dass der Dev-Manager in einem Scrum-Team obsolet ist, aber normalerweise nicht vorkommt.
@dqm Scheint ein ernsthafter Mangel an Vertrauen in das Entwicklerteam durch den Manager zu sein. Für mich als Außenstehenden stellt sich die Frage: Hat das Team ein Problem damit, pünktlich zu erscheinen? Ist der Beginn um 9:30 Uhr in London üblich? Ich habe noch nie an einem Ort gearbeitet, an dem es keine obligatorischen Bürozeiten gab, die mindestens um 8:30 Uhr begannen.
@Kempeth Ich denke, das ist die Wurzel des Problems. Ich schätze, der Manager mag keine Konfrontation, da das Team tatsächlich zu spät kam (später als 9.30 Uhr, vielleicht 9.40 Uhr oder sogar 9.50 Uhr), während die Arbeitszeiten von 9 bis 5.30 Uhr sind. Dies ist ein Fall einer beratenden Straßenbahn, die für einen großen Kunden ohne Linienmanagement arbeitet (nur der Projektmanager, der in Verantwortung und Rang höher ist als der Rest des Teams). So effektiv möchte er das morgendliche Gedränge nutzen, um alle zu versammeln. In London ist es ganz normal, irgendwo zwischen 9 und 9.30 Uhr zu beginnen.
@dqm Und hat das funktioniert? Für mich scheint das Team bereits nach 9:30 Uhr aufgetaucht zu sein, obwohl das tägliche Gedränge um diese Zeit stattfindet. Sie könnten argumentieren, dass Daily Scrum kein Appell ist und es für das wahre Ziel des Meetings (Synchronisation des Teams) besser wäre, alle anwesend zu haben, als es früher zu haben, um die Leute zur Arbeit zu überreden. Aber das Team muss sich eingestehen, dass es deutlich später als die offiziellen Arbeitszeiten ankommt. Dies könnte zu Problemen (Client-Interaktion/Verfügbarkeit) und Ressentiments führen.
Das hat tatsächlich funktioniert. Hin und wieder kommt jemand zu spät, aber es hat definitiv die Schnelligkeit verbessert.

Gemäß dem Scrum-Leitfaden :

Der Scrum Master stellt sicher, dass das Entwicklungsteam an dem Meeting teilnimmt, aber das Entwicklungsteam ist für die Durchführung des Daily Scrum verantwortlich. Der Scrum Master bringt dem Entwicklungsteam bei, das Daily Scrum innerhalb der 15-Minuten-Timebox zu halten.

Das bedeutet, dass nach den Regeln von Scrum das Entwicklungsteam die Freiheit haben sollte, Zeit und Ort des Daily Scrums zu wählen, während der Scrum Master dem Entwicklungsteam die Regeln des Daily Scrum (den Zweck, die Absicht) beibringt , die Timebox).

In Wirklichkeit gibt es wahrscheinlich einige Einschränkungen hinsichtlich Zeit und Ort des Daily Scrum. Wenn es mehrere Teams gibt, müssen die Teams die verfügbaren Räume koordinieren, in denen das Meeting abgehalten wird. Wenn Tools erforderlich sind (ein Telefon für entfernte Teammitglieder zum Anrufen, die Notwendigkeit eines Fernsehers zum Projizieren einer elektronischen Tafel), dann schränkt dies auch die Orte ein, wie, wann und wo das Daily Scrum abgehalten wird.

Diese Frage grenzt jedoch an einige Themen, die außerhalb des Scrum-Frameworks liegen. Eine Sache ist das Konzept der „Kernzeiten“ – das ist eine Managemententscheidung. Das Management kann verlangen, dass die Mitarbeiter bis 09:30 Uhr im Büro sein müssen. Wenn die Mitarbeiter jedoch um 09:30 Uhr im Büro sein müssen, ist es möglicherweise nicht förderlich, das Daily Scrum sofort zu diesem Zeitpunkt abzuhalten.

Die Verantwortung des Scrum Masters besteht darin, der Organisation dabei zu helfen, einen agilen Ansatz zu übernehmen und das Scrum-Framework zu implementieren. Wenn Managemententscheidungen gegen die Regeln des Scrum-Frameworks verstoßen, sollte sich der Scrum Master einmischen und dem Management und dem/den Team(s) helfen, einen guten Zustand zu erreichen.

Die Antwort des Managers war: "Nein ... warum? Damit alle um 10 Uhr reinkommen können? Nein, ich möchte, dass die Stand Ups um 9:30 Uhr stattfinden."

Um auf diesen speziellen Punkt statt auf die allgemeine gestellte Frage einzugehen, möchte ich darauf hinweisen, dass das Team festgestellt hat, dass die Meetings zu diesem Zeitpunkt am effizientesten abgehalten werden, und es keine Vorschrift gibt, dass tägliche Standups als erstes stattfinden sollten. Es gibt oft Dinge, die man morgens klären oder überprüfen sollte, bevor man sich ins Standup stürzt, und es gibt den Leuten auch Zeit, etwa eine Stunde lang ununterbrochen zu arbeiten, bevor sie eine Besprechungspause einlegen.

Aber meine Güte, Mikromanagement! Viel Glück.

Es ist keine Frage der Autorität, es hilft dem Team, die Arbeit für den Sprint zu erledigen. Zwei Vorschläge, abhängig von der Anwesenheit des Managers:

  • Wenn der Manager Teil des Meetings ist, schlägt Servant-Leadership vor, dass Sie bei der Arbeit den Nutzen des gesamten Teams im Auge behalten.

  • Wenn sie nicht Teil des Meetings sind, handelt es sich um Mikromanagement und es klingt, als würden sie den Ansatz des „Befehlen und Eroberns“ genießen. Verhandeln Sie und finden Sie heraus, was sie bekommen möchten; es könnte ein einfacher Status sein (den der SM ohnehin kommunizieren sollte), um sicherzustellen, dass die Arbeit auf Kurs ist.

Es ist ein neues Team (2-3 Monate) und nicht notwendigerweise im gesamten Scrum-Framework ausgereift. Der Scrum Master arbeitet darauf hin, aber wir alle wissen, dass es etwas Zeit braucht. Ich denke, der Manager will dem Team nicht schaden oder seinen Fortschritt behindern, er ist bei der Besprechung anwesend, und wenn überhaupt, hat er normalerweise einen hilfreichen Beitrag, normalerweise am Ende der Besprechung. Er kommt 2 Stunden vor den offiziellen Startzeiten, also könnte man argumentieren, dass er der Meinung ist, dass 9:30 bereits spät genug ist.
Ich möchte auch hinzufügen, dass es allen Managern, die nicht unbedingt einen Scrum-Hintergrund haben (oder selbst wenn sie einen haben), nicht leicht ist, ein neu gebildetes Team in die Hände eines neuen Scrum-Masters zu „geben“. Das ist auch etwas, das Zeit braucht.
@dqm, beide Eigenschaften, die Sie beschrieben haben, klingen unheimlich symptomatisch für Mikromanagementverhalten :)
The Daily Scrum is an internal meeting for the Development Team. Der Scrum-Leitfaden . Wenn der Manager beobachten möchte, muss er schweigen, während das selbstorganisierende Entwicklungsteam die Kontrolle über die Planung und Durchführung der Veranstaltung behält.