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

Effizienz entsteht dadurch, dass man sich auf die im Sprint enthaltenen Aufgaben konzentrieren kann. Das ist nichts, was ein anderes Entwicklungsmodell umgehen kann. Aber Entwickler, denen "andere Aufgaben" zugewiesen werden, sind immer noch eine Realität, z. B. Support, Schulung oder technischer Vorverkauf.

Unterstützung ist für die meisten Orte von Natur aus nicht planbar. Schulungen und Vorverkäufe sind in der Regel zeitlich begrenzt, wie z. B. "Herr X verbringt N Tage mit dem Kunden".

Ich schlage vor, dass Sie versuchen, die Entwickler in zwei oder mehr Teams aufzuteilen. Verteilen Sie die Aufgabe, während dieses Sprint-Zyklus Unterstützung zu leisten, auf zwei Teams. Dieses Team sollte nur Aufgaben haben, deren Nichterfüllung man sich leisten kann. Es sollte sein Bestes tun, um Support-Probleme zu lösen, ohne die anderen Teams zu stören.

Wir haben damit gute Ergebnisse erzielt.

• Wissen wird verbreitet, wenn es etwas gibt, was das Support-Team nicht weiß, sammelt es Informationen von anderen Teams. Das Support-Team ist immer noch das Team, das auf die Support-Tickets antwortet und dabei lernt.
• Die Nicht-Support-Teams können viel konzentrierter an ihren Aufgaben arbeiten. Es ist sehr produktiv, nicht zwischen den Aufgaben wechseln zu müssen.
• Der tatsächliche Zeitaufwand für Unterstützung und ungeplante Ereignisse wird in Stunden angegeben.

Es klingt so, als ob das beschriebene Management nicht wirklich mit Scrum an Bord ist. Ich schlage sehr kurze Sprints vor, 1 Woche oder so. Wenn also ein Vertriebsmitarbeiter oder das Management Sie unterbrechen will, fragen Sie sie, ob sie warten können, bis der nächste Sprint ansteht, der weniger als eine Woche entfernt ist. Scrum sollte nicht etwas sein, was die Entwickler allein machen. Es muss in der gesamten Kette bis hin zum Kunden Anwendung finden.

Answer 2

Ich verstehe nicht, warum Scrum keine Teilzeitkräfte zulässt? Ich habe an vielen Scrum-Teams teilgenommen und wir haben fast immer eine Ressource, die nicht Vollzeit arbeitet. Oder wir haben eine Ressource, die zwischen mehreren Projekten aufgeteilt ist. Wir handhaben das so, dass der Entwickler dem Projekt eine bestimmte Zeit widmet und wir um diese zugeteilte Zeit herum planen. Die meisten agilen Projektmanagementlösungen ermöglichen diese Art der Ressourcenverwaltung.

Answer 3

Das ist in der Tat eine sehr gute Frage. Ich habe diese Aussage "alle Mitglieder müssen Vollzeit arbeiten" in fast jedem Papier, Artikel, Buch usw. gesehen. Ich habe rot über Scrum gelesen, aber ich habe noch kein Argument gesehen, warum das so sein muss. In großen Organisationen würde ich erwarten, dass es Entwickler gibt, die nichts anderes tun, aber in kleinen Organisationen muss es sehr häufig vorkommen, dass es Entwickler gibt, die sich nicht zu 100% für den Sprint engagieren können, und Scrum ist für kleine Teams konzipiert! Der Fokus-Faktor sollte in der Lage sein, damit umzugehen, wie mit allem anderen auch.

Answer 4

Bei meiner Arbeit wurden Entwickler aus dem Projekt abgezogen, z. B. wegen Supportanfragen oder weil der Teamleiter Besprechungen über andere Projekte abhält, so dass es manchmal vorkommt, dass jemand sagt: "Nicht am Projekt beteiligt", so dass kommuniziert wird, dass diese Person derzeit nicht zum Sprint beiträgt.