Ich vermute, dass die Probleme in Scrum-Teams in meiner aktuellen Organisation diesen einen Aspekt verdrängen, wollte die Frage aber genauer darauf fokussieren, wie Scrum besser gemacht werden kann, als es derzeit gemacht wird.
Wir sind eine neue Organisation für Agile/Scrum und haben viele Herausforderungen. Wir sind horizontal bis zum Wahnsinn geschichtet, wo fast jeder Aspekt von Software und Technologie von einem externen Unternehmensplattformteam bereitgestellt wurde, das einen unglaublich spezifischen Aspekt eines gesamten Softwaresystems monopolisiert (z. B. ESB-Team, Reporting-Team, DBA-Team, Team für geplante Aufgaben, Benachrichtigung über Geschäftsereignisse usw.)
Unser Projekt ist eine Art Knotenpunkt mit einer absurden Anzahl externer Schnittstellen, die in unsere Software hinein- und herauslaufen, die wir zu liefern versuchen. Wir haben viele, viele, viele Abstraktionsebenen von Business und Operations über Operations Business Analysts, Product Owner bis hin zu Business System Analysts, die detaillierte funktionale Anforderungen in Form von User Stories und Akzeptanzkriterien definieren.
Dieses Projekt hat ein großes Budget, also haben sie zwei Scrum-Teams gebildet, aber zu meinen äußerst lautstarken Einwänden war die Entscheidung des Scrum-Masters, die beiden Scrum-Teams horizontal zu trennen, sodass ein Scrum-Team User Stories für Stakeholder liefert, während das andere Scrum-Team liefert auf mehr technische und Schnittstellengeschichten in einer verdaulichen Form für das andere Scrum-Team. Meine unbeachteten Einwände waren, dass eine User Story ein vollständiger vertikaler Schnitt sein sollte, da wir sonst unsere Fähigkeit beeinträchtigen, funktionsübergreifend zu sein. Das Argument gegen meins ist, dass selbst das einfachste, zersplitterte Stück Geschäftswert aufgrund der obszönen Menge an externen Abhängigkeiten, die jede einzelne Geschichte erfordert, nicht in einem zweiwöchigen Sprint geliefert werden konnte. Stattdessen arbeitet das zweite Team vor dem User-Story-Team.
Das alles scheitert in der Praxis kläglich, aber trotz alledem besteht das größere Problem immer noch darin, dass unsere Backlog-Grooming- und Sprint-Planungssitzungen mehr als 8 Stunden in Anspruch nehmen.
Unser Scrum Master besteht darauf, dass wir das Meeting nicht beenden können, bis genügend Stories für den nächsten Sprint fertig sind, egal was passiert. Die meisten Stories sind einfach noch nicht fertig in Bezug auf die Anforderungen, die ich fühle, wo die User Story klar ist und die Akzeptanzkriterien Sinn machen. Ich versuche ständig, ausgedehnte, tiefgründige Fachdiskussionen zu unterdrücken, über die die Techniker im Raum unbedingt reden, aber normalerweise gebe ich nach einer Weile einfach auf und lasse sie über ihre Ängste sprechen.
Ursprünglich habe ich versucht, in den Meetings eine harte Haltung einzunehmen und die Geschichte Not Ready zu nennen und zurück zum Backlog zu gehen, aber ich wurde von dem frustrierten Product Owner belehrt, dass wir überhaupt nichts Nützliches in den nächsten Sprint bringen.
Als nächstes habe ich versucht, eine Rückkehr zu Sprint Zero zu fordern, weil wir einfach noch nicht bereit sind, an irgendetwas zu arbeiten. Es ist klar, dass das Scrum-Team mehr Anleitung zu Anforderungen und High-Level-Design benötigt, und da ich für die Systemarchitektur verantwortlich bin, stimme ich zu, dass wir zu schnell voranschreiten, als dass ich den Grad an Designdetails angeben könnte, den die technischen Leute für nötig halten an einer Geschichte zu arbeiten. Ich versuche, dies auszugleichen, indem ich während des Sprints vollständig für Fragen oder Bedenken zur Verfügung stehe, aber es mildert nicht die Angst, die das Team vor der bevorstehenden öffentlichen Demütigung hat, wenn es im Standup steht und zugeben muss, dass es nicht so ist. Sie wissen nicht, was sie tun sollen, und dass ihre Geschichte erneut in Gefahr ist. Mein Ruf nach Sprint Zero wird vom Scrum Master nicht beachtet, der darauf besteht, dass wir unsere strengen regulatorischen Mindestfristen nicht einhalten werden, wenn wir in Sprint Zero „Zeit verschwenden“. Es ist eine völlig unveränderliche Position, von der er sich weigert, zurückzutreten.
Daher hat sich unsere Backlog-Grooming- und Sprint-Planung auf mehr als 8-stündige Sitzungen entwickelt, in denen wir im Wesentlichen unser Bestes geben, um Anforderungen und Designdetails für jede Story zusammenzustellen, und in denen Diskussionen zu jeder Story länger als 45 Minuten dauern können.
Diese ganze Erfahrung lässt mich fragen, ob Scrum in der Praxis einfach nicht auf große Projekte skaliert.
Was kann ich als technischer Architekt noch tun, um das Projekt aus dieser bösartigen Todesspirale herauszuziehen, in der es sich befand? Wie kann ich dem Team helfen, an einen Punkt zu kommen, an dem wir eine Story in weniger als 10 Minuten präparieren, aufteilen und skalieren können?
Unser Scrum Master besteht darauf, dass wir das Meeting nicht beenden können, bis genügend Stories für den nächsten Sprint fertig sind, egal was passiert. Die meisten Geschichten sind einfach nicht fertig in Bezug auf die Anforderungen
Ihr Scrum Master macht seine Arbeit nicht und dies kann eine Diskussion sein, die Sie mit ihm führen müssen (taktvoll und privat), um zu sehen, ob er bereit ist, seinen Ansatz zu ändern.
Sprint-Planungssitzungen müssen zeitlich begrenzt sein, um genau dies zu verhindern. Niemand sollte beim Timeboxing dieser Meetings pedantischer sein als der Scrum Master.
Grundsätzlich unterstützt Sie hier die gesamte Dokumentation zu Scrum (zum Beispiel: http://www.scrumguides.org/scrum-guide.html#events-planning )
Die Sprintplanung ist auf maximal acht Stunden für einen einmonatigen Sprint begrenzt. Bei kürzeren Sprints ist die Veranstaltung normalerweise kürzer. Der Scrum Master stellt sicher, dass das Event stattfindet und dass die Teilnehmer seinen Zweck verstehen. Der Scrum Master bringt dem Scrum Team bei, die Time-Box einzuhalten.
Die Sitzungen dauern so lange, weil sie so lange dauern dürfen. Time-Box die Sitzung und das Team wird bald lernen, aufgrund der Notwendigkeit produktiver / weniger detailliert zu sein. Aus diesem Grund funktioniert Timeboxing – es macht Zeit zu einem nicht verhandelbaren Faktor, sodass andere Dinge verhandelt werden müssen (z. B. Diskussionstiefe, Definition der Bereitschaft, allgemeiner Pflegeprozess).
Möglicherweise benötigen Sie einen neuen Scrum Master, da Sie das Team beaufsichtigen, nicht Mentoren und Herausforderungen. Sie können auch versuchen, ihn von der Supervision zur Mentorschaft zu bewegen. Das wäre eine große Hilfe für Ihr Team.
Als technischer Architekt übernehmen Sie die Rolle des technischen Mentors und verbessern Ihr Team, um besser in der Softwareentwicklung zu sein. Sie können dies offiziell tun, indem Sie SM um Zeit bitten, oder inoffiziell, indem Sie herumgehen und sehen, wer Hilfe benötigt, und Hilfe: Programmieren von Paaren, kleine Diskussionen über Technologie und Architektur und Brown-Bag-Vorträge halten.
Die Planungsbesprechungen sind meist lang weil
Als Technischer Architekt kann man das erst durch Bildung abbauen. Wenn beim Planungsmeeting keine technischen Diskussionen mehr stattfinden, können sie sich auf die Domäne konzentrieren und werden mit der Zeit früher fertig.
Leider gibt es kein Schlangenöl für „eine Geschichte in weniger als 10 Minuten pflegen, schneiden und anpassen“. Es braucht Zeit, viel Mentoring-Aufwand, Managementunterstützung, Patienten und Team, die gleich bleiben. Unter der Annahme, dass diese vorhanden sind, und basierend auf meiner Erfahrung, können Sie nach 5-6 Sprints eine Verringerung der Planungsmeetingzeit feststellen.
Es sieht so aus, als hätten Sie viel über die Probleme und potenziellen Quellen nachgedacht, aber haben Sie darüber nachgedacht, alle zusammenzutrommeln und eine Ursachenanalyse durchzuführen? Angesichts Ihrer Informationen würde ich vermuten, dass selbst der erste Schritt, die aktuellen Probleme zu formulieren, viele interessante Gespräche hervorrufen und Ausrichtungsprobleme darüber aufdecken wird, was es bedeutet, agil zu sein, ob Sie wirklich den Scrum-Grundsätzen folgen usw.
Denkauge