Unser Engineering-Team verwendet agiles Scrum und wir wachsen endlich genug, um mehr Scrum-Rollen an mehr Mitglieder delegieren zu können, einschließlich an einige der Ingenieure wie mich.
Eine Rolle, die wir vorstellen, für die ich mich freiwillig gemeldet habe, nennen wir den „Türsteher“.
Die Rolle eines Türstehers in diesem Zusammenhang ist:
Eine vom Sprint getrennte Arbeitswarteschlange steht Türstehern zur Verfügung, um während der Ausfallzeit zu arbeiten. Bei dieser Warteschlange handelt es sich um kleine Aufgaben mit niedriger Priorität, die sich nicht auf die Geschäftsanforderungen oder Sprint-Ziele auswirken. Der Fortschritt dieser Aufgabe muss gestoppt werden, damit der Türsteher seiner Rolle nachkommen kann.
Ich suche nach einer viel formelleren Definition dieser Rolle und nach Informationen darüber, die ich in die Finger bekommen kann. Gibt es solche Informationen? Hat diese Rolle andere Namen, die bessere Suchergebnisse liefern?
Wie andere gesagt haben, gibt es in Scrum keine Rolle namens „Bouncer“. Der Scrum Guide definiert genau drei Rollen innerhalb des Scrum Teams :
Das Scrum Team besteht aus einem Product Owner, dem Entwicklungsteam und einem Scrum Master.
Da ein Scrum-Team funktionsübergreifend ist, kann das Team sicherlich alle Aktivitäten durchführen, die seine Sprint-Ziele fördern, und kann dies auf jede Weise tun, die für das Team sinnvoll ist. Das Definieren zusätzlicher Rollen (anstelle von Prozessen) ist jedoch ein Scrum-Antimuster, das typischerweise auf ein zugrunde liegendes Prozessproblem hinweist.
Ihr Team definiert eine Rolle mit dem Namen „Bouncer“, um eine Sichtung durchzuführen und Support bereitzustellen. Wenn du sagst:
Die Rolle eines Türstehers in diesem Zusammenhang ist:
Kommunizieren und verfolgen Sie den Support,
untersuchen Sie eingehende Probleme und
eskalieren Sie gegebenenfalls
Sie beschreiben eindeutig eine wiederkehrende Support-Funktion und nicht die Produktentwicklung oder zeitgebundene Arbeit, die die Bereiche sind, für die Scrum entwickelt wurde. Das bedeutet nicht, dass Scrum keine Fehlerkorrekturen oder Support zulässt; es bedeutet nur, dass es im Allgemeinen The Wrong Thing to Do™ ist, einen Unterstützungsprozess außerhalb des Scrum-Frameworks zu entwerfen und ihn dann wieder in Scrum zu integrieren.
In Scrum müssen alle Arbeiten im Product Backlog priorisiert, während der Sprint-Planung geschätzt und mit dem aktuellen Sprint-Ziel in Beziehung gesetzt werden. In einem richtig implementierten Scrum-Framework werden Fehler oder Fehler von außerhalb des aktuellen Sprints in das Product Backlog aufgenommen, während der Backlog-Verfeinerung diskutiert und priorisiert und dann geplant, ob und wann sie während der Sprint-Planung in den Geltungsbereich fallen.
Dies ist sinnvoll, da Scrum in erster Linie ein Projektmanagement-Framework ist und das Ziel darin besteht, Projekte mit einem definierten Umfang und einer begrenzten Dauer zu verwalten. Laufende Unterstützung oder sich wiederholende Prozesse sind keine Projekte und können in einem Rahmen, der eher auf Zeitfenster als auf Verfahrenszyklen ausgelegt ist, schwierig zu verwalten sein.
Meiner Meinung nach gehören Bugs oder Defekte im Produkt eines Projekts definitiv zum Scrum-Team, sollten aber innerhalb des Scrum-Frameworks behandelt werden. Laufender Support sollte jedoch nicht Teil von Scrum sein, es sei denn, es wurde eine geschäftliche Entscheidung getroffen, die Kapazität des Teams für die Zuweisung einer Zeitbox für Support innerhalb jedes Sprints dauerhaft zu reduzieren.
Eine bessere Alternative ist die Einrichtung eines separaten Support - Prozesses , vielleicht unter Verwendung von Kanban oder einer anderen zyklus- oder warteschlangengesteuerten agilen Methodik, der dann Probleme direkt behandeln oder sie gegebenenfalls wieder in das Product Backlog von Scrum einspeisen könnte. Konzeptionell liegt ein solcher Unterstützungsprozess außerhalb des Scrum-Frameworks, muss aber nicht isoliert werden!
Ich habe Scrum für Verwaltungs-, Support- und Backoffice-Prozesse verwendet, die nicht projektbasiert sind. Es kann getan werden. Das zentrale Merkmal von Scrum ist jedoch die Timebox, und der Support wird nicht von Natur aus von Schätzungen oder Timeboxen bestimmt.
Der einzige Weg, wie ich Scrum in solchen Nicht-Projekt-Bemühungen zum Laufen bringen konnte, ist:
Wenn Sie mit all dem oben Genannten nicht einverstanden sind, dann ist Scrum nicht das richtige Framework für Ihren Supportprozess. Evaluieren Sie Kanban als Alternative für warteschlangengesteuerte Arbeit oder finden Sie einen anderen Prozess, der für Ihre geschäftlichen und politischen Anforderungen besser geeignet ist.
Weitere Informationen zum Umgang mit laufenden oder wiederkehrenden Support-Aufgaben innerhalb von Scrum oder warum Scrum oft die falsche Wahl für die Verwaltung eines laufenden Support-Prozesses ist, finden Sie in den folgenden verwandten Antworten:
Es sieht so aus, als würden Sie eine klassische Support-Rolle außerhalb des Teams-Sprints beschreiben. Sichtung der Support-Warteschlange, um dem Scrum-Team Platz für seine Hauptarbeit zu lassen.
Hut ab.
Vielleicht sollten Sie die Einrichtung eines Kanban- Boards in Betracht ziehen, um Ihre Sichtungsarbeit zu unterstützen?
Aber um Ihre Frage formal zu beantworten: Es gibt keine solche agile Scrum-Rolle, um Ihre Arbeit zu beschreiben. Dies liegt daran, dass das Scrum-Framework leicht ist und Teams die Flexibilität bietet, es so zu implementieren, wie es für sie funktioniert.
Grüße
Scrum schreibt nur drei Rollen vor: Scrum Master, Product Owner und Delivery (oder Dev) Team.
Nichts hindert das Team jedoch daran, zu entscheiden, wie es die Herausforderungen angehen möchte, denen es gegenübersteht. Wenn es für Ihr Team arbeitet, jemanden zu haben, der diese Aufgaben übernimmt, ist das cool. Sie werden jedoch keine formale Definition finden.
Eine Frage, die ich jedoch habe, ist, warum Sie, wenn Sie keine Unterstützung suchen, nicht nur andere Teammitglieder bei der Sprintarbeit unterstützen würden. Es scheint, als würden Sie sich künstlich vom Team trennen.
Scrum sieht nur drei Rollen vor: Scrum Master, Product Owner und Entwicklungsteam. In Scrum sind keine anderen Rollen definiert. Da Scrum das Delegieren einiger Elemente jeder Rolle zulässt, können Sie der Rolle, die der Person zugewiesen ist, die bestimmte Aufgaben delegiert, einen Namen geben, und dieser Name würde Ihrer Organisation überlassen bleiben.
Die Product Owner-Rolle ist für das Product Backlog-Management verantwortlich, und es hört sich so an, als ob die meisten dieser Aufgaben direkt in diesen Bereich fallen. Konkret heißt es im Scrum Guide über den Product Owner :
Der Product Owner ist die einzige Person, die für die Verwaltung des Product Backlogs verantwortlich ist. Das Product Backlog Management umfasst:
- Produkt-Backlog-Einträge klar ausdrücken;
- Ordnen der Elemente im Product Backlog, um Ziele und Missionen am besten zu erreichen;
- Optimierung des Werts der Arbeit, die das Entwicklungsteam leistet;
- Sicherstellen, dass das Product Backlog für alle sichtbar, transparent und klar ist und zeigt, woran das Scrum-Team als Nächstes arbeiten wird; und,
- Sicherstellen, dass das Entwicklungsteam die Elemente im Product Backlog auf dem erforderlichen Niveau versteht.
Der Product Owner kann die oben genannten Arbeiten durchführen oder das Entwicklungsteam damit beauftragen. Der Product Owner bleibt jedoch verantwortlich.
Wenn Probleme von außerhalb des Scrum-Teams (das aus den drei Rollen besteht) gemeldet werden, wirken sich diese Probleme auf das Product Backlog aus. Dinge wie Fehlerberichte, Änderungen an bestehenden Funktionen oder neue Funktionsanfragen wären neue oder geänderte Product Backlog-Einträge.
Beachten Sie, dass der Product Owner einige dieser Verantwortlichkeiten an das Entwicklungsteam delegieren kann. Dadurch verringert sich natürlich die Kapazität des Teams. Die frühere Einbindung technischer Mitarbeiter kann jedoch dazu führen, dass besser verfeinerte Product Backlog-Einträge in die Sprint-Planungssitzungen aufgenommen werden. Dies ist ein Kompromiss, den das Team (oder manchmal die Organisation) eingehen muss.
Eine Sache, die Sie erwähnen, „Support kommunizieren und verfolgen“, kann auch in die Rolle des Scrum Masters fallen . Der Scrum Master unterstützt nicht nur das Entwicklungsteam, sondern auch den Product Owner und die Organisation. Der Scrum Master sollte dem Product Owner helfen, Wege zu finden, mit diesen eingehenden Anfragen umzugehen, und Methoden, um das Product Backlog angemessen zu verwalten, einschließlich des Schreibens guter Product Backlog-Einträge. Der Scrum Master ist auch dafür verantwortlich, dass alle Hindernisse für das Entwicklungsteam beseitigt werden.
Abgesehen von all dieser Definition von Scrum können Sie andere Aufgaben identifizieren, die im Laufe eines Sprints erledigt werden müssen und wer für deren Bewältigung verantwortlich ist. Und es liegt an Ihnen, diese Rollen angemessen zu identifizieren und gute Wege zu finden, sie zu delegieren, entweder auf dauerhafter oder rotierender Basis.
Ich persönlich denke, dass der Product Owner, vielleicht mit Unterstützung von einem Mitglied des Entwicklungsteams (vielleicht auf Rotationsbasis) und dem Scrum Master, bei diesen Punkten die Führung übernehmen sollte. Die Untersuchung eingehender Probleme und deren Umwandlung in Product Backlog Items ist definitiv eine Product Owner-Funktion, die delegiert werden kann. Die Arbeit an der Beseitigung von Hindernissen ist definitiv eine Scrum Master-Funktion, die eine angemessene Eskalation beinhalten kann. Die Verfolgung des Supports mag eine gemeinsame Verantwortung sein, aber ich würde dies als eine Aufgabe betrachten, die vom Scrum Master erledigt werden sollte, damit sich das Entwicklungsteam auf die Entwicklung konzentrieren kann, anstatt die Arbeit anderer Leute zu verfolgen.
Vicky Laidler
Matthias Walther
Alan Larimer