1 Stunde bis 2,5 lange Scrums jeden Tag – ist das verrückt?

Nichts von dem, was Sie beschrieben haben, ist Scrum

1. Scrum hat nicht die von Ihnen beschriebenen Rollen.

2. Sie scheinen die beiden wesentlichen Rollen für Scrum nicht zu haben – den Product Owner und den Scrum Master.

3. Bei Scrum kann nicht alles oberste Priorität haben. Der Product Owner erstellt eine geordnete Liste. Das Entwicklungsteam bearbeitet sie in dieser Reihenfolge.

4. In Scrum gibt es keine Statusmeetings. Das Daily Scrum ist ein 15-minütiges Timebox-Event für das Entwicklungsteam, um seine Arbeit zu koordinieren.

Es ist nicht klar, warum Sie es mit Scrum gekennzeichnet haben. Bitte beachten Sie den Scrum-Leitfaden .

Welche Anrufe würden Sie tätigen? Welche Entscheidungen würden Sie treffen?

Wenn Sie jedoch Scrum praktizieren möchten, können Sie damit beginnen, ein paar Leute zum Scrum-Training zu schicken. Ihr Team ist zu groß, um ein einzelnes Scrum-Team zu sein. Sie können es in zwei Scrum-Teams aufteilen. Sie können den Scrum Master und den Product Owner für die Teams bestimmen. Derselbe Scrum Master und/oder Product Owner kann bei Bedarf von den Teams geteilt werden.

Halten Sie die Teams relativ stabil. Sie können die Projekte zwischen den Teams aufteilen. Sie werden jedoch eine bessere Produktivität und Teammoral erzielen, wenn sich jedes Team auf ein Projekt pro Sprint konzentriert. Sie können eine Ausnahme machen, wenn es bei anderen Projekten kritische Produktionsfehler gibt, die nicht warten können.

Es ist nicht Scrum ... wie würden Sie das am besten verbessern?

Ich würde zwei sofortige Schritte unternehmen, um dies zu verbessern:

1. Teilen Sie das Team in zwei Teile auf und teilen Sie jedem Team die Hälfte der Projekte zu : Unabhängig von anderen Faktoren ist die Kommunikation in zu großen Teams ein Problem. Zumindest ersparen Sie sich die Notwendigkeit, bei allen Projektbesprechungen zu bleiben und zuzuhören.

2. Finden Sie einen Weg, Projekte zu priorisieren : Wenn das Management sagt „alles hat höchste Priorität“, sagt es tatsächlich, dass nichts Priorität hat. Wenn Sie einem der Projekte „höchste Priorität“ zuweisen, sagen Sie damit: „Zuerst diesem Projekt Ressourcen zuweisen, und wenn Ressourcen übrig sind, diese anderen Projekten zuweisen“. Wenn "alles oberste Priorität hat", werden alle Projekte an Ressourcen verhungern. In Wirklichkeit werden mehr Ressourcen beim Kontextwechsel verschwendet.

Ich denke, das Dilemma zwischen Scrum und Nicht-Scrum ist ein Problem der zweiten Stufe. Sie sollten zuerst die wichtigsten Dinge angehen, die meiner Meinung nach sind:

1. Alles hat höchste Priorität, was auch bedeutet, dass nichts Priorität hat, was auch bedeutet, dass Sie keine Priorität haben (oder eher sind Ihre Prioritäten das Ergebnis von gegensätzlichen Faktoren/Interessen, was die Verwaltung erschwert). Das ist das erste, was Sie ansprechen sollten. Wenn Sie keine Vorstellung davon haben, wo Sie investieren sollten, wird es sehr schwierig sein, herauszufinden, wie .
2. Sie haben 8 Projekte für 10 Personen + 3 Manager. Ich weiß nicht, wie Sie zu einer solchen Konfiguration gekommen sind, aber vielleicht können Sie (ich meine als Unternehmen) andere Möglichkeiten zur Verwaltung Ihres Entwicklungssystems erkunden. Ich könnte mich hier irren, aber vielleicht sind 1h * 5d * 13Personen = 65 Stunden/Woche, die für ein so kleines Team in die Koordination investiert werden, etwas zu viel ...

Um diese Dinge zu beheben, müssen Sie ein gemeinsames Verständnis der Probleme haben, mit denen Sie konfrontiert sind (dh der Manager hat das Gefühl, dass er/sie einen vollständigen Tagesstatus haben muss, da er/sie sonst keine klare Vorstellung davon hat was los ist ... wenn das der Fall ist, müssen Sie daran arbeiten, eine Lösung für dieses Problem zu finden) und wie sich dies auf die Arbeit der anderen auswirkt, und auf die Menschen, die an der Lösung dieser Situation beteiligt sind.

Wie andere bereits betont haben, ist dies in keiner Weise Scrum.

Wie kann man es beheben?

Der einfachste Weg, den ich gefunden habe, um unnötige Meetings wie diese zu reduzieren, besteht darin, ihre Kosten zu quantifizieren.

Nehmen Sie die durchschnittlichen Tageskosten des Teams (seien Sie vorsichtig, es wird immer noch teuer). Berechnen Sie ihren Stundensatz, multiplizieren Sie das mit den Stunden pro Woche, die diese Meetings in Anspruch nehmen, multiplizieren Sie das mit der Anzahl der Personen in den Meetings.

Verwenden Sie die resultierende GROSSE ZAHL, um zurückzunehmen und zu sagen, dass diese Meetings X $ pro Woche, XX $ pro Monat, XXX $ pro Jahr an direkten Kosten kosten, ganz zu schweigen von den Kosten für verlorene Produktivität bei anderen Dingen. Verwenden Sie dies als Rechtfertigung für die Reduzierung der Länge, Häufigkeit und Teilnehmerzahl der Meetings.

Die Quantifizierung der tatsächlichen Kosten (nicht einmal einschließlich der verlorenen Produktivität) regelmäßiger Meetings verängstigt die Leute normalerweise dazu, einen besseren Weg zu finden.

1 Stunde bis 2,5 lange Scrums jeden Tag – ist das verrückt?

Es ist nicht nur verrückt, es ist falsch. Das ist genau die Art von Situation, die Scrum verhindern soll. Wenn Sie ein 1-stündiges (ganz zu schweigen von 2,5) tägliches Meeting haben, machen Sie es falsch.

Das Management erfordert, dass das gesamte Team bleibt und zuhört.

Der erste Schritt zur Lösung eines Problems besteht darin, das Problem anzuerkennen. Besprechen Sie es mit einem Vorgesetzten – eins zu eins ist hier wahrscheinlich am besten, damit Sie frei reden können und sie nicht vor dem ganzen Team antworten müssen. Wenn Sie auf die Kosten dieser langen Besprechungen (zwischen 65 und 160 Arbeitsstunden pro Woche) und das Potenzial zur Verbesserung der Produktivität und Moral hinweisen, werden Sie wahrscheinlich viel Zustimmung bekommen.

Welche Entscheidungen würden Sie treffen?

Die Aufteilung der Gruppe in zwei Teams und das Erlernen des tatsächlichen Scrum anstelle des aktuellen Scrum nur dem Namen nach, wie andere vorgeschlagen haben, sind zwei gute Vorschläge, aber es sind große Schritte, die das Management möglicherweise nicht unbedingt machen möchte. Eine gute Scrum-Schulung kann teuer sein, und es kann auch schwer zu rechtfertigen sein, wenn Manager Kunden oder anderen Interessengruppen gesagt haben, dass Sie Scrum bereits praktizieren.

Da das primäre Ziel hier darin besteht, mehr Zeit mit der Arbeit und weniger Zeit mit Besprechungen zu verbringen, könnten Sie damit beginnen, die für die tägliche Besprechung zulässige Zeit zu reduzieren. Das Meeting sollte sich darauf konzentrieren, nur die Informationen zu vermitteln, die sich seit dem letzten Meeting geändert haben, und was alle bis zum nächsten Meeting erwarten können. Hören Sie auf, jedes Ticket im Sprint durchzugehen, und geben Sie stattdessen jedem Entwickler 1 Minute Zeit, um seinen Status mitzuteilen:

• Was haben sie beendet?
• Was erwarten sie bis zum nächsten täglichen Meeting zu erledigen?
• Was, wenn überhaupt, hindert sie daran, etwas zu erledigen?

Wenn detaillierte Informationen zu bestimmten Tickets übermittelt werden müssen, sollte dies in schriftlichen Kommentaren erfolgen, die dem Ticket selbst beigefügt sind – es muss nicht laut vorgelesen oder während des täglichen Meetings wiederholt werden.

Ein weiteres Ziel sollte sein, jeden Sprint etwas besser zu machen als den letzten. Um dies zu fördern, beinhaltet Scrum ein „Sprint Retrospective“-Meeting. Dies ist eine Gelegenheit für jeden im Team, Verbesserungen des Prozesses vorzuschlagen, aber es ist kein kostenloses Angebot, um Frust abzulassen. Das Meeting sollte eine Tagesordnung haben, zu der jeder im Team beitragen kann – eine Wiki-Seite eignet sich dafür gut – und die Person, die das Meeting leitet (kein Manager), sollte sich an die Tagesordnung halten und die Dinge am Laufen halten. Lassen Sie das Team nach einer Erklärung jeder vorgeschlagenen Änderung darüber abstimmen, ob es sie versuchen soll oder nicht, und machen Sie sich eine Notiz für das nächste retrospektive Meeting, um zu besprechen, ob die Änderung geholfen hat und fortgesetzt werden sollte.

In allen Fällen sollten ausführliche Diskussionen oder Argumente außerhalb des Meetings eingebracht und angesprochen werden, wobei die Ergebnisse dem Team per E-Mail, Chat oder wie auch immer das Team routinemäßig kommuniziert zurückgemeldet wird.

Was Sie beschreiben, ist weit davon entfernt, Scrum zu sein. Das Scrum-Framework bietet Ihnen jedoch einige Anleitungen, die hilfreich sein könnten.

In Scrum begrenzen wir die Teamgröße auf maximal 9. Dies geschieht, weil es viele Untersuchungen gibt, die zeigen, dass die Kommunikation in einem Team mit mehr als 9 Personen zu viel Aufwand verursacht.

Scrum begrenzt auch die täglichen Scrum-Standups auf maximal 15 Minuten. Der Grund, warum sich das Team für das Meeting einsetzt, ist, dass es gezielte und effektive Gespräche fördert. Es ist erwähnenswert, dass es beim täglichen Scrum um die Synchronisation innerhalb des Teams geht und nicht darum, den Fortschritt zu melden. Wenn man bedenkt, dass das gesamte Team in einem Meeting zusammenkommt, kostet das viel verlorene Arbeitszeit. Daher ist es wichtig, dass das tägliche Scrum effizient ist und Themen behandelt, die das gesamte Team betreffen. Wenn ein Thema angesprochen wird, das nicht jeden betrifft, sollte es aus dem Daily Scrum genommen und nur von denen diskutiert werden, die es betrifft.

Scrum betont auch die Bedeutung der Priorisierung. Untersuchungen haben gezeigt, dass je mehr Aufgaben von einer Person parallel erledigt werden, desto weniger effizient sind sie. Eine gute Priorisierung ermöglicht es den Teammitgliedern, konzentriert und effizient zu arbeiten.

Wie würden Sie geeignete Alternativen empfehlen, um sicherzustellen, dass Sprint-Items nicht auf der Strecke bleiben?

Hier kommt die Rolle des Product Owners ins Spiel. Das Entwicklungsteam arbeitet an den Aufgaben mit der höchsten Priorität und muss sich nur auf diese Punkte konzentrieren. Dabei betrachtet der Product Owner das Gesamtbild und arbeitet mit dem Team daran, den Arbeitsrückstand kontinuierlich zu verfeinern.

Sie haben einen Fehler bei der Organisation mit dem Team gemacht.

Meiner Meinung nach braucht man dieses Zeug:

• müssen die Anforderungen herunterbrechen, Aufgaben erstellen, schätzen und verteilen. Mit anderen Worten bedeutet dies, dass Sie das Sprint Backlog erstellen müssen. (mit dem Product Owner und Investor)

• müssen das kurze tägliche Sprint-Meeting durchführen.

• müssen sicherstellen, dass am Ende des Sprints potenziell auslieferbare Funktionalität geliefert wird.

• müssen den Status und den verbleibenden Aufwand für ihre Aufgaben aktualisieren, um die Erstellung eines Sprint-Burndown-Diagramms zu ermöglichen (ein Sprint-Burndown-Diagramm ist sehr wichtig)

Es klingt, als würden Sie Meetings und nicht Scrum beschreiben.

Scrum sollte zu Beginn des Tages stattfinden, das gesamte Team anwesend und stehen.

Weniger als 10 Minuten mit einer Zusammenfassung der erledigten Dinge/Aktualisierungen und einem Commit für die Aufgaben des aktuellen Tages; von jeder Person im Team durchgeführt.

Ich denke, vielleicht sind Planungsmeetings und Story-Review-Meetings Ihre 1-Stunden-Meetings.

Ich habe das folgende Dokument „Fourteen Observations of Good Scrum Practice“ mit Erfolg verwendet, hoffe, Sie werden es auch tun: http://lookforwardconsulting.com/wp-content/uploads/2011/01/ScrumObservations.pdf

Zusammenfassend besteht ein Scrum-Team normalerweise aus etwa sieben Personen, die in kurzen Zeiteinheiten namens Sprints zusammenarbeiten, wobei viel Zeit für Überprüfung und Reflexion eingebaut ist. Das Mantra von Scrum lautet „Inspizieren und Anpassen“, und Scrum-Teams zeichnen sich dadurch aus ein intensiver Fokus auf kontinuierliche Verbesserung – ihres Prozesses, aber auch des Produkts. Die Hauptrollen in Scrum sind Product Owner: das Produkt besitzen und vorantreiben und den Return on Investment maximieren, Der Scrum Master: als Coach fungieren und das Team zu einer höheren Effizienz und Selbstorganisation führen. Das Entwicklungsteam: ein sehr kollaboratives und selbstorganisiertes Team, das die eigentliche Arbeit erledigt.

Beobachtung 1: Sprint gehört dem Entwicklungsteam und SM sollte sicherstellen, dass das Team während des Sprints vor Eingriffen des Managements geschützt wird, die sich negativ auf den Sprint auswirken können.

Beobachtung-2: Eine gemeinsame Definition of Done, die das Ergebnis von Verhandlungen zwischen allen Akteuren in Scrum-Teammitgliedern ist, aber die Entwicklung hat das letzte Wort.

Beobachtung 3: Das Product Backlog gehört dem Product Owner und wird von ihm eingestuft. Andere Teammitglieder können Funktionen zum Hinzufügen vorschlagen, aber der PO hat das letzte Wort.

Beobachtung-4: Das Team ist für seine eigenen Verpflichtungen verantwortlich und sollte nur Verpflichtungen eingehen, von denen es wirklich glaubt, dass sie sie erfüllen werden.

Beobachtung 5: Der PO kann die Prioritäten für das Team festlegen.

Beobachtung-6: Der Scrum Master hat keine Autorität über die Aktivitäten des Teams. Der SM ist derjenige, der das Expertenwissen über das Scrum-Framework hat.

Beobachtung 7: Bei der Sprintplanung geht es darum, welche PBI das Team aufbauen wird und wie das Team sie aufbauen wird.

Beobachtung 8: Sprint-Backlog, Eigentum und Pflege des Entwicklungsteams.

Beobachtung-9: Das tägliche Scrum-Meeting ist ein Timebox-Meeting von maximal 15 Minuten, bei dem das Entwicklungsteam die Gelegenheit nutzt, seine Aktivitäten zu synchronisieren und die drei Fragen zu beantworten: Was haben Sie gestern getan, was werden Sie heute tun und alle Hindernisse, die das verhindern andere Teammitglieder können sie lösen. Der SM wird das Treffen moderieren.

Beobachtung 10: Die Sprint-Review, es ist Zeit für das Team zu glänzen und dem PO das Sprint-Inkrement zu präsentieren. Es kann nur eine demontierbare Erhöhung demonstriert werden.

Beobachtung-11: Die Retrospektive ist die Zeit für das Team, darüber nachzudenken, wie es sich verbessern kann.

Beobachtung-12: Stakeholder haben keine direkte Autorität über das Team und der SM sollte das Team abschirmen, wenn die Interaktion mit Stakeholdern als Ablenkung angesehen wird

Beobachtung 13: Wenn der PO beschließt, einen Sprint zu beenden, sollte er ein Terminierungsmeeting mit dem Team organisieren, um dem Team mitzuteilen, was hinter der Absage steckt, und das Team sollte wichtige Punkte für die Neigungen vorlegen, die den Stakeholdern mitgeteilt werden

Weitere Einblicke finden Sie in der pdf-Datei.