Ich bin also der Scrum-Master für mein Team, und der Manager meines Teams besteht darauf, schlecht definierte Geschichten in den Sprint zu packen.
Obwohl sie beispielsweise ein Endziel vor Augen haben, ist es eine schlecht definierte Geschichte ... wir sind uns nicht einmal sicher, welche Systeme beteiligt sind oder wie viel Aufwand erforderlich ist. Meistens enthält die Geschichte Leute, mit denen man sprechen kann, um Anforderungen zu sammeln.
Nun, normalerweise würde ich diese Story in den Rückstand verbannen und einige Besprechungen zur Ausarbeitung ansetzen, da mein Chef darauf besteht , dass diese Story in diesem Sprint begonnen werden muss.
Als ich ihm sage, dass wir uns nicht dazu verpflichten können, etwas fertigzustellen, wenn wir nicht wissen, was es ist, antwortet er, dass es ihm egal ist, es muss diese Woche beginnen. Die Geschichte bezieht sich nicht einmal auf unser Projekt, sondern auf die Systeme und Anforderungen von jemand anderem.
Er macht auch deutlich, dass wir anhand von Geschichten beurteilt werden, die am Ende des Sprints nicht fertig sind.
Wie um alles in der Welt kann ich das effektiv umsetzen? Ich kann meinen Programmierer nicht die Geschäftsanalysearbeit erledigen lassen und eine Geschichte für den nächsten Sprint erstellen ... zwei Wochen sind zu lang.
Sag ich einfach „nein“, entferne die Story aus dem Sprint und lasse ihn wütend werden oder unterbreche ich den Prozess auf einer ziemlich routinemäßigen Basis?
Ist dies ein Hinweis auf eine Denkweise/Kultur, in der Scrum einfach nicht funktioniert und ich aufhören sollte, den Square Peg/Round Hole Dance zu machen? Wie kann ich effektiv zurückdrängen?
Sie machen kein Scrum. Möglicherweise tun Sie etwas Scrum-ähnliches, aber Ihr Chef muss den Scrum Guide lesen , und der Scrum Master muss eine aktive Rolle dabei übernehmen, diesen Manager über seine Rolle (falls vorhanden) im Projekt aufzuklären.
Der Manager meines Teams besteht darauf, schlecht definierte Storys in den Sprint aufzunehmen. Die Geschichte enthält hauptsächlich Leute, mit denen man sprechen kann, um Anforderungen zu sammeln ... [und] mein Chef besteht darauf, dass diese Geschichte in diesem Sprint begonnen werden muss.
Nur der Product Owner kann die Priorisierung von Stories im Sprint Backlog verwalten. Wenn Ihr „Chef“ (vermutlich das Linienmanagement) auch als Product Owner fungiert, liegt ein Interessenkonflikt vor. Wenn er nicht der Product Owner ist, dann überschreitet er seine Rolle als Stakeholder im Rahmen von Scrum.
Während das Entwicklungsteam an User Stories aus dem Product Backlog in ordinaler Reihenfolge arbeiten muss, ist es außerdem allein Sache des Entwicklungsteams, Stories zu schätzen und zu ermitteln, wie viele dieser Top Stories in jeden Sprint passen. Mit anderen Worten, Sie akzeptieren die Menge an Arbeit, von der Sie überzeugt sind, dass Sie jede Iteration beenden können; Das Arbeitsvolumen kann niemals von außerhalb des Entwicklungsteams zugewiesen werden.
Es ist niemals akzeptabel, dass sich ein wesentlicher Umfang oder Anforderungen innerhalb eines bestimmten Sprints ändern, es sei denn, der Product Owner fordert eine vorzeitige Beendigung und eine Rückkehr zur Sprint-Planung. Wenn Ihre Organisation gegen dieses Grundprinzip verstößt, ist dies ein ernsthaftes Prozessproblem für das Team und bricht möglicherweise den Rahmen.
Darüber hinaus ist eine der größten Ursachen für das Versagen von Frameworks die Unfähigkeit, ein verfeinertes Product Backlog an das Sprint Planning zu liefern. Der Product Owner (nicht das Linienmanagement, Stakeholder oder sonst jemand) ist dafür verantwortlich, umsetzbare Geschichten für das Sprint-Planungsmeeting zu liefern.
Während es für den Product Owner in Ordnung ist, während des Backlog Refinements mit dem Scrum Master und dem Entwicklungsteam zusammenzuarbeiten, um Storys zu klären oder zu zerlegen, kann das „Erfassen von Anforderungen“ nicht pragmatisch ein fester Bestandteil einer User Story sein; bestenfalls könnte man zusätzliche User Stories über das Sammeln von Anforderungen hinzufügen.
Ein gutes funktionsübergreifendes Team könnte einen Business Analyst haben. Auch wenn nicht, als Geschichte, die so etwas sagt:
Als Mitglied des Entwicklungsteams muss
ich Feature XYZ mit dem Marketing besprechen, um
dabei zu helfen, den Arbeitsumfang für das Feature für den folgenden Sprint zu definieren .
Unabhängig davon, ob Sie dies als Story Spike oder einfach nur Anforderungserfassung bezeichnen, ist dies eine akzeptable Geschichte, da sie die Kosten für das Projekt deutlich sichtbar macht (z. B. dass die Anforderungserfassung nicht kostenlos ist) und ermöglicht, dass die verfeinerte Geschichte in das Product Backlog eingespeist wird während der Backlog-Verfeinerung, um vom Product Owner priorisiert und schließlich während eines zukünftigen Sprints vom Entwicklungsteam geschätzt und akzeptiert zu werden, sobald die Story die Spitze des Product Backlog erreicht hat.
Der Scrum Master ist der Prozessschiedsrichter. Wenn Sie solche "Rahmenfouls" sehen, müssen Sie die rote Karte ziehen und Ihren metaphorischen Pfiff blasen. Darüber hinaus müssen Sie allen in der Organisation angemessene Schulungen über das Framework, seine definierten Meetings und Artefakte sowie die Rollen und Verantwortlichkeiten innerhalb des Scrum-Frameworks und der Organisation anbieten. Ob Ihr Chef wirklich ein Mitglied des Teams ist oder nicht, kann ich nicht beurteilen (obwohl ich es vermute), aber Ihre Rolle als Scrum Master besteht darin, mit ihm zusammenzuarbeiten, um rahmengerechte Wege für ihn zu definieren, wie er mit dem Team interagieren kann im Rahmen des Rahmens.
Wenn Sie dazu nicht in der Lage sind oder er nicht bereit ist, sich an die Anforderungen des Frameworks anzupassen, sollten Sie vielleicht damit beginnen, Ihren Lebenslauf zu entstauben. Dabei spielt es keine Rolle, ob das Problem ein unerfahrener Scrum Master oder ein Command-and-Control-Line-Manager ist; beides sind Schlüsselfaktoren, die statistisch wahrscheinlich zum Scheitern des Projekts führen, und wenn Ihre Berufsbezeichnung nicht „Professional Scapegoat“ lautet, würde ich nicht in einer Situation bleiben, die wahrscheinlich zu einem Karriereunglück führt.
Wie immer kann Ihr Kilometerstand variieren.
If your "boss" (who is presumably line management) is also acting as the Product Owner, this is a conflict of interest+1CodeGnome hat eine gute Zusammenfassung der Grundursache. Ihr Chef versteht nicht oder ist nicht davon überzeugt, wie Agile funktioniert. Das ist ein ziemlich großes Problem. Das fällt in die Problematik der agilen Einführung, was eine größere Frage ist, die Sie gestellt haben.
Die kurzfristige Lösung für diesen Sprint ist der Abnahmetest. Nehmen Sie sich ein paar Minuten Zeit mit Ihrem Chef und finden Sie heraus, was sein Maßstab wäre, wenn das Feature fertig ist. Wenden Sie die 5-Warum-Fragetechnik an und machen Sie einen Drilldown. Es kann ziemlich schnell erledigt werden, um seine Zeit nicht zu "verschwenden". Mit einem soliden Verständnis dessen, was er als Erfolg betrachtet, sollten Ihre Entwickler in der Lage sein, herauszufinden, was zu bauen ist.
Am besten-
Ihr Chef hat wahrscheinlich die technische Unsicherheit erkannt, mit der Sie konfrontiert sind. Für ihn ist es ein Risiko. Deshalb möchte er, dass die Geschichte jetzt beginnt; damit dieses Risiko konkretisiert werden kann.
Anstatt sich zu verpflichten, etwas zu erledigen, nehmen Sie die Ungewissheit an und verpflichten Sie sich, etwas zu haben, zu dem Sie Feedback erhalten können. Brechen Sie dies in eine Spitze auf, wobei der Rest der Geschichte danach folgt.
Die starre Einhaltung der Agile-/Scrum-Prinzipien in diesen Situationen hat die Tendenz, risikoreiche (und normalerweise hochwertige) Elemente weiter nach unten im Rückstand zu verschieben. Selbst der Versuch, klare Akzeptanzkriterien für etwas zu bekommen, das das Unternehmen noch nie zuvor ausprobiert hat, kann schwierig sein. Sprechen Sie auf jeden Fall mit Ihrem Chef, aber lassen Sie ihn wissen, dass es mehr als zwei Wochen dauern wird, bis Sie fertig sind, und dass Sie ihn über den Fortschritt auf dem Laufenden halten werden.
Wenn Ihr Chef danach immer noch darauf besteht, Sie angesichts der Ungewissheit an starren Schätzungen festzuhalten, dann ist er ein Idiot, und es ist Zeit, sich einen neuen Job zu suchen.
Wenn Sie mehr über Spiking vs. Analyse wissen möchten und wann Sie dies tun sollten, lesen Sie Cynefin oder einige der neuesten Artikel, die ich über BDD und Unsicherheit geschrieben habe .
Seien Sie hart und löschen Sie die gesamte Geschichte und lassen Sie die Person, die sie geschrieben hat, sie richtig neu schreiben und dem Chef, CTO und dem CEO Bericht erstatten. Es ist das einzige, was funktioniert.
Weise Männer bauen und zerstören.
Ich denke, es gibt ein tieferes Problem, wenn Ihr Chef Ihnen sagt, etwas zu tun, was er nicht richtig definieren kann. Aber anhand der wenigen Informationen, die Sie gegeben haben, kann ich nicht beurteilen, was es sein könnte oder nicht.
Davon abgesehen versuche ich, Ihr aktuelles Problem anzugehen:
Wenn Sie nicht entscheiden können, ob die Geschichte ein Epos ist oder nicht, behandeln Sie sie als Epos. Erstens separate Geschichten für die Dinge, die die Entwickler zu lösen wissen. Ziehen Sie diese. Dann separate Geschichten für weitere Untersuchungen zu den Dingen, bei denen sie sich nicht sicher sind. Schätzen Sie, wie viel Aufwand Sie für die Suche nach Lösungen aufwenden möchten. Ziehen Sie diese Geschichten auch, wenn sie passen. Was bleibt, ist eine schlecht definierte Geschichte mit einer ominösen „Ruhe“. Das kannst du nicht ziehen.
Wenn Entwickler am Sprint arbeiten, finden sie entweder Lösungen für die Problemgeschichten – dann verschwindet der „Rest“ – oder sie bekommen zumindest ein besseres Verständnis des Problems. Wenn das Problem nicht gelöst wurde, können sie den verbleibenden Aufwand für den nächsten Sprint besser einschätzen.
Der entscheidende Punkt ist jetzt wohl, wie viel man in die Forschungsgeschichten investiert. Dies hängt von der Wichtigkeit der Story für Ihren Chef/den Kunden ab (übrigens, wer von ihnen ist der PO? Es sollte nur einen geben...). Schätzen Sie mehr Aufwand ein, wenn Sie unsicher sind und das Teil entscheidend ist. Weniger, wenn es optional ist.
Hoffe das hilft!
Kennen Sie die 5 Warums ? Sehen Sie, ob Sie einen Kontext für die Geschichten finden können, die sie hinzufügen möchten.
Liegt es daran, dass Ihr Team viel konsequenter Werte liefert? Zeigen Sie, dass das Hinzufügen von Arbeit zu Multitasking führt, das Sie ausbremst.
Liegt es an einer Datumsabhängigkeit? Machen Sie diese Informationen transparent und verhandeln|priorisieren Sie basierend auf den Kosten der Verzögerung
Liegt es daran, dass Ihr Chef einfach nicht weiß, wie man Geschichten schreibt? Arbeiten Sie mit ihnen zusammen, um besser darin zu werden und zu verstehen, dass es Akzeptanzkriterien für den Beginn der Arbeit gibt, ähnlich wie für die Arbeit, die abgeschlossen werden soll.
Liegt es daran, dass sie an extrinsischen Druck statt intrinsischer Motivation glauben? Zahlreiche Studien zeigen, dass dies der Leistung abträglich ist.
Ändern Sie die Organisation oder ändern Sie die Organisation.
Meiner Meinung nach verlangt der Chef diese Funktion so stark, weil es etwas ist, das er wirklich für das Geschäft braucht, und das letztendlich das Gehalt aller zahlt.
SCRUM ist eine großartige Reihe von Tools, die helfen, produktiver zu sein, aber manchmal lassen sich seine strengen Regeln nicht sehr gut auf die reale Welt anwenden.
Natürlich muss der Chef besser verstehen, wie Scrum funktioniert, und versuchen, sich daran anzupassen. Es ist, als ob Ihr Chef versucht, ein Auto zu fahren, sich aber weigert, das Lenkrad zu benutzen, das Auto kommt vielleicht irgendwohin, aber kaum dorthin, wo er hin will.
Diese Überlegungen hätten jedoch früher angegangen werden sollen, jetzt stehen Sie vor einer Situation, die wie ein Notfall aussieht. Wenn Ihr Boot sinkt, reicht es möglicherweise nicht aus, das Schließen des Lochs während des nächsten Sprints zu planen, auch wenn das Schließen von Löchern im Rumpf möglicherweise nicht in der Sprintplanung vereinbart wurde. Sich über Wasser zu halten, hat bei jedem Verfahren Vorrang.
Ich würde raten, der Anfrage nach bestem Bemühen nachzukommen und zu versuchen, die richtige Fleckenbildung der Geschichte zurückzudrängen, damit Sie zumindest daran arbeiten können, wenn Sie wissen, was von Ihnen verlangt wird. Versuchen Sie grundsätzlich, Scrum so weit wie möglich zu übernehmen, aber denken Sie daran, dass dies eine Notfallsituation ist.
Ich würde auch alles aufschreiben und beim nächsten Sprint-Review mit dem Team besprechen, versuchen, Vorschläge zu bekommen, wie man in Zukunft ähnliche Situationen angehen kann, und dann müsste man vielleicht mit dem Chef reden, um ihm die Konsequenzen seiner zu erklären Anfrage, und Sie sind in der Lage, effektive Vorschläge (aus dem Team) zu diskutieren, und da diese nicht von Ihnen allein, sondern vom gesamten Team kommen, kann der Chef nicht einfach etwas verwerfen.
Sie, das Team und der Chef sitzen im selben Boot, die Handlungen aller haben Konsequenzen, Sie alle haben das gleiche Ziel, aber unterschiedliche Sichtbarkeit.
Sven Amann
Cleverer Neologismus