Wie kann ich in einem Scrum-Team mit der Zeit aufhören / vermeiden?

Eigentlich helfe ich einem kleinen Software-Shop bei der Scrum-Implementierung. Kürzlich hat mich der Scrum-Meister darüber informiert, dass er ein Problem hat, weil das Team im Laufe der Zeit daran arbeitet, den Umfang (Committed Backlog) zu erreichen. Sie haben also eine unwirkliche Geschwindigkeit .

Meine formelle Frage (n) lautet / lauten:

1. Abgesehen davon, dass wir über die Retrospektive gesprochen haben; halten Sie es für eine gute Idee, einige Hard-Blocks zu implementieren, um Überstunden zu vermeiden?

2. Wenn ja, welche Techniken / Tools schlagen Sie vor?

   • Revisionskontrollsystem (SVN, GIT, HG, etc ...), stundenweise blockiert (8 bis 5)
   • Arbeitsplatzblöcke nach Stunden (8 bis 5) oder kumulierte Stunden (bis zu 8 Stunden / Tag)?
   • Andere)...

3. Oder blockieren Sie diese Art von Dingen nicht; aber ein "Strafsystem" für ungerechtfertigte zusätzliche Stunden einführen ?

@Baqueta (und andere mit ähnlichen Fragen): Nein, sie werden nicht für zusätzliche Stunden bezahlt. Mein erster Rat an sie war, ihre Schätzungen zu überprüfen, weil sie vielleicht unterschätzt wurden. Das war mein Lieblingsratschlag:

Wenn sie ein Interesse an Überstunden haben, entfernen Sie es. Entwicklung kann man nicht 60 Stunden pro Woche machen, um produktiv zu bleiben, und es gibt zahlreiche Studien, die dies belegen. Wenn Überstundengeld das Problem ist, sollten Sie es loswerden und die Grundvergütung verbessern, damit sie das bekommen, was sie wert sind.

Ich denke auch, dass das Grundproblem (für dieses Team) eine Kombination der folgenden ist:

1. Den Entwicklern wird gesagt, was sie in einem Sprint erreichen müssen / werden nicht zu dem befragt, was erreichbar ist / werden ignoriert, wenn sie sagen, dass es zu viel Arbeit gibt.
2. Die Entwickler unterschätzen immer wieder, wie viel Zeit Aufgaben in Anspruch nehmen und wie viele Arbeitseinheiten an jeder Aufgabe beteiligt sind.

Zusammenfassung: Ich werde mit dem Team sprechen, um ihre Schätzungen zu überprüfen, und mit der PO, weil ich das Gefühl habe, dass sie , wie Sie erwähnt haben, nicht zu dem Umfang konsultiert werden .

Ehrlich gesagt, sind diese "harten Blöcke", die Sie in # 2 erwähnen, die schlechteste Idee, die ich seit langem gehört habe. Was passiert, wenn um 16.45 Uhr ein Fehler mit höchster Priorität gefunden wird und der Typ, der die Möglichkeit hat, Ihre Blöcke zu überschreiben, krank ist? Was # 3 betrifft, schlagen Sie vor , Leute für ihre Arbeit zu bestrafen .

Wenn das Team beständig Überstunden leistet, um Sprints zu absolvieren, hat es entweder ein Interesse daran, Überstunden zu leisten - z. B. Überstunden zu zahlen oder Überstunden als Urlaub zurückzugewinnen - oder es verpflichtet sich, zu viel Arbeit in den Sprints zu leisten.

Wenn sie ein Interesse an Überstunden haben, entfernen Sie es . Entwicklung kann man nicht 60 Stunden pro Woche machen, um produktiv zu bleiben, und es gibt zahlreiche Studien, die dies belegen. Wenn Überstundengeld das Problem ist, sollten Sie es loswerden und die Grundvergütung verbessern, damit sie das bekommen, was sie wert sind.

Wenn zu viel Arbeit in die Sprints fließt, hat dies normalerweise einen von drei Gründen:

1. Den Entwicklern wird gesagt, was sie in einem Sprint erreichen müssen / werden nicht zu dem befragt, was erreichbar ist / werden ignoriert, wenn sie sagen, dass es zu viel Arbeit gibt.
2. Die Entwickler unterschätzen immer wieder, wie viel Zeit Aufgaben in Anspruch nehmen und wie viele Arbeitseinheiten an jeder Aufgabe beteiligt sind.
3. Die Entwickler werden immer wieder auf Aufgaben aufmerksam, die nicht Teil des Scrums sind.

Wenn es die Nummer 1 ist, machst du es falsch . Keine zwei Möglichkeiten!

Wenn es # 2 ist, ist die übliche Ursache Unerfahrenheit - entweder mit Zeitschätzungen oder mit dem zu entwickelnden System. Ein guter Weg, um dies zu umgehen, besteht darin, auf Zeitschätzungen zu verzichten und mit der Schätzung der Arbeitseinheiten zu beginnen. Verwenden Sie eine abstrakte Einheit, stellen Sie jedoch sicher, dass es sich nicht um Echtzeitstunden handelt (letztendlich stellen Sie immer noch ein Zeitintervall dar, aber die Abstraktion ist wichtig!). Sie können dann berechnen, wie viele Arbeitseinheiten tatsächlich in einer Woche erledigt werden, und dann Sprints mit diesen Daten einrichten.

Wenn es die Nummer 3 ist, müssen Sie diese anderen Aufgaben irgendwie berücksichtigen. Wenn es konsistent ist, sollte es leicht zu erklären sein (siehe # 2 oben). Wenn es häufig, aber unvorhersehbar ist, ist es viel schwieriger, damit umzugehen. Sie werden einen Blick darauf werfen wollen, warum es passiert (z. B. schwerwiegende Fehler im Live-Code => sind Ihre Tests gründlich genug?), Aber wenn dies nicht behoben werden kann, ist Scrum möglicherweise nicht der richtige Ansatz für Sie. Aus genau diesem Grund ist mein Team kürzlich auf Kanban umgestiegen ...

Edit: Klarstellung meiner Kritik an den in der Frage vorgestellten Ideen.

Zunächst klingt es so, als ob sie zu viel Arbeit für einen Sprint haben, wenn sie Überstunden machen müssen, um dies zu erreichen. Sind alle Stunden protokolliert? Wenn ja, können Sie zählen, wie viel tatsächliche Arbeit ein Story Point ist, und anhand dieser Zahl die Arbeit für den nächsten Sprint berechnen.

Es ist auch wichtig sicherzustellen, dass das Team versteht, dass es sich nur selbst schadet, wenn es zu viel Arbeit auf sich nimmt. Sogar das agile Manifest spricht von nachhaltigem Tempo: "Agile Prozesse fördern nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten." Überstunden sind nicht nachhaltig.

Alles in allem würde ich Kommunikation anstelle von Gewalt und Strafen vorschlagen. Ich könnte mir vorstellen, dass dies nur zu einer Demoralisierung des Teams führen würde.

Die Entwickler, die Überstunden leisten, reagieren wahrscheinlich auf einen Anreiz, entweder tatsächlich oder wahrgenommen. Das ist, entweder den Anreiz zu entfernen, wenn er aktuell ist, oder zu kommunizieren, dass ein wahrgenommener Anreiz nicht funktionsfähig ist.

Für jedes vorgeschlagene Hard Limit gibt es einige Problemumgehungen oder andere Probleme. Quellcodeverwaltungsblöcke führen dazu, dass Entwickler ihre Commits beibehalten, bis das Fenster erneut geöffnet wird. Workstation-Blöcke müssten weg sein, sobald ein Support-Problem aufgetreten wäre oder einer der Entwickler aus irgendeinem Grund seine Arbeitsstunden verschieben musste. Strafsysteme führen nur dazu, dass Überstunden ausgeblendet oder begraben werden.

Ich denke, das Problem ist grundlegender - das Team hat einen Anreiz (oder glaubt, dass es einen Anreiz hat), Überstunden zu machen.

Dies ist, was angegangen werden muss. Sind ihre Leistungsbeurteilungen an ihre Geschwindigkeitszahlen gebunden? Macht das Management Überstunden? Werden Promotionen und Auszeichnungen an diejenigen vergeben, die lange arbeiten? Sind es Auftragnehmer, die für Überstunden bezahlt werden?

Sagen Sie dem Team einfach, dass es keine Überstunden machen soll. Zeitraum.

Dies kann dazu führen, dass sie einige Arbeiten nicht beenden können. Das ist kein Problem, das ist ein Datenpunkt. Sie können diesen Datenpunkt dann für die Planung des nächsten Sprints verwenden. Lassen Sie sie auch hier keine Überstunden machen. Ob sie fertig sind oder nicht, sie haben einen anderen Datenpunkt. Aufschäumen, ausspülen, wiederholen.

Es sind keine Tricks oder Limits erforderlich. Nur keine Überstunden machen. Erfahren Sie, wie viel Arbeit Sie leisten können, und passen Sie Ihre Sprintplanung entsprechend an.

Vielleicht gibt es eine Frage, nicht wie "viel" sie arbeiten, sondern wann. Dies kann ein Problem sein, wenn ein Arbeitstag ansteht, aber ein Großteil der normalen Arbeitszeiten besteht aus Besprechungen und anderen sozialen und persönlichen Ablenkungen. Arbeiten sie im Laufe der Zeit, weil sie sich einfach produktiver fühlen?

Reduzieren Sie den Arbeitsaufwand im Sprint und arbeiten Sie an der Flex-Zeit. Lassen Sie sie später kommen. Die verantwortliche Person muss den Leuten nur sagen, dass sie nach Hause gehen sollen. es ist alles in Ordnung. Es gibt einige Unternehmenskulturen, die ein Umfeld schaffen, in dem ein vorzeitiges Verlassen der Firma ein wenig die Stirn runzeln kann.

Ich hatte Probleme damit, als ich zum ersten Mal auf Scrum umstieg. Es ist normal, dass Sie sich in der Nähe einer Frist mehr Mühe geben möchten, aber scrum hat alle zwei Wochen eine Frist, daher ist dies eine Anpassung. Zusätzlich zu dem Vorschlag, den andere gemacht haben, um die festgeschriebenen Story-Punkte bei jeder Iteration zu reduzieren, würde ich auch vorschlagen, sicherzustellen, dass die Storys ausreichend aufgeschlüsselt sind, sodass jeder Entwickler mindestens zwei oder drei in einer Iteration beenden kann.

Dies stellt nicht nur sicher, dass jeder Entwickler das Gefühl hat, bei jeder Iteration etwas erreicht zu haben, sondern gibt Ihnen auch ein wenig Spielraum. Wenn Ihr Burndown zeigt, dass Sie eine Geschichte nicht fertigstellen können, können Sie sie herausziehen und die Leute den Geschichten zuordnen, die fertiggestellt werden können. Wenn die Leute sehen, dass der Umfang angepasst werden kann, wird es weniger wahrscheinlich sein, dass sie sich über unrealistische Fristen lustig machen. Wenn Sie mit jeder laufenden Story eine Iteration starten, haben Sie keinen Raum für Anpassungen.

Ein ideales kumulatives Flussdiagramm sollte ungefähr so ​​aussehen, wenn jeder zwei Storys pro Iteration beendet:

Es sieht nie so aus, weil es in Wirklichkeit sehr schwierig ist, alle Geschichten am letzten Tag zu beenden, während alle beschäftigt sind, aber es ist eine gute Faustregel. Wenn Sie überlastet sind, wird der rote Bereich größer und Sie können Storys entfernen. Wenn Sie nicht festgeschrieben sind, wird der blaue Bereich größer und Sie können Geschichten hinzufügen. Wenn Ihre Storys zu groß sind, wird der grüne Bereich größer und Sie sollten die Storys aufteilen.

Um Überstunden zu vermeiden, müssen Sie den Projektumfang kürzen.

Die folgende Grafik zeigt, wo die Unsicherheit in einem Projekt liegt:

Wenn Sie bemerken, dass Sie in der Phase der Produktdefinition und der Anforderungen eine enorme Abweichung in der Aufwandsschätzung feststellen. Sie können nicht sicher sein, ob die Implementierung der Funktion einen Monat oder einen Tag in Anspruch nimmt.

Ich wette, dass keine der Aufgaben erledigt ist, weil sie einfach zu groß und nicht spezifiziert sind und es zu viele von ihnen gibt.

Wenn Ihr Team 10 Tickets in 5 Tagen bearbeiten kann und 20 Tickets zugewiesen wurden, reduzieren Sie diese Anzahl, wenden Sie sich an den Product Owner / Project Manager / Manager / Client und weisen Sie ihn an, Prioritäten zu setzen.

Zu diesem Zeitpunkt ist dies die einzige Möglichkeit, die Mannschaft vor Überstunden zu retten. Sie können nicht alles liefern, aber was auch immer Sie liefern, wird mit geringerer Wahrscheinlichkeit Fehler aufweisen.

Ich würde auch raten, nach einem neuen Job zu suchen und Ihren Teamkollegen dabei zu helfen, dasselbe zu tun und ihre Lebensläufe und professionellen Portfolios zu reparieren. Eine Firma, die Überstunden erwartet, ist eine, für die niemand arbeiten sollte, und die produzierte Software wird verdammt fehlerhaft sein.

Ich rate dringend von "harten Blöcken" ab. Solche Kontrollen könnten als Mikromanagement angesehen werden und das zugrunde liegende Problem möglicherweise nicht lösen.

Ich schlage vor, dass Sie herausfinden, warum Programmierer Überstunden leisten. Die Antwort kann Sie überraschen. Es hört sich so an, als wären Sie ein "Außenseiter" (kein Angestellter des Unternehmens), und Programmierer sind möglicherweise bereit, offen mit Ihnen umzugehen, wenn Sie sich privat mit ihnen treffen (Einzelgespräche).

Ist der Grund für Überstunden wirklich die Arbeitsbelastung oder hat der Grund mehr mit Kultur oder Erwartungen zu tun?

Gründe für die Arbeitsbelastung könnten sein

• Der zugesagte Rückstand ist zu groß
• Entweder sind Programmierer oder der Produktbesitzer "vergoldet" (wodurch Funktionen komplexer werden als benötigt).

Erwartungen könnten sein

• Eine Art finanzielle Belohnung oder Anerkennung für Überstunden
• Angst vor dem Scheitern. Die Programmierer haben Angst, dass sie schlecht aussehen oder bestraft werden, wenn sie die Frist nicht einhalten
• Die Programmierer unterschätzen die schädlichen Langzeitfolgen von Überstunden.