Guter Ansatz, um verschiedene Projektgeschichten in denselben Sprints zu gruppieren

Nachdem ich bei mehreren Gelegenheiten so gearbeitet habe, mit einem einzigen Team, das an mehreren Projekten gleichzeitig gearbeitet hat, habe ich zahlreiche Gründe identifiziert, dies nicht zu tun, und überhaupt keine, so zu arbeiten.

Letztendlich wird es das Team belasten oder zerbrechen, die Motivation schwächen, die Produktivität verringern und Sie mit zwei gescheiterten Projekten zurücklassen.

Verschiedene Unternehmen haben dies auf unterschiedliche Weise versucht, aber keine davon hat am Ende wirklich geklappt.

Wir haben versucht, Probleme aus zwei Rückständen mit dem gesamten Team anzugehen. Die Hauptnachteile waren der ständige Wechsel zwischen Kontext, der einen enormen Overhead verursachte, und die unvermeidlichen Kämpfe mit dem PO darüber, welche Projektgeschichten fallen gelassen werden mussten, wenn wir den Sprint nicht schaffen würden. Zuerst ein Projekt und danach das zweite zu machen, machte die Kämpfe noch intensiver; Das Erstellen einer Geschichte von jedem machte sie häufiger, da die Overhead-Geschwindigkeit verringert wurde.

Wir haben auch versucht, einige Leute primär an einem Projekt zu beauftragen, einige Leute an dem anderen und einige gemeinsam, mit der Idee, dass beide Seiten helfen würden, wenn das eine oder andere Projekt ins Rutschen käme. Dieser zerbrach das gesamte Team innerhalb von Wochen, wobei jede Seite nur noch an einem einzigen Projekt arbeitete und sich nicht mehr wirklich um die andere kümmerte, den Überblick über das Fachwissen und den Fortschritt verlor, die für das andere Projekt erforderlich waren, und sich dann nur noch darüber ärgerte, mitmachen zu müssen Treffen für ein Projekt, an dem sie nicht beteiligt waren. Das Team wurde im Grunde genommen in zwei Teams aufgeteilt, eines für jedes Projekt, aber das verursachte viel Ärger und Produktivitätsverluste.

Dann haben wir auch versucht, an einem Projekt für einen Sprint zu arbeiten, dann das andere Projekt für einen Sprint usw. Das hat einigermaßen funktioniert . Es hat weniger Probleme des ersten Ansatzes, da sich jedes Projekt in einer klaren Timebox befindet, aber es kostet Sie viel Flexibilität, wenn etwas Wichtiges in Projekt A passiert, Sie aber gerade einen Sprint für Projekt B gestartet haben, und dann Sie mit dem gleichen Prioritätskampf enden.

Mein bester Rat: Tu es nicht. Eine Person, ein Team, ein Projekt, ein Ziel. Alles andere wird Sie tonnenweise Moral und Produktivität kosten, ohne Gewinn. Pflichtlektüre.

Fragen Sie sich als letzte Anmerkung auch, warum Sie dies tun möchten. Es gibt buchstäblich keinen Grund, dies jemals in Betracht zu ziehen; Sie können einfach beide Projekte in Serie machen. Schließen Sie Projekt A ab und dann B, sobald A fertig ist; Wenn Sie beide erfolgreich parallel abschließen konnten, werden Sie sie immer schneller in Serie abschließen können. Alle Gründe, beides gleichzeitig zu beginnen, liegen wahrscheinlich darin, dass Sie sich bereits eingestehen, dass Sie bei beiden Projekten sowieso scheitern werden, und versuchen, den Schaden zu mindern, indem Sie zum Stichtag etwas vorweisen können , um die Leute davon zu überzeugen, dass Sie mehr Zeit brauchen /Geld, ohne dass sie es herausziehen. Investieren Sie Ihre Zeit in die Behebung dieses Problems und überlassen Sie es Ihren Mitarbeitern, sich auf eine Sache nach der anderen zu konzentrieren. So arbeiten sie am besten.

Sie können mehrere Projekte haben. Sie können mehrere Teams haben. Aber:

• Eine Person kann nur in genau einem Team sein ⁽¹⁾
• Ein Scrum Master ist pro Team , nicht pro Projekt.

Mit diesen Einschränkungen wird Ihr Plan so oder so nicht funktionieren. Am besten bildet man ein Team, stellt beide Projekte ins Backlog und bearbeitet sie. Sie können Arbeitselemente aus mehreren verschiedenen Projekten in einen Sprint ziehen, so wie Sie es gesagt haben. Aber Sie werden einen Scrum Master und einen Product Owner haben.

Alternativ, wenn Sie zwei Teams wollen, bilden Sie zwei Teams, zwei Scrum Master, zwei Product Owner und zwei Backlogs.

⁽¹⁾ (Meine Erfahrung sagt mir, dass jeder Weg, diese Regel zu umgehen, fehlschlagen wird, weil es weder Fokus noch Engagement geben kann , zwei der fünf Kernwerte, wenn jemand in mehreren Teams ist).

Das ist eine schreckliche Idee

• Es gibt nur einen Scrum Master pro Team. Der Scrum Master ist nicht an das Projekt gebunden, da er kein Projektmanager ist. Ihr Setup deutet darauf hin, dass Ihr Unternehmen Scrum oder die darunter arbeitenden Personen nicht versteht oder respektiert.
• Es hat keinen Vorteil, solche Projekte zu mischen. Dies ist eindeutig nur das Management, das willkürliche Fristen ohne Rücksicht auf die Praktikabilität drückt. Es gibt keinen Grund, warum irgendjemand vorschlagen sollte, Projekt A richtig zu machen und dann Projekt B richtig zu machen, es sei denn, er versucht, die Entwickler dazu zu bringen, mehr Arbeit zu leisten, als machbar ist.
• Das Wechseln zwischen Jobs ist unwirksam. Menschen brauchen Zeit, um sich zurechtzufinden, wenn sie etwas Neues beginnen. Dies gilt umso mehr, wenn zwischen völlig unterschiedlichen Projekten gewechselt wird.
• Wenn Sie den vorherigen Punkt umgehen, indem Sie das Team aufteilen, sind Sie immer noch nicht besser dran, da Sie viele Synergien des Teams verlieren, indem Sie es an verschiedenen Projekten arbeiten lassen.
• Konflikte sind vorprogrammiert, sobald Sie die Projekte mischen. Was ist eine „faire“ Aufteilung der Sprintkapazität? Welche Aufgaben haben Priorität, wenn Sie nicht alles erledigen können? Projekt A wird auf mehr Aufmerksamkeit drängen, um es zu erledigen. Projekt B wird zurückdrängen. Es wird nichts als Drama sein.
• Sie haben keine Garantie, dass Sie mit Projekt A zum geschätzten Datum fertig sind. Was wirst du dann tun? Schneide es ab? Wenn Ihre Manager dazu bereit wären, könnten Sie diese Frist genauso gut um einen Monat nach oben verschieben und diese Vermischung vermeiden. Werden Sie weiterhin parallel laufen? Für wie lange? Denn das wird Projekt B verzögern und jemand auf der Leiter wird darüber nicht glücklich sein.

Dies ist ein Lehrbuch -Double-Bind- Szenario.

Vorteile, Geschichten aus mehreren Projekten in jedem Sprint zu haben:

• Sie werden Fortschritte in mehr als einem Projekt sehen
• Die Entwickler dürfen sich an der Abwechslung erfreuen

Nachteile:

• Kontextwechsel sind teuer und reduzieren die Leistung Ihres Teams
• Sie verlieren die Klarheit, sich nur auf ein Projekt konzentrieren zu müssen, was auch die Produktivität beeinträchtigen kann
• Schwieriger ist es oft, die relativen Prioritäten für Aufgaben aus verschiedenen Projekten zu definieren

Meiner Erfahrung nach ist der häufigste Grund für mehrere Projekte in jedem Sprint, dass die Organisation nicht in der Lage (oder nicht willens) ist, Prioritäten zu setzen, und sie den Produktivitätsverlust, der durch Multitasking entsteht, nicht zu schätzen weiß.

aber Sie haben mehrere Scrum Master (einen pro Projekt) und ein Team

Dann machen Sie kein Scrum und sollten sie nicht wirklich Scrum Master nennen. Einer der Gründe für die Existenz von Scrum ist, dass erkannt wurde, dass die Konsistenz der Teammitglieder einem Team wirklich hilft, effektiv zu arbeiten. Wenn ein Team zusammenarbeitet, lernen sie, sich an die Stärken und Schwächen des anderen anzupassen. Wenn Sie Teammitglieder wechseln (insbesondere eine Schlüsselrolle wie der Scrum Master), wird Ihre Produktivität sinken.