Hintergrund: Ein großes Beratungsunternehmen möchte die Zeit seiner Berater zwischen den Einsätzen besser nutzen. Geplant ist ein internes Konzept zur Verwaltung interner Projekte, die darauf abzielen, einen Mehrwert für das Unternehmen zu schaffen (Verkaufsdemos, interne Produkte usw.) und den Beratern auch die Möglichkeit zu geben, neue Fähigkeiten zu erwerben (z. B. Erfahrungen in der Arbeit als Scrum zu sammeln Meister).
Die Verwendung von Scrum für diese Projekte führt zu gemischten Ergebnissen, da die Mitarbeiter die Projekte ziemlich sofort verlassen, wenn sie einen bezahlten Auftrag erhalten, was es unmöglich macht, eine einigermaßen konstante Geschwindigkeit zu erreichen.
Diese Umstände erhöhen auch die Anforderungen an die Leichtigkeit, mit der man in diese Projekte einsteigen kann, zum Beispiel Lesbarkeit des Codes, Dokumentation der Entscheidungsfindung usw. Ein Risiko besteht darin, dass dies den Wasserfallcharakter dieser Projekte erhöhen könnte, was ich sehr möchte vermeiden
Wie verwaltet man diese Projekte? Projektmethoden verwenden? Fallstricke zu vermeiden, und wie? Jede Hilfe wäre sehr willkommen
Scrum geht von einem festen Team aus, also ist es, wie ein anderer Befragter sagte, keine Überraschung, dass Sie Scrum frustrierend fanden. Und während zu sagen, dass Sie Menschen mehr „einsetzen“ wollen, spricht gegen die falschen Annahmen, dass Sie Menschen zu 100 % einplanen können, aber ich stimme mit den Zielen überein, Leuten zu helfen, die nicht bei einem Kunden sind, Wege zu finden, sich auf andere wertvolle Beschäftigungen zu konzentrieren.
Das klingt eher nach Begriffen wie „FedEx Days“ oder „80 % Zeit“. Im Wesentlichen geht es darum, Richtlinien für Leute zu entwickeln, aber nicht zu versuchen, Projekte mit Terminen, Lieferungen oder Verpflichtungen zu erstellen. Nimm Daniel Pinks „Drive“ auf. Es kann Ihnen auch einige Ideen geben, wie Sie helfen können, Berater auf der Bank zu motivieren und anzuleiten.
Ich habe in Beratungsunternehmen gearbeitet und meiner Erfahrung nach haben wir uns immer darauf gefreut, zusammenzuarbeiten, wenn wir wieder in unserer Heimatbasis waren. Es gab uns eine Möglichkeit, unser Geschäft zu verbessern und voneinander zu lernen, und die Herausforderung der Führung bestand darin, Wege zu finden, dies für uns zu erleichtern und gleichzeitig die Kunden zu unterstützen.
Was spezifischere Tools betrifft, könnten Sie ein Kanban-Board ausprobieren, aber ich würde ernsthaft fragen, warum Sie die Geschwindigkeit messen müssen (Velocity oder Thru Put). Vielleicht brauchen Sie nur einen sichtbaren Indikator oder eine Möglichkeit zur Übergabe oder eine Möglichkeit, um zu sehen, was als nächstes abgeholt werden muss, wenn Sie zurückkommen. Erstellen Sie das Tool, das zu Ihnen passt, und steuern Sie es nicht mit Prozessen. Viel Glück
Ich bin mir nicht sicher, ob Scrum in diesem Fall das richtige Werkzeug für den Job ist. Ein ähnlicher Fall findet sich bei der Entwicklung von freier/Open-Source-Software, wo die Beiträge sporadisch und heterogen sind.
Wahrscheinlich könnte ein System ohne spezifische Iterationen, aber mit kontinuierlicher Bereitstellung und variabler Geschwindigkeit, wie Kanban , besser zu Ihnen passen.
Es gibt keine Wunderwaffe, um das Problem Ihres Unternehmens zu lösen, dass es nicht in interne Projekte investiert. Der Weg zur erfolgreichen Durchführung eines Projekts besteht darin, es realistisch zu besetzen und mit diesem Personal durchzuführen. Wenn Sie Leute haben, die einfach nur die Zeit totschlagen, werden sie sich nicht für ihre kurzfristige Aufgabe mit unbekannter Dauer interessieren oder sich dafür einsetzen.
Ich würde vorschlagen, dass die Verwendung einer iterativen Projektmethodik Ihnen tatsächlich schadet.
Warum? Agile Methoden beruhen auf einem konstanten Team mit konstant erreichbarer Geschwindigkeit. Wenn Sie ein 5-köpfiges Team haben und in einem 3-Wochen-Zyklus (auch Sprint) 2 Leute verlieren, verlieren Sie die Kontrolle über diese Geschwindigkeit und müssen entweder zu wenig liefern oder den Zeitrahmen Ihres Entwicklungszyklus ändern.
Ich glaube, Ihre Projekte könnten erfolgreicher sein, wenn Sie ein kleineres Team (2 Personen?) damit beauftragen würden, Ihre Anforderungen zu verfassen und einige UI-Mockups (zum Beispiel) in sehr kleinen Arbeitspaketen zu erstellen, und wenn Sie dann einen Entwickler auf die Bank bekommen, weisen Sie zu ihm oder ihr eine kleine Menge Arbeit, die Ihre Organisation übernehmen kann, damit sie sie erledigen kann. In unseren agilen und nicht agilen Projekten (und einige mit Hybriden aus beiden) machen wir unsere definierbaren und testbaren Arbeitspakete in weniger als einer Woche so „machbar“ wie möglich. Alles, was länger als 3-5 Tage Arbeit ist, wird in der Hoffnung in Frage gestellt, auseinander gebrochen zu werden.
Ich denke, der beste Weg für Sie ist, zuerst ein Backlog zu erstellen und zu versuchen, eine Vision davon zu entwickeln, was genau Sie mit diesem Tool erreichen möchten. Sobald Sie wie oben erwähnt Rückstand haben, versuchen Sie, 2 Personen langfristig an Bord zu haben. Diese Jungs sollten Design/Anforderungen verstehen. Dann können Sie weitere Personen um sie herum hinzufügen. Für ein internes Projekt stellt kein Unternehmen der Welt Ressourcen oder Geld zur Verfügung. Machen Sie also von Zeit zu Zeit Demos, um die Beteiligten auf den neuesten Stand zu bringen und die Leute im Pool zu nutzen
Scrum schlägt vor, ein festes Team zu haben, so dass es schwierig sein wird, die Geschwindigkeit für Ihr Projekt zu verfolgen.
Was ich vorschlagen würde, ist, Aufgaben auf die kleinste Größe aufzuteilen, die innerhalb eines Tages erledigt werden kann, und dann den Entwicklungszyklus im Kanban-Stil anzuwenden. Es hilft, die Arbeit in Gang zu bringen, und Sie können den Beitrag des Einzelnen überwachen.
David Hiller
magnus.westrom