Scrum-Ressourcenschwierigkeiten

Bei der Einführung einiger Scrummaging-Praktiken bin ich auf einige interessante Probleme gestoßen. Ein Problem, mit dem ich konfrontiert wurde, hatte mit der Leerlaufzeit der Projektmitglieder zu tun. Das Unternehmen, für das ich derzeit arbeite, führt seine Projekte nach dem Wasserfallprinzip durch. Die Struktur des Unternehmens unterstützt den Wasserfall, die Arbeitsweise der einzelnen Abteilungen, ihre geografischen Standorte, die strikte Trennung der Rollen usw. sind alle für die 'Über-die-Wand-werfen'-Kultur optimiert. Nach einigen Evangelisationen konnten einige Manager davon überzeugt werden, Scrum in ihren Projekten auszuprobieren. Die Projekte hatten vor etwa einem Jahr begonnen, aber in diesem Jahr hatten sie an Architektur- und Anforderungsdokumenten gearbeitet. Bis jetzt war also alles wasserfallorientiert. Die Finanzierung stand fest, die Funktionalität war festgelegt, das Veröffentlichungsdatum war festgelegt usw. Jetzt, da wir die Architektur und die Anforderungen hatten, mussten wir 'nur' noch das System bauen. Als wir mit der eigentlichen Implementierung von Scrum begannen, suchten wir als erstes nach Projektmitgliedern. Wir stellten Tester, Designer, Entwickler, Integrationsspezialisten usw. ein. Da das Projekt verschiedene Technologien verwendet, mussten wir Entwickler, Designer, Tester usw. für Technologie X und andere Entwickler, Designer usw. für Technologien Y, Z usw. finden. Als ich damit konfrontiert wurde, wurde mir klar, dass es keine leichte Aufgabe sein würde, Teams zu bilden, in denen die Leute die Arbeit der anderen übernehmen oder sich sogar gegenseitig helfen können. Am Ende hatten wir drei Scrum-Teams. Jedes ist ein funktionsübergreifendes Team, das sich auf eine bestimmte Technologie spezialisiert hat. Das ist nicht ideal, ich hätte gerne technologieübergreifende Teams gehabt, aber das war das Beste, was wir bekommen konnten. Wir haben die Teams so oft wie möglich zusammengesetzt. Wir haben unserem PO geholfen, ein Product Backlog zu erstellen, haben unsere Schätzungen und Sprint-Planungsmeetings durchgeführt und waren bereit, loszulegen...... Bei einem der ersten Stand-ups: Team: Wir können nichts testen!, Scrummaster: Warum können Sie nicht testen? Team: Nun, wir haben keine Testumgebung eingerichtet. Wir haben 'sie' um eine solche gebeten und sie arbeiten jetzt an einem Angebot. Sie werden es uns innerhalb von zwei Wochen zukommen lassen. Sobald wir ihr Angebot akzeptieren und unterschreiben, dauert es noch ein paar Wochen, bis sie die Hardware einrichten, konfigurieren usw!!!!! Oeps, das Team hat in drei Wochen eine Demo! Scrummaster: Ok, was können wir tun? Team: Wir können in unseren Entwicklungsumgebungen testen und demonstrieren! Die Teams sind startklar..... Team: Wir können unsere Funktionalität nicht vollständig entwickeln!, Scrumaster: Warum können Sie nicht entwickeln? Team: Nun, wir haben nicht die richtigen Berechtigungen für die Anwendung, die Datenbanken usw., also können wir auch nichts entwickeln. Wir haben 'sie' um die Berechtigungen gebeten. Sie sagten, das sei in zwei Wochen erledigt. Oeps, das Team hat in drei Wochen eine Demo! Scrumaster: Ok, was können wir tun? usw. usw. Diese Art von Problemen gab es zuhauf. Um diese Probleme zu lösen, verließen sich die Teams vollständig auf andere Abteilungen.Da das Unternehmen wasserfallorientiert ist, waren diese Verzögerungen bisher kein Problem. Wenn die Architektur und die High-Level-Anforderungsdokumente 'fertig' sind, fordern Sieein paar Anforderungsanalysten, um die Anforderungen zu vertiefen. Dann entlassen Sie diese von Ihrer Gehaltsliste und stellen ein paar Designer usw. ein. Gleichzeitig beantragen Sie die Hardware, Genehmigungen usw. Bis die Anforderungs- und Designphase abgeschlossen ist, ist genug Zeit vergangen und die anderen Abteilungen hatten genug Zeit, die für das Projekt benötigten Dinge bereitzustellen. Zu dem Zeitpunkt, an dem Sie mit der eigentlichen Softwareentwicklung beginnen, sind alle infrastrukturellen Fragen usw. geklärt. Und die ganze Zeit über hatte das Projekt nur eine kleine Anzahl von Mitarbeitern. Eines der Projekte scheiterte wegen dieser Probleme drei Mal hintereinander. Das andere Projekt hatte während der ersten beiden Sprints viel Leerlauf, schloss sie aber erfolgreich ab. Bei beiden Projekten sind die Manager der Meinung, dass zum Teil dank dieses Scrum-Ansatzes eine Menge Geld verschwendet wurde. Das ist kein guter Start, wenn man sich in den ersten Schritten der Scrum-Einführung befindet. Sie brauchen den Erfolg, damit Sie bei einem nächsten Projekt mehr Scrum in der Organisation einführen können!!! Die Lektion, die wir hier gelernt haben, ist, dass wir diese Art von organisatorischen Hindernissen hätten identifizieren und lösen sollen, bevor wir mit dem Scrum-Teil des Projekts beginnen. Stellen Sie nicht viele Leute ein, bevor Sie diese grundlegenden Probleme gelöst haben.... Ein Sprint 0 wäre in der Tat sehr praktisch gewesen. In dieser speziellen Situation nutzen Sie ihn, um diese organisatorischen Hindernisse zu identifizieren und eine Lösung für sie zu finden. Sobald Sie diese Probleme gelöst haben und die Teams tatsächlich anfangen können, ist es an der Zeit, sie auf die Gehaltsliste zu setzen und mit Scrum zu beginnen.