Scrum: eine gute Methode nur für Teams mit Entwicklern, die "Vollzeit an Sprints" arbeiten?

Question

Wir sind ein Softwareentwicklungsunternehmen. Wir haben Scrum eingeführt.
Das Problem ist, dass die Entwickler nicht wie in vielen anderen Unternehmen die gesamte Zeit für Scrum-Sprints aufwenden können. Sie müssen viele entwicklungsfreie Aufgaben außerhalb des SCRUM-Projekts erledigen!
Ich habe gelesen, dass : Scrum keine Teilzeitentwickler zulässt

Welche Erfahrungen haben Sie diesbezüglich gemacht?
Ist Scrum eine gute Methode nur für Teams mit Entwicklern, die ihre Zeit nur mit Entwicklungsaufgaben verbringen, die sich auf die SCRUM-Sprints konzentrieren?

Vielen Dank für Ihre Zeit

Answer 1

Ich arbeite in einem Unternehmen, in dem dies ebenfalls ein Thema ist. Wir versuchen, Scrum zu verwenden, haben aber Probleme mit den folgenden Punkten:

• Wenn es ein wichtiges Support-Problem gibt, müssen wir alles, was wir tun, um dieses Problem zu lösen, fallen lassen und ruinieren damit den Sprint.
• Die Geschäftsleitung wendet sich direkt an einige Entwickler mit bestimmten Aufgaben, die sie erledigt haben möchte.
• Einige Entwickler haben bestimmte Aufgaben, die sie von Zeit zu Zeit erledigen müssen (z. B. Support für bestimmte alte Produkte).
• Manchmal wird einer der Entwickler aus dem Sprint genommen, um eine wichtige Installation durchzuführen.
• Die Teams haben oft gewechselt, je nach den Verbesserungsvorschlägen des Managements.

Angesichts all dieser Probleme ist es unmöglich, Scrum nach Vorschrift durchzuführen. Die Geschwindigkeit für jeden Sprint ist im Grunde wertlos, wenn sich die Anzahl der Personen im Team ständig ändert.

Dennoch habe ich festgestellt, dass man einige Vorteile daraus ziehen kann:

• Die Menschen arbeiten im Team und werden dadurch inspiriert und gestärkt.
• Die Aufgaben, die den Sprint noch durchlaufen, sind besser, als wenn Scrum/Sprinting überhaupt nicht verwendet wird, da der Feedback-Zyklus so viel kürzer ist als ohne Sprints. Man ist sich jetzt einig, dass zwei Wochen eine gute Zeit sind.
• Im Laufe der Zeit scheint sich die Geschwindigkeit schließlich zu nivellieren, so dass das Management zumindest eine Vorstellung davon hat, wie viel Arbeit über einen längeren Zeitraum hinweg erledigt werden kann.

Mein Vorschlag ist daher, Scrum zu verwenden. Wenn das Management und die Entwickler in meinem Unternehmen die Vorteile kurzer Zyklen usw. erkennen, werden sie Änderungen vornehmen, so dass mehr Arbeiten, die nicht als Sprint-Aufgaben gelten, doch zu Sprint-Aufgaben gemacht werden. Ich sehe also immer noch Vorteile darin, Scrum zu versuchen. Es gibt ohnehin keinen 100%ig korrekten Weg, Scrum zu praktizieren, auch wenn manche Bücher das noch so sehr behaupten.

Answer 2

Definieren Sie eine Schwerpunktfaktor das Verhältnis der Zeit, in der jeder Entwickler nur an den Sprint-Inhalten arbeiten kann. Dieser Fokusfaktor berücksichtigt die Zeit, in der Sie nicht an den Sprint-Inhalten arbeiten können (E-Mail, Support, Meetings ...).

Planen Sie bei der Sprint-Planung nur das, was nach diesem Fokusfaktor erreicht werden kann: Wenn das Team 600 Stunden bei 80 % hat, planen Sie nur 480 Stunden.

Der Ausgangswert kann willkürlich festgelegt werden oder auf der Grundlage der im vorangegangenen Sprint erzielten Ergebnisse: 60 Tage geplant und 45 Tage abgeschlossen ergibt einen Fokusfaktor von 75%.

Wenn die Nicht-Scrum-Aufgaben keine Unterbrechung darstellen, ist es besser, sie zur gleichen Zeit zu erledigen (z.B. am Freitag arbeiten alle Teammitglieder an diesen anderen Aufgaben, nicht an den Sprint-Aufgaben).

Dieser Fokusfaktor muss nicht für jedes Teammitglied identisch sein. Dies ermöglicht auch die Aufnahme von Teilzeitmitgliedern in ein Team.

Answer 3

In unserem Team haben wir Support-Aufgaben in den Sprint integriert. Für jeden Sprint nehmen wir eine Schätzung vor, wie viel Zeit für die Unterstützung jedes der Produkte voraussichtlich benötigt wird, und fügen diese als Aufgaben in den Sprint ein. Auf diese Weise wird der Sprint nicht beeinträchtigt, es sei denn, der Supportbedarf ist viel höher als erwartet (was sich natürlich auf die für den Support reservierte Zeit in den kommenden Sprints auswirken kann).

Answer 4

Es gibt viele Ansätze für Scrum, ehrlich gesagt habe ich noch kein einziges Unternehmen gesehen, das "reines" Scrum macht. Wenn Sie in der Lage sind, Ihr Scrum gut zu organisieren, können Sie davon profitieren. Aber Sie sollten sich überlegen, warum Sie Ihren Prozess auf Scrum umstellen wollen, vielleicht ist es sinnlos.

Ich denke, Sie sollten Scrum ausprobieren und sehen, ob es sich gelohnt hat.

Answer 5

Ich habe zwar nicht die größte Erfahrung mit SCRUM, aber die allgemeine Regel ist, dass, wenn SCRUM nicht so gut funktioniert, wie es sollte, es in der Regel daran liegt, dass der Sprint zu fokussiert ist und das Team viele Aufgaben hat, die über den Sprint hinausgehen und nicht berücksichtigt werden. Diese Aufgaben werden dann vom Team innerhalb des Scrums als lästig empfunden und das Scrum wird von den Außenstehenden als lästig empfunden.

Wir haben SCRUM noch nicht in Gänze ausprobiert, aber ich habe hier einige Erfahrungen mit verschiedenen Möglichkeiten der Umsetzung gemacht, und die besten Ergebnisse wurden erzielt, wenn das Team Mitarbeiter aus vielen Abteilungen umfasste (Test, QA, Implementierung, Entwicklung, Architektur, Marketing). Das bedeutet, dass diese Personen nicht Vollzeit im Team sind, aber die Tatsache, dass ihnen Aufgaben im Rahmen des aktuellen Projekts zugewiesen werden, bedeutet, dass sie in der Regel eher bereit sind, die Zeit dafür aufzuwenden.

Der nächste große Vorteil ist, dass es möglich ist, einen gewissen Zeitpuffer für Unbekanntes, wie z. B. eine ungewollte, aber kritische Unterstützungsleistung, einzuplanen. Wenn diese auftreten, wird ein kleineres Team gebildet, das sich vorübergehend vom Haupt-Scrum abspaltet, um das Problem zu lösen.

Schließlich sind Dinge wie Installationen, Konfigurationen usw. Teil des Scrums und werden als solche mit ihm abgeglichen.

Ein weiterer Ansatz, den ich als Nächstes ausprobieren werde, besteht darin, die Idee so zu erweitern, dass ich anstelle des Ansatzes "ein Scrum für alle" kleinere Teams für jeden spezifischen Bedarf einrichten werde. Das Hauptproblem dabei ist, dass nicht viele Leute die Rolle des Scrum-Masters übernehmen können, also ist es im Moment eher eine Frage von Huhn und Ei.

Ganz allgemein habe ich hier SCRUM verwendet, aber ich halte mich nie an die Regeln. Ich betrachte diese Techniken und Ansätze als Ideenfundus, aus dem ich schöpfen und mit dem ich experimentieren kann, um die bestmögliche Lösung für unsere Bedürfnisse zu finden. Damit dieses Experimentieren funktioniert, muss man manchmal subversiv vorgehen (man macht Scrum, aber man formalisiert nicht, dass man es macht). Ich finde, dass dies der beste Weg ist, um sie für neue Ansätze zu gewinnen und den inhärenten Widerstand gegen Veränderungen, mit dem wir immer konfrontiert werden, zu überwinden.

Auf diese Weise entwickelt sich der Arbeitsablauf auf natürliche Weise in Richtung Scrum-XP-agile-TDD und bringt sie langsam dazu, die schreckliche Kaskade, in die sie so verstrickt sind, zu vermeiden. Mit der Zeit werden sie hoffentlich erkennen, dass das Gras auf meiner Seite des Zauns viel grüner ist :-)