Warum und aus welchen Gründen mögen Entwickler vielleicht kein "tägliches Gedränge"? [geschlossen]

Tägliches Gedränge zu halten hat folgende Vorteile:

1. Das Team wird aufeinander abgestimmt
2. Jeder weiß, wie viel Arbeit erledigt wurde
3. Das Burndown-Diagramm wird immer vollständiger
4. Task Board wird aktualisiert
5. Es dauert nicht so lange, 15 Minuten werden niemanden töten

In letzter Zeit (nach 6 Monaten der Implementierung und Verwendung von Scrum) habe ich jedoch das Gefühl, dass unsere Entwickler Scrum nicht mehr so ​​sehr täglich mögen. Die Leute aktualisieren einfach das Aufgaben-Board, ohne genug zu erklären, und es scheint, dass sie es langweilen. Ich sehe, wenn wir es aus irgendeinem Grund nicht halten, werden sie irgendwie überglücklich.

Ich weiß nur nicht, was daran falsch sein könnte. Gibt es irgendwo Gründe für Nachteile, die das "tägliche Gedränge" für ein Team haben kann? Was könnte die Ursache dafür sein, dass Entwickler das tägliche Gedränge satt haben?

Ich hatte Erfahrung in der Teilnahme an einem "SCRUM" -Team mit mehreren Arbeitgebern. Mir scheint, dass die Manager das "Daily Scrum Meeting" als Hauptpunkt von SCRUM herausnehmen und es als Ziel festlegen, anstatt es so zu haben, wie es ist: ein Mittel, um einen effektiveren Entwicklungszyklus zu erreichen .

Sehr schnell wurden aus den 15 - Minuten - Besprechungen 45 - Minuten - Besprechungen, die Aktualisierungen waren wirkungslos, weil die Leute damit beschäftigt waren, zu gähnen und zu denken, "wann können wir schon gehen?" eine Eulenperson, und jeden Tag um 9 Uhr morgens für dieses blöde Treffen zur Arbeit zu kommen, ist für mich ein guter Grund, den Job zu kündigen).

Wenn Manager eine Idee aufgreifen, die bei richtiger Anwendung nützlich sein kann, und sie auf den Punkt bringen, erhalten sie genau das Gegenteil der erwarteten Ergebnisse. Ich persönlich denke, je mehr Meetings ich besuche, desto weniger arbeite ich. Ich habe 2 regelmäßige Meetings pro Woche in meinem Kalender und überspringe normalerweise eines davon. Meetings sind für Manager, überlassen Sie den Entwicklern ihre Arbeit.

Ich bin mir sicher, dass es viele SCRUM-Enthusiasten geben wird, die sagen: "Aber es ist so wunderbar" - nun, rette es, ich habe alles gehört.

Ich würde das tägliche Aufstehen langweilig und nutzlos finden, wenn ich das Gefühl hätte, dass es wenig oder gar keinen Wert hat. Es gibt einige Dinge, die den Nutzen eines täglichen Stand-ups verringern können.

• Die Informationen, die weitergegeben werden, betreffen mich in keiner Weise.
• Keine Teamverantwortung und jeder arbeitet immer an seinen eigenen Projekten.
• Fehlen von Teamkommunikation außerhalb des Aufstands.
• Fehlender sichtbarer oder kommunizierter Fortschritt.
• Keine Informationen zum Teilen.

Das ist mir ein Rätsel, aber es gibt immer mehr mögliche Gründe.

Vielleicht sollten Sie einfach die Entwickler fragen, warum sie nicht interessiert zu sein scheinen? Wenn Sie mehr / bessere Kommunikation wünschen, sollte dies bei Ihnen beginnen.

Einige der Probleme bei täglichen SCRUM-Meetings:

• diejenigen, die zu lange dauern. Sie wollen keinen Manager-Typ in diesen täglichen, weil sie die Hauptursache für diese Art von Problemen sind. Sehen Sie, wie sie normalerweise einen Stuhl benutzen (ja, dafür aufstehen zu müssen heißt, die Leute dazu zu verleiten, schnell zu sein).
• Sie müssen hören, dass jemand (oder 2 oder 3 Entwickler) ein einzelnes Problem ausführlich beschreibt, anstatt sich zu entscheiden, später ein weiteres echtes Treffen zu planen, um es mit den Betroffenen zu besprechen
• dumme Stunden. Diese Besprechungen müssen nicht morgens stattfinden: Sie sprechen nicht über das, was Sie gestern getan haben, und entscheiden nicht, was Sie heute tun. Sie sprechen darüber, was Sie zwischen dem letzten Tag und diesem Tag getan haben, und entscheiden, was Sie bis zum nächsten Tag tun werden.
• Mangel an Eigentum an der App für die Entwickler. SCRUM funktioniert, wenn Entwickler nicht als Code-Affen behandelt werden. Das erste Anzeichen dafür, dass der Prozess schief läuft, ist, dass die Entwickler nicht beurteilen, wie viel Zeit es dauern wird, etwas zu tun.
• schon wieder dumme stunden. Wenn ein Teil des Teams begonnen hat, an einigen Dingen zu arbeiten, und sich "in der Zone" befindet, wenn das tägliche Geschehen eintritt, wird es zu einer Störung. Eine gute Zeit, um diese täglich zu haben, ist, wenn niemand arbeiten sollte (zum Beispiel nach dem Mittagessen oder kurz vor dem Beginn einiger Diskussionen, die während des Mittagessens stattfinden sollen).

Timing ist für viele der Mörder. Programmierer programmieren gern spät, schlafen spät und kommen nach dem Ansturm des Morgens herein. Zu einer festgelegten Zeit im Amt sein zu müssen - viel zu früh für sie. Und zu spät für andere, die früher kommen und schon anfangen zu arbeiten.

Flow ist ein weiteres Problem. Ein laufender Programmierer mit einigen Funktionen arbeitet bis spät in die Nacht, geht nach Hause und kehrt aufgeladen zurück, um fortzufahren. Wenn er ein Meeting mit zumeist nicht zusammenhängenden Themen durchstehen muss, kann dies ihn ablenken.

Meine Beobachtung ist viel zu oft, dass die Manager bei diesen Besprechungen nicht das Gefühl haben, dass sie tatsächlich etwas tun, sondern dass sie für das Team und das Projekt nützlich sind.

Beispielsweise wird ein Team beauftragt, eine Reihe von kurzen Fehlerkorrekturen für verschiedene Projekte durchzuführen. Sie arbeiten wirklich nicht als Team, sondern als Einzelpersonen. Da die Unternehmens- / Abteilungsrichtlinie dies jedoch vorschreibt, hält der Teamleiter / -manager ohnehin ein tägliches Scrum-Meeting ab. Alles, was erreicht wurde, ist, mehr als 15 Minuten für eine nutzlose Besprechung aufzuwenden und 15 bis 30 Minuten Ablenkung und mangelnde Produktivität vor und nach der Besprechung in Angriff zu nehmen.

Jetzt habe ich gesehen, dass Scrum in einem Projekt, das enge Termine hatte und viel Koordination zwischen den Leuten erforderte, die an verschiedenen Stücken arbeiteten, gut funktioniert hat. In diesem Zusammenhang war es ein großartiges System. Aber im Kontext von "Wir haben ein Meeting, weil wir ein Scrum / Agile-Shop sind und das ist, was wir tun sollen" kann das wirklich scheiße sein.

Stellen Sie sicher, dass niemand das Meeting monopolisiert.

Wenn 4 der Entwickler ihr Spiel in 5 Minuten aus dem Weg schaffen und die nächsten 10 Minuten damit verbracht haben, dem Teamleiter zuzuhören, der alle erstaunlichen , fantastischen neuen Entwicklungen, die er gemacht hat, detailliert beschreibt , von denen die meisten weder so erstaunlich noch so fantastisch sind so wie er das glaubt, werden sich die leute sehr schnell langweilen.

Treten Sie einen Moment zurück und denken Sie an Ihr Team:

• Arbeiten sie effektiv?
• Sind die Aufgaben rechtzeitig erledigt?
• Ist der Code robust und gut geschrieben?
• Stellt das Team sicher, dass nichts durch die Risse fällt?
• Koordiniert sich das Team so, dass es nicht doppelt arbeitet oder sich gegenseitig auf die Zehen tritt?

Wenn Sie auf all diese Fragen mit "Ja" antworten, sollten Sie sich vielleicht überlegen, warum Sie Ihrem Team geschäftige Aufgaben wie tägliche Besprechungen, Burndown-Charts und Aufgabenbereiche aufzwingen möchten. Welchen Wert fügt es hinzu? Möchten Sie bürokratische Daten nur zu Ihrem eigenen Vergnügen generieren oder möchten Sie das Team produktiver machen?

Hat die Produktivität abgenommen, seit das tägliche Gedränge gestoppt wurde, oder läuft alles wie zuvor? Wenn sich nichts geändert hat, warum die Besprechungen fortsetzen?

15 Minuten. Vermitteln diese 15 Minuten (zuzüglich der Vorbereitungszeit) genug neue und nützliche Informationen zwischen den Teammitgliedern, um die Produktivität des Teams für den kommenden Tag um mehr als 15 Minuten zu steigern? Wenn es nicht jeden Tag so viele nützliche Scrum-Inhalte gibt, denken die Teammitglieder wahrscheinlich, dass sie weitaus mehr Fortschritte auf dem Weg zu den Zielen erzielen würden, wenn sie dieses Meeting so schnell wie möglich verlassen und wieder an die Arbeit gehen würden.

Wenn Sie nur das Board und die Tabelle regelmäßig aktualisieren möchten, legen Sie Entwurfskopien in ein Wiki.

Ich würde vorschlagen, wenn Sie die Retrospektive abhalten, um zu sehen, was gut und was nicht gut gelaufen ist, und um zu sehen, ob die Entwickler das tägliche Stand-up-Meeting selbst als Zeitverschwendung auflisten. Dann müssten Sie es ein wenig neu organisieren.

Meine persönliche Erfahrung:

• Das Ziel ist zu wissen, was wir heute tun und wo wir gestern waren. Anstatt sich an die Agenda zu halten, kommt es zu einer technischen Diskussion über Blocker zwischen 2 Personen, und die anderen 15 langweilen sich. Identifizieren Sie das Problem, diskutieren Sie es jedoch im Freien
• Die Leute kommen nicht pünktlich in den Besprechungsraum, und dies wird zu einem Zyklus, den einige absichtlich machen. Daher muss der Scrum-Master außerhalb des Meetings eine ruhige Diskussion mit ihnen führen, um sicherzustellen, dass sie pünktlich beginnen und enden.
• Wir aktualisieren Burndown-Charts bereits außerhalb des Scrum-Meetings, sodass dies nicht der Hauptzweck des täglichen Stand-Ups ist.

Der Widerstand kommt, wenn: 1) Sie verwendet werden, um Leute zu zwingen, für 9 Uhr morgens hereinzustürmen. Wenn der Zug zu spät kommt, ist es zusätzliche Belastung. 2) Schlechte Scrum-Führung. Der Anführer sollte den Leuten sagen, dass sie Dinge lieber aus dem Verkehr ziehen sollen, als dass sie herumstehen und etwas hören, das sie nicht beeinträchtigt. 3) Wertloser Inhalt. Dies ist wieder ein Problem der Scrum-Führung. Es soll ein Forum sein, um Engpässe, Flugbahnprobleme und mögliche Kooperationen anzugehen. Was tatsächlich passiert, ist, dass jeder nur sagt, was er an diesem Tag erwartet, was für niemanden anderen von Nutzen oder Interesse ist. 4) Stehen. Ich werde nicht für das Stehen stehen. Die Logik hinter dem Stehen war, dass es die Menschen ermutigt, kurz zu sein. Die Leute rasseln eigentlich einfach weiter.

Ich habe es geschafft und war oft Teil von Scrum-Teams. Die Hauptgründe, warum Entwickler Scrum nicht mögen, sind:

• Da sie von einem sehr schlechten Scrum-Master ausgeführt werden, muss Ihr Scrum-Master die Steuerung des Scrums verbessern, wenn es 45 Minuten dauert.
• Der mit Abstand größte und aufrichtigste Grund, warum sie es nicht mögen, ist, dass es sehr schwer ist, sich in einer schlechten Arbeitsmoral zu verstecken, dh es zeigt eklatanterweise faule Leute. Einige Entwickler, mit denen ich zusammengearbeitet habe, sind schockierend. Sie brauchen Tage, um Aufgaben zu erledigen, die 30 Minuten dauern sollten. Ein guter PM sollte Barrieren für Entwickler beseitigen, was bedeutet, dass sie in der Lage sein sollten, ihre Aufgaben im Sprint zu erledigen. Die Entwickler mögen es nicht, weil sie jeden Tag aufstehen und ihre Fortschritte demonstrieren müssen. Es macht Angst, wenn sie aus irgendeinem Grund keinen Fortschritt zeigen können. Wenn es sich um ein gültiges Problem handelt, sollte ein guter Scrum-Master dieses Problem so schnell wie möglich beheben.

Das Problem tritt auf, wenn Scrum-Master nicht über die Autorität, die Fähigkeiten oder die Fähigkeit verfügen, Blockierungsprobleme zu lösen. Tatsächlich habe ich einige Probleme mit der Beerdigung gesehen, in der Hoffnung, dass sie verschwinden. Das ist katastrophal.

Ehrlich gesagt, in 99% der täglichen Scrum-Meetings, an denen ich teilgenommen habe, hätten so ziemlich alle Diskussionen / Fragen / Antworten mit ein paar E-Mails behoben werden können.

Ich denke ehrlich, wir müssen mehr berechtigte Gründe zeigen, um KEINE Meetings zu haben. Bauen Sie Umgebungen, in denen, wenn es Zeit ist, alle Personen persönlich in einen Raum einzubeziehen, dies ein guter Grund sein und so organisiert werden sollte, dass die Zeiteffizienz maximiert wird.

Ich hasse Meetings im Allgemeinen und bevorzuge die Verwendung von Videokonferenzen, Telefonen, E-Mails und allem, was es mir ermöglicht, in meine Arbeit einzusteigen oder zu bleiben, ohne aufstehen und meinen Produktivitätsfluss unterbrechen zu müssen.

Ich persönlich denke, wenn Sie mehr als vier Meetings in einem Zeitraum von 8 Stunden haben, werden Projekte nicht gut verwaltet.

Es gibt viele Faktoren, die zu den Spannungen bei Besprechungen beitragen. Betrachten Sie dies als einen der wichtigsten Gründe, warum Besprechungen Sie mehr kosten als sie wert sind:

• Fokus - Software versus Meetings
• Management - Manager brauchen Messung
• Persönlichkeit - Introvertierte vs. Extrovertierte
• Zeit - Interrupts, Maker- und Managerzeit
• Ziele, Prioritäten

Jeder dieser Faktoren wird im Folgenden erläutert.

Fokus - Mir macht es Spaß, Software zu entwickeln, und dazu gehört das Nachdenken über die Herausforderungen (Probleme), das Erstellen von Lösungen, das Erstellen der Software und Besprechungen, die mich vom Fokus auf die Aufgaben ablenken, die die Software erstellen. Es gibt einen Zustand namens " Flow ", in dem ein Entwickler in die Herausforderung (das Problem) eintaucht, ein mentales Modell der Lösung erstellt und sich vollständig auf die Erstellung der Lösung konzentriert. Ein Entwickler kann bis Mitternacht arbeiten, nur essen und schlafen lassen und dann in einen Zustand zurückkehren, in dem er nicht mehr weiterkommt.

Entwickler müssen Ablenkungen vermeiden, und viele finden, dass es Vorteile gibt, bis spät in die Nacht zu programmieren (sie vermeiden Lärm, Telefonanrufe, geschäftiges Büro und Kollegen, die keine Entwickler sind, die ihre Arbeit unterbrechen). Und wenn Sie bis 22, 23 oder 24 Uhr gearbeitet haben, ist es nicht unvernünftig, später zur Arbeit zu kommen (10, 11, 12 Uhr?). Ist es vernünftig zu erwarten, dass Entwickler von 9 Uhr bis Mitternacht arbeiten?

Scrum-Meetings (und alle Meetings) lenken den Entwickler von seinem Hauptzweck ab, nämlich dem Erstellen von Software.

Management - Manager müssen messen, um erfolgreich zu sein. Daher müssen Zeitpläne, Ergebnisse, Zeitpläne, Prioritäten und Besprechungen erstellt werden, um Fortschritte zu messen und zu berichten sowie Abhängigkeiten, Verzögerungen und Risikobereiche aufzudecken. Die Herausforderung bei einem Scrum besteht darin, dass ein Manager diese Dinge benötigt, der Entwickler sich jedoch konzentrieren muss. Besprechungen dienen dem Manager und bieten dem Manager eine Möglichkeit, Status und Fortschritte zu ermitteln, zu messen und zu verfolgen, aber Besprechungen bieten Entwicklern selten einen Nutzen. Bedenken Sie, dass Manager mehr Wert schaffen, wenn sie mit Ablenkungen umgehen, Hindernisse beseitigen und Entwicklern die Möglichkeit geben, sich auf das Erstellen von Software zu konzentrieren.

Es gibt Lösungen für die Notwendigkeit von Besprechungen. Ein Manager kann seine Entwickler besuchen, Statusberichte anfordern, ein Protokoll festlegen, wenn Unterbrechungen weniger aufdringlich sind, oder eine Richtlinie festlegen, mit der der Entwickler über den Fortschritt informiert wird, wenn der Entwickler unterbrechbar ist. Sehen Sie sich die Diskussion der Zeit an, warum dies wichtig ist.

Persönlichkeit - Denken Sie daran, dass einige Menschen introvertiert und andere extrovertiert sind. Extrovertierte genießen soziale Interaktionen und werden von ihnen wieder aufgeladen. Manager sind in der Regel extrovertiert (da Extrovertierte in der Regel besser mit sozialen Interaktionen umgehen), obwohl Introvertierte als Manager erfolgreich sein können. Introvertierte können sich an sozialen Interaktionen erfreuen und diese sogar übertreffen, werden aber durch Einsamkeit wieder aufgeladen. Entwickler sind oft introvertiert und arbeiten erfolgreich alleine (oder in kleinen Teams), weil sie keine sozialen Interaktionen "brauchen". Sie können gerne alleine an Problemen arbeiten (auch wenn Extrovertierte Entwickler sein können). Tägliche Scrum-Meetings können zu geselligen Anlässen werden, gut für Extrovertierte, aber nicht so gut für Introvertierte.

Zeit - Entwickler können in Besprechungen keinen Code schreiben. Sie können auch nicht über schwierige Probleme nachdenken (es sei denn, sie führen ein Brainstorming durch), während sie durch Besprechungen abgelenkt werden. Entwickler benötigen große Zeitblöcke, um sich auf die Erstellung von Software zu konzentrieren. Meetings sind Unterbrechungen, die von ihren Bemühungen ablenken. Wenn Sie stundenlang in die Lösung eines Problems vertieft sind, fast fertig sind und jemand "Zeit für das Gedränge" sagt, werden Sie unterbrochen und verlieren möglicherweise Stunden Arbeit beim "Schalten". Oder Sie waren bis 23:00 Uhr bei der Arbeit, haben die Arbeit verlassen, sind nach Hause gereist, haben über das Problem geschlafen, sind aufgewacht, sind zur Arbeit zurückgereist, um das Problem zu lösen, und sind dann nach einer Stunde Arbeit an einem Problem unterbrochen worden, weil es ist "Zeit für das Gedränge".

Paul Graham hat einen ausgezeichneten Artikel über Maker Time vs. Manager Time, der dieses Problem viel besser erklärt als ich. Es genügt zu sagen, dass eine geplante oder ungeplante Unterbrechung der Besprechung den Ablauf unterbrechen und einen Entwickler von der Maker-Zeit zur Manager-Zeit zwingen kann. Glauben Sie mir, Sie wollen Entwickler auf Maker-Zeit.

Ziele, Prioritäten - Entwickler und Manager haben unterschiedliche Ziele und Prioritäten. Manager haben die Pflicht, Zeitpläne zu verfolgen, Kosten zu minimieren, sicherzustellen, dass ihre Berichte verantwortlich sind und dass sie Leistung erbringen. Entwickler haben das Ziel, die Software zu entwickeln, die die Herausforderungen / Probleme angeht. Diese Ziele stehen nicht in Konflikt, aber es ist der Kommunikationsmechanismus, der die Spannung erzeugt. Besprechungen dienen den Bedürfnissen des Managers und optimieren die Zeit des Managers, stehen jedoch im Widerspruch zu den Bedürfnissen des Entwicklers. Scrum-Meetings verwerfen die erste Regel von Meetings, "haben eine Agenda" und neigen dazu, mehr zu wandern. Und Meetings werden verwendet, um die Kommunikation (für den Manager) zu optimieren, kosten aber den Entwickler Zeit (Unterbrechungen, Flussverlust usw.).

Was ist das Ziel? Software zu entwickeln, die den Anforderungen schnell und qualitativ gerecht wird, während Einschränkungen bestehen (Qualität, Zeit, Kosten, Prozess). Scrum und andere agile Methoden erkennen die Prozessbeschränkung und versuchen, diesen Faktor zu minimieren. Sie waren erfolgreich, weil sie diese Einschränkung minimieren. Das Hinzufügen von Besprechungen kostet jedoch Zeit und die Unterbrechung kostet den Entwickler viel mehr als die Dauer der Besprechung.

Ändern Sie das Meeting, um sicherzustellen, dass es Vorteile bietet:

1. Planen Sie es zu einem Zeitpunkt, der Ihnen Komfort bietet. Warum kann es nicht 30 Minuten nach Arbeitsbeginn sein, damit jeder E-Mails lesen und seine Gedanken für das Meeting organisieren kann? Kürze braucht Planung. Das Unvorbereitete kann für immer weitermachen.
2. Identifizieren Sie Probleme, die vermieden werden könnten, wenn während des Meetings ein Problem mitgeteilt worden wäre. Jeder muss verstehen, worum es geht.
3. Tun Sie alles, um die Eingaben aller auf ein Minimum zu beschränken. Es ist nicht der Ort für Debatten. Ermutigen Sie die Teilnehmer, private Besprechungen außerhalb der täglichen Besprechung zu planen, die sich auf ein Thema konzentrieren, das diskutiert werden muss. Regel: Es spricht immer nur eine Person.

Alle Beschwerdeführer müssen sicherstellen, dass sie nicht zum Problem beitragen. Wenn Sie Ihre Ziele für das tägliche Gedränge erreichen können, ohne weniger schmerzhaft zu sein, würden wir es gerne hören.