Die Situation: Wir sind ein kleiner Anbieter von vollvertriebenen Softwarelösungen. Wir betreuen mehrere Kunden, und angesichts unserer Größe bedeutet dies, dass jedes Teammitglied in mehreren kostenpflichtigen Teilzeitteams ist. Normalerweise 2 solcher Teams pro Person, um Kontextwechsel zu minimieren. Jeder arbeitet insgesamt 30-40 Stunden pro Woche, was von Woche zu Woche je nach verfügbarer Arbeit und normalen Herausforderungen variiert. Alle Teams schätzen die Arbeit anhand von Story Points oder Stunden, aber die Definitionen davon variieren je nach Kunde, ebenso wie die Methodik (Kanban oder Scrum, mit unterschiedlichen Iterationen) und die Tools (Jira, PT und V1).
Das Problem: Zusammengenommen ist die Teamzusammensetzung und -ausführung nie konsistent genug, um typische Geschwindigkeits- oder Effizienzmetriken zu unterstützen, was es wiederum zu einer Herausforderung macht, vertrauenswürdige Ziele für Kunden zu schaffen (z. B. wo wir zu bestimmten Terminen in einem Rückstand landen, potenzielle Arbeitsschätzungen). Wir tun unser Bestes, um die Teamzusammensetzung aus Gründen der Kontinuität einige Monate am Stück aufrechtzuerhalten, aber die oben genannten Aspekte führen offensichtlich zu schwer vorhersehbaren Ergebnissen und verschleiern wahrscheinlich andere Bedenken.
Wie können wir also besser werden, am besten ohne die Art und Weise, wie wir Geschäfte machen, drastisch zu ändern?
Ansätze, die uns bisher eingefallen sind, haben wichtige Fallstricke:
Wir fixieren unsere Eingaben (z. B. Definition von Story Points), Methodik und Tools und iterieren, bis wir so gut wie möglich damit umgehen. Der Fallstrick, wie wir es sehen: Das Risiko der Kundenbeziehung, da die meisten bereits über Teams, Methoden und Tools verfügen, mit denen wir koexistieren.
Wir erstellen pro Person aggregierbare Velocity-Metriken, die nach Art der Arbeit, Teamgröße usw. mit Querverweisen versehen sind, wenn wir im Laufe der Zeit Verständnis gewinnen. Gotcha: Basierend auf unseren Recherchen scheint dies spekulativ zu sein und es könnte ewig dauern, bis es gesperrt ist.
Wir stabilisieren unsere Teams, um traditionellere Velocity-Metriken, Schätzungen und Planungstechniken zu ermöglichen. Gotcha: Geschäftsentwicklungs- und Aufrechterhaltungsrisiko, da dies unsere Fähigkeit einschränken wird, Teams als Reaktion auf Budgetänderungen und neue Aufgaben zusammenzustellen und aufeinander abzustimmen.
Welche davon klingt am effektivsten? Oder eine Mischung? Irgendwelche anderen Ideen?
Ich stimme dem zu, was @barnaby vorgeschlagen hat. Option 3 ist hier die bevorzugte Lösung, funktioniert jedoch nur, wenn auf organisatorischer Ebene ein Buy-In vorhanden ist. Es gibt ein paar Möglichkeiten, die von Ihnen erwähnten "Fallstricke" zu vermeiden
Gotcha: Geschäftsentwicklungs- und Aufrechterhaltungsrisiko, da dies unsere Fähigkeit einschränken wird, Teams als Reaktion auf Budgetänderungen und neue Aufgaben zusammenzustellen und aufeinander abzustimmen.
Führen Sie Scrum in Ihren Teams ein. Erklären Sie externen Stakeholdern, was dies bedeutet, und stellen Sie sicher, dass sie Scrum und seine Prinzipien respektieren. Sobald Ihr Team an Bord ist und versteht, was Scrum bedeutet, ist es Ihre Aufgabe, das Scrum-Team zu schützen.
Während Sprints ist es Ihre Aufgabe sicherzustellen, dass das vereinbarte Sprint-Ziel nicht gestört wird. Dies bedeutet jedoch nicht, dass Sie nicht agil sein können. Zum Beispiel führen viele Organisationen 1- oder 2-wöchige Sprints durch. Wenn also außerhalb Ihres Scrum-Teams etwas auftaucht, an dem so schnell wie möglich gearbeitet werden muss, kann Scrum darauf eingehen. Es muss nur auf kontrollierte Weise geschehen (durch Sprint-Planung).
Ohne genauere Details ist es schwierig, Ratschläge zu "Änderungen des Budgets" zu geben. Wie oft ändern sich Projektbudgets und warum?
Scrum kann nur funktionieren, wenn das Scrum-Team geschützt und nicht unterbrochen wird. Dies kann in vielen Organisationen schwierig sein, die von traditionelleren Projektmanagementstilen abweichen können. Vielleicht können analoge Beispiele dabei helfen, interne Skeptiker zu überzeugen, wie Jeff Bezos Ansatz, dass „ein Team niemals mehr Leute haben sollte, als zwei große Pizzen vertragen“. Dies ist jedoch enger mit organisatorischen Veränderungen verbunden als mit Projektmanagement.
Option 3 ist die richtige und ich werde erklären, wie man das „Gotcha“ vermeidet.
Wir stabilisieren unsere Teams, um traditionellere Velocity-Metriken, Schätzungen und Planungstechniken zu ermöglichen. Gotcha: Geschäftsentwicklungs- und Aufrechterhaltungsrisiko, da dies unsere Fähigkeit einschränken wird, Teams als Reaktion auf Budgetänderungen und neue Aufgaben zusammenzustellen und aufeinander abzustimmen.
Stabile Teams zu haben, verringert nicht Ihre Flexibilität, auf Budgetänderungen und neue Aufgaben zu reagieren. Es verbessert es, weil die Effizienz der Teams verbessert wird (z. B. können sie einen verfeinerten Prozess für das Onboarding von Prioritätsänderungen haben).
Bringen Sie die Arbeit in die Teams, anstatt neue Teams für bestimmte Projekte zu bilden.
Wenn sich ein Budget ändert, ändern Sie die Priorität des Rückstands für die Teams, um dies widerzuspiegeln. Wenn neue Arbeit hereinkommt, bestimmen Sie die Priorität gegenüber anderer Arbeit, die das Team bereits in seinem Backlog hat.
Dies kann bedeuten, dass ein Team an mehr als einem Projekt gleichzeitig arbeitet. Dies ist nicht ideal, da die Kontextumschaltung ihre Effektivität verringert. Sie können dies jedoch bis zu einem gewissen Grad abmildern, indem Sie:
Die größten Herausforderungen werden sich auf Dinge wie den Abrechnungsmechanismus und die Kundenwahrnehmung beziehen (z. B. möchten sie möglicherweise ein „dediziertes Team“). Wenn Sie ein gutes Verhältnis zu Ihren Kunden haben, können Sie ihnen die Vorteile stabiler Teams erklären und sind dann hoffentlich bereit, in anderen Bereichen Kompromisse einzugehen.
Daniel
Todd A. Jacobs
Bart van Ingen-Schenau