Die Erwartungen (insbesondere) an das neu formierte Scrum-Team sind hoch. Die Methodik ist für viele Unternehmen noch neu, und wenn sie endlich den Mut haben, umzusteigen, erwarten sie viel von der Umstellung.
Es ist sehr einfach für die Scrum-Team sein Versprechen nicht einzuhalten, und das Scheitern kann viele Varianten haben, die alle gleichermaßen möglich sind 😀.
Nun, dieser Artikel wird nicht auf Scrum-Prozesse als solche eingehen. Vielmehr möchte ich mich auf das ultimative Ziel (jedes) Teams konzentrieren – das zu liefern, was vereinbart wurde, pünktlich und in Qualität. Und in diesem Fall liegt der Fokus auf eher technischen Aktivitäten innerhalb des Teams, die zu erfolglosen Sprints führen können, und was ein effektiver Weg sein könnte, damit umzugehen.
Jetzt werden wir technische Details besprechen, die Ihren Sprint ruinieren können, und wie Sie sie beheben können.
Backlog Generation Without a Solid Roadmap Target
Abhängig von der technischen Schwierigkeit des Lieferinhalts und davon, wie weit der Inhalt des Sprints vom vollständigen Verständnis der Themen durch den Kunden entfernt ist, können Rückstände eines der ersten Probleme sein, die das Team treffen. Dies erfordert schwerwiegende Komplikationen wie:
- Geschichten können fast zufällig generiert werden und nicht, indem sie einer logischen Linie folgen, basierend auf aktuellen Flash-Ideen von jemandem, der hierarchisch wichtig ist, anstatt auf einem chronologischen Plan.
- Dann wird das Scrum-Team, kurz davor, die Konsistenz zu retten, seine eigenen Geschichten hinzufügen, um die bereits gegebenen zu ergänzen. Das Ergebnis werden aber letztendlich mehrere große Themen parallel im Backlog sein.
- Da die Bedürfnisse der Kunden immer im Vordergrund stehen, werden einige der wichtigen, aber zu technischen Geschichten verschoben, um die vom Kunden gewünschte Funktionalität zu liefern.
- Das Team wird dann versuchen, zu liefern, aber das unvermeidliche Ergebnis ist die Bereitstellung von Sprint-Inhalten, die sich unvollständig (oder sogar fehlerhaft) anfühlt, und die technische Verschuldung wächst (was dazu führt, dass weitere Geschichten in den Rückstand geraten).
Geben Sie ihm ein paar Sprintzyklen, und das Problem wird sich exponentiell zu einer Situation entwickeln, in der es nicht mehr wichtig ist, was im Rückstand ist, weil es klar ist, dass der Inhalt, der niedrig genug sitzt, niemals gelöst werden wird. Es wird keine Zeit bleiben, die Geschichten auszuwählen; In jedem Sprint wird eine Reihe neuer Geschichten generiert (und hat eine höhere Priorität).
So beheben Sie die Backlog-Generierung
Hier eine Lösung anzugehen und die Partner von einer Veränderung zu überzeugen, ist besonders schwierig, da hier die Organisationshierarchie einen erheblichen Einfluss hat.
Es müssen jedoch bestimmte Maßnahmen eingeleitet werden, und selbst wenn sie nicht sofort genehmigt werden, kann es im Laufe der Zeit zum Erfolg führen, sie regelmäßig daran zu erinnern und sie in einen Zusammenhang damit zu bringen, wie die Situation im Rückstand jetzt aussieht und wie sie sein könnte:
# 1. Fragen Sie nach konkreten Roadmap-Zielen für das Team
Dies sollte sowohl kurz- als auch langfristig erfolgen. Machen Sie deutlich, welche Funktionen in den nächsten Monaten erledigt werden müssen und wie das Produkt ein Jahr später aussehen soll. Eine klare Vision sollte gründlich demonstriert und mit spezifischen Roadmap-Zielen gepaart werden.
# 2. Fordern Sie die Priorisierung der Features auf der Timeline heraus
Es sollte nie passieren, dass das Team gleichzeitig zwischen mehreren Storys mit hoher Priorität und hoher Komplexität balanciert. Dies wird nur zu langsamen Fortschritten in allem führen, anstatt erhebliche schrittweise Fortschritte in großen Themen zu demonstrieren.
# 3. Besuchen Sie die alten Geschichten regelmäßig
Die alten Geschichten noch einmal durchgehen und sich bestätigen lassen, ob sie tatsächlich noch gültig sind und welche Priorität diese haben. Ordnen Sie sie bestimmten Roadmap-Zielen zu, wenn sie noch gültig sind. Vermeiden Sie nicht zugeordnete Stories im Backlog – das ist ein Zeichen dafür, dass diese Stories keinen eindeutigen Geschäftswert haben oder die Priorität über sie im Laufe der Zeit verloren gegangen ist.
Technical Debt Postponement
Technische Schuld ist ein Zustand des Codes (oder seiner Teile) in der entwickelten Software, der als Nebeneffekt entsteht, wenn der Geschwindigkeit der Lieferung Vorrang vor der Qualität eingeräumt wird. Manchmal ist die Veröffentlichung neuer Funktionen innerhalb eines Sprints ein dringendes Thema, sodass das Team möglicherweise beschließt, die Stories nicht perfekt fertigzustellen.
Auf diese Weise erfüllt es jedoch immer noch die Hauptanforderung der Funktionalität von der Geschäftsseite. Wenn es nicht richtig und rechtzeitig identifiziert wird, kann es unterwegs sogar vergessen und erst wiederentdeckt werden, wenn in späteren Phasen des Projekts auf Probleme gestoßen wird.
Das Team selbst ist am besten in der Lage, Geschichten für die technischen Schulden zu definieren, die auf diesem Weg entstanden sind. Leider werden solche Geschichten oft am Ende der Prioritätenliste platziert, entweder vom Kunden oder vom Product Owner.
Die Anhäufung technischer Schulden ist ein ernsthaftes Problem für das Scrum-Team. Es fängt klein an, wächst aber mit der Zeit exponentiell:
- Neue Geschichten beginnen, von unvollendeten Themen aus der Vergangenheit beeinflusst zu werden.
- Die Behebung eines neuen Fehlers in einem System mit hoher technischer Verschuldung führt oft zu sehr komplexen Lösungen, da zur Behebung des neuen Fehlers mehrere andere Probleme behoben werden müssen, um die Verarbeitung in die Phase zu bringen, in der die Behebung vorgenommen werden kann.
- Die Frustration des Entwicklungsteams wächst, wenn es sieht, wie schwieriger es ist, neue Funktionen in ein System voller ungelöster technischer Probleme zu implementieren, die die neue Funktionserweiterung unnötig erschweren.
So beheben Sie den technischen Schuldenaufschub
Konsistenz ist hier der Schlüssel. Jedes Scrum-Team muss einen für seinen Anwendungsfall geeigneten Prozess entwickeln und sich daran halten, egal was passiert. Der fragliche Prozess kann ähnlich sein wie:
Machen Sie eine Regel, wo mindestens 1 oder 2 Geschichten werden abgeholt aus dem technischen Schuldenstau.
Reservieren Sie einen Prozentsatz aus dem Sprint, der nur technischen schuldenbezogenen Aufgaben gewidmet ist. Dies kann jedoch schwierig sein, da es sehr schwierig ist, ein solches Engagement zu verfolgen. Wenn Sie diesen Weg gehen, ist es wahrscheinlich besser, einen konkreten Tag im Sprint zu definieren, der nur den technischen Schuldenaktivitäten gewidmet ist.
Define jeder 5. Sprint oder so, um technische Schulden aufzuholen Geschichten. Füllen Sie in diesem Sprint so viele relevante technische Schuldeninhalte wie möglich aus. Wenn es im Laufe der Zeit der Fall sein sollte, dass es im Moment nicht genügend technische Schuldgeschichten gibt, an denen gearbeitet werden kann, vervollständigen Sie den Rest dieser Sprint-Kapazität mit neuen Funktionsinhalten. In jedem Fall soll dieser konkrete Sprint in erster Linie Tech Debt Stories vorbehalten sein.
Too Flexible Sprint Content Change Before End of the Sprint
Scrum-Teams sollen flexibel und veränderungsbereit sein, wie es schon aus dem unmittelbar impliziert Agiles Manifest, von dem erwartet wird, dass es der Kern jedes Scrum-Teams ist.
Aber stellen Sie sich eine Situation vor, in der sich der Sprintinhalt alle 2-3 Tage ändert:
- Geschichten werden neu priorisiert, neue Geschichten kommen in den Sprint und andere Geschichten kommen selten heraus.
- Der Inhalt ändert sich nicht nur, sondern nimmt im Laufe der Sprint-Periode auch zu.
- Eine Änderung der Priorität führt zu einem demotivierten Team, da es dann von einem Thema zum anderen springen muss, was den Stress erhöht und am Ende dazu führt, dass Inhalte nicht geliefert werden. Nicht nur für Stories, die während der Sprintplanung als Teil des Sprints vereinbart wurden, sondern oft auch die neu hinzugefügten Stories.
Es wäre großartig, wenn wir dem Scrum-Team einfach die Freiheit geben könnten und dann beobachten könnten, wie die Stories fertig werden, trotz aller Änderungen, die während des Sprints auf das Team zukommen. Die Erfahrung zeigt, dass dies nicht funktionieren wird. Das Team wird von den Inhalten abgelenkt und überwältigt; Im Laufe der Zeit wird die Sprintverpflichtung nichts bedeuten.
Es wird zum Standard für das Team, Stories nicht innerhalb des Sprints abzuschließen; ebenso wird es zum Standard werden, Stories als direkte Konsequenz von Sprint zu Sprint zu übertragen.
Der Kunde wird sich dann darüber beschweren, dass es keine Zusicherung gibt, dass die in einen Sprint eingefügten Stories innerhalb dieses Sprints geliefert werden. Die Planung für Features und Roadmap-Ziele ist deaktiviert.
So beheben Sie die Flexibilität der Sprints
Ich glaube, dass das Opfern einer Art von Freiheit für ein paar Prozesse, die die Flexibilität der Sprints einschränken, die Zuverlässigkeit der Sprint-Lieferung erheblich erhöhen wird. Ein solcher Prozess würde Schritte umfassen wie:
- Lassen Sie kein unorganisiertes Hinzufügen neuer Storys in den bestehenden Sprint zu. Führen Sie einen Überprüfungsprozess ein, auch wenn dieser sehr einfach ist, aber einen Bestätigungspunkt dafür, dass die neue Story relevant ist und eine höhere Priorität hat als alles andere, was sich bereits im Sprint befindet.
- Entfernen Sie für jede neue Story, die dem Sprint hinzugefügt wird, eine entsprechend komplexe Story aus dem Sprint. Idealerweise soll es eine Story sein, die im Sprint noch nicht oder erst vor kurzem begonnen wurde.
- Fügen Sie im Sprint entdeckte Ad-hoc-Bugs nicht automatisch zum Sprint-Backlog hinzu. Das sind neue Geschichten, die für die spezifische Sprint-Inklusion geschätzt und geplant werden müssen.
Insufficiently Defined Stories Leave Too Many Open Items
Sie definieren also die Storys für den nächsten Sprint, das Team geht die Klärung und Verfeinerung, Schätzung und Aufgabenverteilung durch, und alles ist bereit für eine klare Entwicklung, oder? Nun, nicht mit unklaren Geschichten, die in den Sprints auftauchen.
Selbst wenn die Geschichten verfeinert sind, wird sich das Team auf irgendeine Art von Schätzungen einigen, auch wenn niemand Unklarheiten mit den Geschichten kommuniziert. Schlecht definierte Stories können leicht identifiziert werden, sodass das Team immer wieder zurückkehrt, um die Stories innerhalb des Sprints zu diskutieren.
Dies verlängert nicht nur natürlich die Verfeinerungszeit des Teams, sondern führt auch zu weiteren Änderungen des Umfangs, nachdem die Schätzungen für den Sprint vorgenommen und die Inhalte für den Sprint vom Team festgelegt wurden.
Folglich werden die Geschichten größer und komplexer als zunächst angenommen. Auch die eigentliche Entwicklungsarbeit an einer solchen Story wird schon wegen des vielen zusätzlichen Klärungsbedarfs viel später als zu Beginn des Sprints beginnen.
In den meisten Fällen führt dies letztendlich zu einer unvollendeten Geschichte im Sprint.
So beheben Sie eine unvollendete Story im Sprint
Wenn dem Team zu viele unklare Geschichten serviert werden, wird es mit der Zeit unüberschaubar Projektmanagement kann mich nur wundern, warum jeder Sprint mit unvollendeten Geschichten endet.
Dies kann ein komplexes Problem sein, das behoben werden muss. Es kommt vor allem darauf an, wie weit der Product Owner mit seinem Wissen vom Entwicklungsteam ist und ob er die Bedürfnisse des Teams bezüglich der klaren Definition der Stories verstehen kann.
Häufig sind Product Owner stark funktional orientierte Personen und ihre Verbindung zum Entwicklungsteam ist oberflächlich. In anderen Fällen wird die Rolle des Product Owners mit der Rolle des Business Analysten kombiniert, was zu noch mehr Verwirrung führt. Was also tun in diesem Fall?
Planen Sie monatliche Anrufe B. zur Story-Vorbereitung, wo die noch in die Sprints einzuführenden Features vorab intensiv besprochen werden sollen. Eine klare Roadmap ist die ultimative Voraussetzung dafür, dass dies gelingt.
Bereiten Sie Analyseseiten vor für solche komplexen Storys rechtzeitig (bevor die Storys in Sprints platziert werden), damit Product Owner auf einfache Weise inhaltsreiche Storys für Entwicklungsteams definieren können.
In sehr komplexen Fällen ist dies eine gute Möglichkeit Zeit für die Designvorbereitung einplanen bevor das Thema das Scrum-Team erreicht. Spezielle KMU aus dem Team werden dieser Aktivität gewidmet.
Lassen Sie die unvorbereitete Geschichte auf keinen Fall zu einem Sprint werden. Bestehen Sie auf der inhaltlichen Vervollständigung. Dadurch entsteht zusätzlicher positiver Druck auf die relevanten Stakeholder, die Stories besser für das Team aufzubereiten.
Final Words
Sich auf den guten Inhalt jeder Geschichte zu konzentrieren, zahlt sich im Laufe der Zeit sehr aus. Das Backlog-Management ist für die meisten Scrum-Teams ein undefiniertes Gebiet. Geschichten auf konkrete Ziele abzubilden und sie in den Kontext von übergeordneten Zielen zu stellen, ist eine unterschätzte Aktivität.
Diese Liste soll etwas Licht in diese technischen Details bringen und hoffentlich bei der Orientierung helfen, wenn einige der oben genannten Probleme bekannt sind.
Als nächstes sehen Sie sich die besten an Scrum-Tools für ein Startup bis zu einem mittelständischen Unternehmen.
