Unsere Version von Agile funktioniert nicht. Tipps?

Ich arbeite in einem kleinen Team von 4 Entwicklern. Wir implementieren eine Version von Agile, die uns Woche für Woche die gleichen Schwierigkeiten bereitet, und ich suche nach Vorschlägen, die uns helfen können, unseren Prozess zu verbessern.

Der Hintergrund:

Wir machen in der Regel zweiwöchige Sprints und bei jedem Sprint unterschätzen wir unsere Arbeit. Wir bekommen Probleme mit unserem Manager, weil wir hinter dem Zeitplan zurückbleiben.

Wir beginnen jeden Sprint damit, die Geschichten herauszuarbeiten, die unser Manager für uns erstellt. Manchmal wirft er auch die Aufgaben ein und wir schätzen sie. Wir verwenden keine Story Points. Wir verwenden die Software Urban Turtle, um "unsere Sprints zu verwalten", die im Wesentlichen nur aus Geschichten und Aufgaben und dem damit verbundenen Abbrennen bestehen. Wir planen keine Veröffentlichung am Ende eines Sprints.

Das häufigste Problem ist, dass wir eine Aufgabe zu Beginn eines Sprints planen, nur um festzustellen, dass sie einen viel größeren Umfang hat, aber immer noch eine hohe Priorität hat. Daher müssen wir zusätzliche Stunden daran arbeiten. Das zweithäufigste Problem ist, dass einer von uns auf ein technisches Problem stößt, das die verbrannten Stunden verlangsamt und eine Straßensperre verursacht.

Der einzige Vorschlag, der uns unterbreitet wird, besteht darin, unsere Schätzungen proaktiver anzupassen und Aktualisierungen während der morgendlichen Stand-ups bereitzustellen, damit wir uns auf die zusätzliche benötigte Zeit einstellen können.

Es scheint jedoch etwas grundlegend Falsches an der Art und Weise zu sein, wie wir Dinge tun. Vielleicht gibt es eine Trennung zwischen den Erwartungen des Managers auf Projektebene und den Erwartungen auf Sprint-Ebene. Weil wir diese Sprint-Iterationen gemäß einem Projektplan durchführen und daher einen Sprint verlängern oder Elemente verschieben, wird der Projektplan durcheinander gebracht. Als Entwickler werden wir daher ermutigt, Agile durchzuführen, indem wir die Schätzungen bei Bedarf erweitern, aber auch den Sprint pünktlich abschließen, was verwirrend ist.

Dies kann kein ungewöhnliches Problem sein, daher hoffe ich, dass diejenigen, die klüger sind als ich, ein oder zwei Vorschläge haben, wie wir aufhören können, bei jedem Sprint auf dasselbe Problem zu stoßen. Es ist frustrierend.

weil wir hinter dem Zeitplan sind

Diese Art des Denkens ist Ihr Problem. Sie sind nicht hinter dem Zeitplan, der Zeitplan ist zu eng. Sie sollten anfangen, Geschichten in abstrakten Punkten anstatt in Stunden zu schätzen, und dann im Verlauf von 2-3 Iterationen Ihre Geschwindigkeit herausfinden. Ihre Geschwindigkeit gibt an, wie viele Punkte Sie normalerweise bei jeder Iteration ausführen, nicht wie viele Punkte Ihr Manager einfügen möchte.

Danach spielt es keine Rolle, ob Sie Aufgaben konsequent unterschätzen - Ihre Geschwindigkeit berücksichtigt dies bereits.

Dies ist natürlich unmöglich, wenn Sie Stunden anstelle von Punkten verwenden.

Es scheint, dass die Probleme in der Unfähigkeit Ihres Teams liegen, genaue Schätzungen vorzunehmen, und in der Unfähigkeit, die Probleme vorherzusagen, die unvermeidlich sind.

Kleine Aufgaben lassen sich viel einfacher genau abschätzen als große Aufgaben. Versuchen Sie daher, Ihre Aufgaben in viel kleinere Teile aufzuteilen.

Erlauben Sie niemandem, eine Schätzung für eine Aufgabe vorzunehmen, es sei denn, er weiß genau, wie er es tun wird. Nehmen Sie für jede Aufgabe, die der Entwickler nicht ausführen kann, etwas Zeit in den Zeitplan DIESES Sprints ein, damit der Entwickler einige Untersuchungen und Entwürfe durchführen und eine genaue Schätzung erstellen kann. Nie weniger als einen halben Tag. Verschieben Sie die Aufgabe jedoch in den nächsten Sprint. Wenn Sie dann zur Planung für den nächsten Sprint kommen, haben Sie eine gute Schätzung. Beachten Sie, dass diese zusätzliche Zeit nicht verschwendet wird, da es Zeit ist, die der Entwickler auf jeden Fall ausgeben würde.

Und haben Sie keine Angst davor, zum Projektmanager zurückzukehren und ihm / ihr zu sagen, dass Sie mehr Sprints benötigen, um die Liste der Aufgaben zu durchlaufen. Es ist besser, das zu tun, als sich auf unmögliche Ziele festzulegen.

Versuchen Sie, 100% Ihrer Zeit zuzuweisen? Wenn ja, hören Sie damit auf. Addieren Sie zunächst alle Stunden, die Ihr Team während des Sprints beitragen muss. Gehen Sie dazu davon aus, dass jeder Mitarbeiter höchstens 6 Stunden pro Tag für das Projekt einsetzt. Dies wird als "idealer Tag" angesehen. Diese anderen zwei Stunden? Von Besprechungen, Pausen, Verwaltungsaufgaben, der Zeit am Morgen, wenn Sie E-Mails lesen und Ihren Tag planen, usw. aufgesaugt. Dies ist nicht "Absicherung Ihrer Wetten" oder "Sandsack", sondern realistisch.

Zweitens multiplizieren Sie diese 6 Stunden / Tag mit 80% . Warum? Denn als Menschen saugen wir daran, vorherzusagen, wie viel Zeit eine Aufgabe dauern wird. Dies erklärt Fehler in unserer Beurteilung. Auch hier ist es kein Sandsack, sondern realistisch.

Jetzt haben Sie eine Zahl, die eine realistische Anzahl von Stunden darstellt, die Sie voraussichtlich direkt für Ihre Aufgaben anwenden werden. Wenn Sie schätzen, hören Sie auf, Geschichten hinzuzufügen, wenn die nächste Geschichte Sie überraschen würde.

Lassen Sie den Product Owner keine Aufgaben hinzufügen. Die Scrum-Planung ist für das Team , die Bestellung ist nicht Teil des Teams, das die Arbeit erledigt. In der realen Welt kann ihre Eingabe natürlich sehr nützlich sein, wenn die PO besser informiert ist als jeder andere im Team. Wenn das Team jedoch die Hitze auf sich nimmt, um zurückzubleiben, muss es die Verantwortung dafür übernehmen, welche Aufgaben es genau erledigen wird. Ihr Ziel ist es, die Akzeptanzkriterien erfüllen zu können; Wenn eine Aufgabe nicht direkt dazu führt, tun Sie es nicht.

Denken Sie daran, bei Scrum geht es nicht darum, produktiver zu sein. Es geht darum, offener und kommunikativer zu sein. Die Arbeit wird alles brauchen, um fertig zu werden. Scrum dient dazu, die Schätzung zu vereinfachen, die Kommunikation mit Stakeholdern zu vereinfachen und Ihrem Team die Verpflichtung zu erleichtern.

Akzeptanzkriterien zu Beginn des Sprints schlecht definiert?

Anfängliche Schätzungen sind oft zu niedrig, da Story Cards bei der Schätzung schlechte Akzeptanzkriterien (falls vorhanden) haben. Was ist mit der Umstellung auf Acceptance-Test-Driven Development (ATDD), auch bekannt als Storytesting , um dem Team zu helfen, wirklich klar zu machen, was die Karte ist?

Geschichten zu groß?

Ein weiterer Grund, warum Sie mitten im Sprint feststellen, dass Ihre Geschichten länger dauern als erwartet, kann sein, dass sie zu groß sind. Haben Sie die Agile in einem Flash- Kartenspiel gesehen? Sie haben eine Karteikarte namens "Shrink XL Stories to Fit". Es bietet Strategien zum Aufteilen von Storys wie das Verschieben von Randfällen, Nebenwirkungen, nicht funktionierenden Aspekten oder die Fehlerbehandlung auf spätere Storys.

Sie können nicht schätzen, weil Sie nicht genügend Informationen haben?

@sleske macht einen guten Vorschlag über Spikes . Versuchen Sie, technische Unbekannte zum Schätzzeitpunkt zu identifizieren. Wenn es welche gibt, prüfen Sie, ob Sie die Geschichte auf einen späteren Sprint verschieben können, und führen Sie stattdessen eine zeitgesteuerte Untersuchung (Spike) dieses Sprints durch, um herauszufinden, was erforderlich ist, um eine Schätzung vornehmen zu können. Lassen Sie sich nicht mitreißen und lösen Sie die ursprüngliche Geschichte - der Spike ist fertig, wenn Sie genug wissen, um die Geschichte abzuschätzen.

Schneller scheitern

Und ich stimme @Patrick Hughes zu - erwägen Sie, auf 1-wöchige Sprints umzusteigen, damit Sie Probleme schneller erkennen können.

Neben den guten Vorschlägen von @Kevin und @Patrick ...

Agile Ansätze sind nicht "one size fits all", aber dieser Kommentar hat meine Aufmerksamkeit erregt:

Wir implementieren eine Version von Agile, die uns ständig die gleichen Schwierigkeiten bereitet

Sie sind besser dran, wenn Sie mit einer Methodik "nach dem Buch" beginnen (Scrum ist heutzutage anscheinend dominant) - und genau das tun, was ein anderes erfolgreiches Team getan hat ... Tun Sie das für ein paar Sprints ... und beginnen Sie erst dann zu überlegen Änderungen, die zur Optimierung der lokalen Bedingungen erforderlich sind.

Die Anmietung eines erfahrenen Scrum-Trainers (für einige Iterationen) kann ein echter Unterschied sein. Es ist subtil, agil richtig zu machen.

Zuerst empfehle ich, das Buch scrum-xp-from-the-Graben zu folgen . Schauen Sie sich auf Seite 26 den Punkt über Geschwindigkeitsberechnungen an. Die Idee ist, einen Fokusfaktor zu definieren und dies für den nächsten Sprint zu sagen:

verfügbare Manntage * Fokusfaktor = geschätzte Geschwindigkeit

Die geschätzte Geschwindigkeit ist die Summe der Schätzungen der Storys, die Sie beim nächsten Sprint implementieren möchten.

Und nach einem Sprint berechnen Sie den letzten Sprint-Fokusfaktor wie folgt:

Fokusfaktor = tatsächliche Geschwindigkeit / verfügbare Manntage

Dabei ist die tatsächliche Geschwindigkeit die Summe der Schätzungen der Storys, die Sie während des Sprints implementiert haben.

Dann verwenden Sie diesen tatsächlichen Fokusfaktor für den nächsten Sprint wieder und nach einigen Sprints können Sie genauer bestimmen, wie viel Sie während eines Sprints wirklich erreichen können ...

Bis Sie Ihre Schätzungen erhalten, um Ihre Sprints auf eine Woche zu verkürzen, erkennen Sie auf diese Weise den Überschuss schneller und können in kleineren Schritten reagieren.

Verbringen Sie mehr Zeit im Voraus, wenn Sie Aufgaben entwerfen, um etwas Luft zum Atmen zu bekommen, um Nebenwirkungen zu erkennen, die wahrscheinlich dazu führen, dass das Zielfernrohr überall blutet. Es kann auch sein, dass die Aufgaben selbst zu lang für eine ordnungsgemäße agile Schätzung sind. Prüfen Sie, ob Aufgaben in kürzere Schritte unterteilt werden können, die leichter zu schlucken sind.

Machen Sie es sich bequem, eine rote Fahne zu senden, sobald sie einen Haken bekommen, anstatt ein paar Stunden lang an einem Problem festzuhalten. Versuchen Sie, Ego und Schuld von diesem Prozess zu lösen, das ist für einige einfacher als für andere =)

Und wie bei @Kevin erwähnt, planen Sie nie wirklich 100% direkt für Aufgaben, da es immer Overhead-ähnliche Besprechungen gibt und so weiter, die Sie möglicherweise nicht als Zeitfresser erkennen.

Wenn an der Planungsfront alles kühl ist und dann auf zwei Wochen zurückgeht, werden Sie auf magische Weise wieder ein wenig Zeit von den weniger Besprechungen abholen.