Sollte ein Designer oder Entwickler Mitglied eines Scrum-Teams sein?

Normalerweise werden solche Spezialisten wie ein Designer oder ein DevOps-Ingenieur (im Gegensatz zu Entwicklern und QA-Ingenieuren) nicht dauerhaft benötigt, um Entwicklungsaktivitäten durchzuführen (sie werden mit einigen Aufgaben nach Bedarf beschäftigt). Daher ist es normalerweise nicht sinnvoll, dass jedes Scrum-Team einen eigenen Designer oder Entwickler hat.

Nehmen wir an, wir haben mehrere Scrum-Teams (Entwickler und QA), die an demselben Projekt oder vielleicht an verschiedenen Projekten arbeiten. Was ist mit Designern und Entwicklern? Sollten wir in einem Unternehmen eine Designer-Abteilung und eine Devops-Abteilung haben (in diesem Fall können diese Abteilungen leicht zu Engpässen für die Scrum-Teams werden und tun dies oft)?

Antworten (4)

Die Externalisierung von Schlüsselressourcen ist ein häufiges Anti-Pattern

Was ist mit Designern und Entwicklern? Sollten wir in einem Unternehmen eine Designer-Abteilung und eine Devops-Abteilung haben (in diesem Fall können diese Abteilungen leicht zu Engpässen für die Scrum-Teams werden und tun dies oft)?

Nein. Ein Scrum-Team sollte über alle erforderlichen Fähigkeiten verfügen, um das Produkt zu erstellen und jedes Produktinkrement zu produzieren. Wenn Sie wesentliche Ressourcen auslagern, schaffen Sie Engpässe in Ihrem Prozess.

Unternehmen, die sich dafür entscheiden, treffen eine geschäftliche Entscheidung , Engpässe, erhöhte Prozessfriktionen und reduzierte Produktivität im Gegenzug für (theoretisch) niedrigere Arbeitskosten durch reduzierte Mitarbeiterzahl in Kauf zu nehmen. Das funktioniert so gut wie nie, aber Leute mit einem gewissen Business-School-Hintergrund scheinen es immer wieder zu versuchen, trotz der empirischen Evidenz, dass das in der IT oder in der Wissensarbeit im Allgemeinen einfach nicht gut funktioniert.

Sie haben ein paar Möglichkeiten, aber keine davon ist die, die Sie wahrscheinlich hören möchten. Sie sind:

  1. Investieren Sie in mehr „Spezialisten“, damit jedes Team über alle wesentlichen Ressourcen verfügt, die es während des gesamten Produktentwicklungslebenszyklus benötigt. Hinweis: Dies geht zu Lasten einer höheren Mitarbeiterzahl.
  2. Investieren Sie in die Schulung Ihrer I-förmigen Teammitglieder und Spezialisten, damit diese zu T-förmigen Menschen werden, und setzen Sie Ihre Fachexperten ein, um Praxisgemeinschaften zu bilden, damit das Wissen breiter geteilt wird. Hinweis: Dies geht zu Lasten eines höheren Overheads (und möglicherweise des Eindrucks einer verringerten Produktivität), da Laien ihre Fähigkeiten erweitern.
  3. Akzeptieren Sie die reduzierte Produktivität, höhere Reibung und längere Vorlaufzeiten, die einem System mit hohen oder kritischen externen Abhängigkeiten innewohnen. Hinweis: Dies ist einer der Hauptgründe dafür, dass 68 % der IT-Projekte scheitern. Planen Sie, eine Statistik zu sein.

Es gibt keinen Königsweg, aber die Auslagerung von Schlüsselressourcen ist fast immer die schlechteste Lösung. Mit Nr. 3 setzen Sie sich, das Team und das Projekt höchstwahrscheinlich dem Scheitern aus, aber solange die Geschäftsleitung die volle Verantwortung für die Folgen der Wahl dieser Option übernimmt, ist dies zumindest eine legitime Geschäftsentscheidung und verdient daher eine Erwähnung .

Idealerweise sollte ein Scrum-Team alle erforderlichen Rollen haben, um das Produkt innerhalb des Teams zu entwickeln, und nicht von externen Ressourcen oder Personen abhängig sein. Idealerweise sollten der Designer und der Entwicklungsingenieur daher Teil des Teams sein, auch wenn sie nicht während des gesamten Sprints voll ausgelastet sind (obwohl Sie immer einen Designer mit der UX/UI-Forschung beauftragen können, um das Produkt zu verbessern, oder der Entwicklungsingenieur mehr Zeit mit der Automatisierung von Dingen verbringt oder die Überwachung der Live-Server erhöhen, um beispielsweise das Leben des Teams zu erleichtern).

Aber wie Sie selbst erwähnt haben, ist es nicht gut für Unternehmen, wenn jemand nur manchmal benötigt wird oder mit einer Arbeit beschäftigt sein muss, um voll ausgelastet zu sein. Das liegt daran, dass es eine vorherrschende Denkweise gibt, Menschen als Ressourcen zu betrachten, die vollständig genutzt werden müssen (genauso wie Sie nicht wollen, dass eine Maschine nur die Hälfte der Zeit ungenutzt auf dem Werksboden steht) und denken, dass sie das bekommen können maximaler Nutzen bei 100 % Auslastung, was eigentlich ein Mythos ist .

Manchmal ist auch jemand sehr geschickt in seinem Job und das Unternehmen möchte, dass er seinen Beitrag zu mehreren Projekten leistet, damit jedes davon profitiert, aber das Endergebnis ist dasselbe, was Abhängigkeiten und mögliche Engpässe einführt.

Wenn Sie sich in einer solchen Situation befinden, muss das Team entsprechend planen (häufig mit anderen Teams für dieselbe Person koordinieren), um sicherzustellen, dass die Abhängigkeit minimiert und Engpässe vermieden werden. Und das betrifft auch die Person, die an Scrum-Events teilnimmt, um sicherzustellen, dass für die Person immer noch eine gewisse Kontinuität besteht, auch wenn sie in mehreren Projekten arbeitet.

Also um deine Frage zu beantworten:

Sollte ein Designer oder Entwickler Mitglied des Scrum-Teams sein?

Ja, das sollten sie. Sind es aber oft nicht.

Ja . Designer und DEVOPS sollten Teil des Scrum-Teams sein. Ihre Zeitpläne würden sich auf den Gesamtzeitplan für die Projektabwicklung auswirken

Seien Sie sehr vorsichtig mit dem, was Sie als „Engpass“ bezeichnen . Um es einfach auszudrücken: "Es spielt keine Rolle, wie schnell Sie die Straße hinunterfahren, wenn die Brücke vor Ihnen aus ist."

Sie benötigen daher unbedingt zumindest den Input von Designern (die dem Team helfen, festzustellen, was tatsächlich erforderlich ist) und Entwicklern (die dem Team helfen, festzustellen, wie das fertige System bereitgestellt wird). Obwohl diese Personen zweifellos nicht direkt an der Herstellung des Arbeitsprodukts beteiligt sind und daher nicht direkt in diese Zählungen einbezogen werden sollten.

Wenn diese Leute etwas beisteuern, das eigentlich „langsam!“ sagt, sollten Sie sehr vorsichtig sein, dass Ihre Messstrategie dies nicht fälschlicherweise als „Engpass“ identifiziert , also „eine negative Sache, die es zu vermeiden gilt“. Während Ihr Team Dinge „voran sprintet“, ist es dennoch wichtig, dass sie jederzeit das Beste und am besten informierte tun. Der beste Weg, um mit einer ausgerissenen Brücke fertig zu werden, ist, den Kurs rechtzeitig zu ändern, wenn dies erforderlich ist.