Spezialist für ein Projekt in ein Scrum-Team "adoptiert" - nicht voll ausgelastet, aber gebeten, sich bei SM / Team zu erkundigen, um für andere Aufgaben "entschuldigt" zu werden

Ich habe ein Alt-Konto verwendet, da ich auf anderen .SE-Sites aktiv bin, und ich habe überlegt, ob dies eher auf The Workplace zutreffen würde, aber ich frage hier, weil ich letztendlich dachte, es sei eher eine Sache des „Projektmanagements“ als ein „Was“. was ich in meiner persönlichen Situation am Arbeitsplatz tun soll. Und ich vermute, dass es eine häufige Sache ist, der Scrum Master begegnen.

Hintergrund:

Ich bin „Spezialist“ in einem Team (Non-Scrum, Non-Agile) von anderen Spezialisten (mit unterschiedlichen Fachgebieten, aber die Gemeinsamkeit ist, dass wir eine Art „Crack-Team“ von Experten sind, auf die man sich verlassen kann bei Bedarf „Beratung“ für die Scrum-Teams im Unternehmen leisten und in der Zwischenzeit unsere eigenen strategischen Projekte verfolgen, um die zugrunde liegenden „strategischen“ Ziele des Unternehmens voranzutreiben). Um es klar zu sagen, wenn ich Beratung sage , meine ich das im internen, metaphorischen Sinne – wir sind Mitarbeiter des Unternehmens wie die Mitglieder des Scrum-Teams.

Ich bin also ein UX-„Guru“ und werde mit der „internen UX-Beratung“ in den verschiedenen Teams sowie mit der Arbeit an umfassenderen Projekten rund um UX und ähnlichen Dingen im Unternehmen als Ganzes beauftragt.

Also, für die letzten 6 Monate oder so wurde ich in „Projekt X“ versetzt, das ein Scrum-Team von 4 Webentwicklern, 2 Testern, einem Scrum Master (der keiner der Entwickler/Tester ist) hat; Die Rolle des Product Owners wird von einem Mitglied des Entwicklungsteams übernommen, was in diesem Zusammenhang sinnvoll ist.

Mein Problem:

In jedem Sprint gibt es nicht immer (oder oft!) genug UX-Beratungsarbeit, um zu rechtfertigen, ein Vollzeit-Scrum-Teammitglied zu sein , aber bei jedem Stand-up muss ich zurückmelden, „was ich gestern getan habe“ usw. (was nichts sein könnte , praktisch gesprochen), was ich mir heute holen möchte usw.

Ich könnte wahrscheinlich, möchte aber nicht wirklich, anfangen, "funktionsübergreifend" zu werden, indem ich anfangen könnte, in Angular.JS zu entwickeln und so weiter, oder zu lernen, wie man Tests automatisiert, oder was auch immer das Team braucht mehr Kapazität für im Moment... aber ich bin mit einer klaren Vorgabe als UX-Designer in dieses Unternehmen eingetreten und das ist der Fokus meines Karriereweges. Ich möchte kein "Front-End-Entwickler" als solcher werden; Ich schätze, dass Elemente des Front-End-Designs dem UX-Designer inhärent sind, aber was ich meine, ist, dass ich nicht 2 Jahre mit diesem Projekt verbringen möchte, ohne UX-Zeug und alle Front-End-Entwicklungs-Sachen zu machen, denn das ist es, was das Projekt erfordert , und bin dann in 2 Jahren mangels aktueller Erfahrung in meinem eigentlichen Bereich arbeitsunfähig!

Die Erwartung scheint zu sein, dass wir alle voll ausgelastet sind (geben oder nehmen) ; Es gibt eine Zeiterfassungsanwendung, in der wir ausfüllen müssen, dass wir an Y-Tagen X Stunden damit verbracht haben, an Rückstandselement Z usw. zu arbeiten, das für die Anforderungen der „abrechnungsfähigen Zeit“ verwendet wird. Im Großen und Ganzen ist die Arbeit an etwas, das ein „Projekt“ ist, kostenpflichtig; „Interne“ Arbeiten, wie viele der strategischen Dinge, an denen ich normalerweise arbeite, werden einem bestimmten Kunden nicht in Rechnung gestellt, sondern unterliegen einem internen Code wie „Marktforschung“ oder was auch immer. Später wird die Zeiterfassungsanwendung mit Schätzungen verglichen.

Wenn es für mich an diesem Projekt nichts mehr zu tun gibt, habe ich festgestellt, dass ich dazu übergehe, allgemeine Entwicklungen in der Branche zu recherchieren und über Probleme nachzudenken, die für andere Projekte im Unternehmen gelten (die mir nicht offiziell zugewiesen wurden können also die Zeit nicht gegen ihr Projekt melden) usw.

In der Zwischenzeit werde ich immer wieder gebeten, anderen Teams Input zu geben oder einen Blick auf etwas zu werfen und Verbesserungsvorschläge zu machen oder was auch immer ... diese Aufgaben können 2 Stunden oder einen Tag oder länger dauern, je nachdem, was sie sind und sie sind der Kern meiner „echten“ Arbeit.

Ich wurde dafür bestraft, dass ich im Vergleich zum Scrum-Team „off the books“ an diesen Dingen gearbeitet habe (obwohl sie sich in meiner Zeiterfassung niedergeschlagen haben), weil der SM das volle Engagement aller erfordert und das Team vor „außen“ „schützen“ muss. Unterbrechungen, damit wir die Sprintziele erreichen können.

Und ich darf nicht daran arbeiten, da sie außerhalb der „Sprint-Ziele“ liegen!

Vor kurzem bestand die „Lösung“ darin, eine Zeitbox von (sagen wir) 7 Stunden „Arbeit außerhalb des Sprints“ für die interne Beratung von Team X zu Problem Y herauszuarbeiten, und dann wird es als „Verschwendung“ in unsere Metriken aufgenommen es hat nicht zum Sprint beigetragen ( weil ich meinen eigentlichen Job gemacht habe!!

Meine Frage / TL;DR:

Wie soll ein Scrum-Master/Scrum-Team mit einer Situation umgehen, in der sie einen funktionsübergreifenden „Experten“ von einer anderen Stelle im Unternehmen bei einer vermeintlichen 100-prozentigen Auslastung assimiliert haben, wenn es nicht 100-prozentige Arbeit gibt und der „Experte“ erhält weiterhin externe Anfragen, wie es in ihrer Position zu erwarten wäre?

Wie erfasst man dies in den Scrum-Metriken?

Haben Sie mit dem Scrum Master gesprochen oder das Problem in einer Sprint-Retrospektive angesprochen? Wenn Sie eigentlich kein echtes Mitglied des Scrum-Teams sind, stellt sich die Frage, wer Sie „züchtigt“. Es ist aus Ihrem Beitrag nicht ersichtlich, ob die Trennung bei Ihnen, dem Scrum Master oder der Organisation liegt.

Antworten (4)

Dies ist einer der Bereiche, in denen Scrum meiner Meinung nach nicht in der Lage ist, reale Probleme anzugehen. Obwohl es für Teams gut ist, das Ziel zu verfolgen, dass seine Mitglieder funktionsübergreifend werden, gibt es Gründe, warum Spezialisten oder Experten zur Unterstützung des Teams erforderlich sein können. Dies sind Personen, die nicht Vollzeit im Team sind und möglicherweise mehrere Teams in der gesamten Organisation mit ihrem Wissen und ihrer Expertise unterstützen. Im Idealfall versuchen diese Spezialisten und Experten, einen Teil ihres Wissens und ihrer Expertise an die Mitglieder des Teams weiterzugeben, um den Zeitpunkt der Einbindung oder den Grad der Einbindung zu reduzieren, aber dies ist nicht immer möglich.

Wenn es um die Zusammenarbeit mit diesen Spezialisten in einem Scrum-ähnlichen Kontext geht, würde ich eine von zwei Arten von Engagements vorschlagen.

Die erste Art des Engagements wäre ein "eingebettetes" Engagement. Der Spezialist wird Mitglied des Scrum Teams. Damit dies jedoch sinnvoll ist, müsste der Experte über einen längeren Zeitraum ausreichend Arbeit leisten, um nahezu vollständig in dieses eine Scrum-Team investiert zu sein. Die vom Spezialisten übernommene Arbeit könnte praktisch sein, indem er Product Backlog Items übernimmt und sie fertig bringt. Die Arbeit könnte darin bestehen, das Scrum-Team zu unterrichten. Der Spezialist arbeitet möglicherweise nicht einzeln an Product Backlog Items, sondern nur zusammen mit anderen Mitgliedern des Scrum-Teams, um sie zu unterrichten oder ihnen bei der Lösung der Probleme zu helfen.

Die zweite Art von Engagement wäre ein „Berater“-Engagement. Der Spezialist wäre kein Mitglied des Scrum-Teams – er würde nicht am Daily Scrum oder der Sprint-Retrospektive teilnehmen. Sie sollten an der Sprint-Planung teilnehmen, um die Arbeit zu verstehen, die sie unterstützen werden, und um zu bestätigen, dass sie realisierbar ist. Sie können als Stakeholder am Sprint Review teilnehmen. Wenn die Arbeit für den Sprint ansteht, können die entsprechenden Mitglieder des Entwicklungsteams mit dem Spezialisten zusammenarbeiten, um zu helfen, die Arbeit fertig zu stellen. Dies kann alles sein, von der Unterstützung bei der Zerlegung und Planung der Arbeit über die Durchführung der Arbeit bis hin zur Überprüfung der "fertigen" Arbeit auf Korrektheit, bevor sie als erledigt bezeichnet wird.

Es hört sich so an, als gäbe es nicht genug Arbeit für die „eingebettete“ Art des Engagements, daher ist das „Berater“-Engagement möglicherweise angemessener. Daher würde ich keine bestimmte Auslastung oder abrechenbare Zeit für das Projekt des Scrum-Teams erwarten. Als Scrum Master würde ich mich darum kümmern, sicherzustellen, dass das Team Ihre Unterstützung hat, wenn sie rechtzeitig benötigt wird. Meiner Erfahrung nach hat abrechenbare Arbeit Vorrang vor interner oder nicht abrechenbarer Arbeit. Wenn es sich um einen Konflikt zwischen zwei Arten von abrechenbarer Arbeit handelte (Unterstützung von zwei oder mehr Scrum-Teams), gäbe es eine Methode zur Lösung dieser Art von Bedenken.

Wenn Ihre Hauptfunktion tatsächlich diese interne Arbeit und nicht die abrechenbare Arbeit ist, denke ich nicht, dass es die Entscheidung des Scrum Masters oder irgendjemandes in einem Scrum-Team wäre, von Ihnen zu erwarten, dass Sie sich einer Arbeit zuwenden, die außerhalb Ihrer liegt erste Pflichten.

Aus einem breiteren organisatorischen Kontext könnte dies etwas sein, das Sie mit Ihrem Front-Line-Manager besprechen sollten. Haben andere in der Organisation ähnliche Probleme erlebt? Wie haben sie es gelöst? Um weiterhin einen Mehrwert für die Organisation zu schaffen und die laufende Arbeit zu unterstützen, müssen Sie funktionsübergreifender werden (z. B. Front-End-Entwicklung oder -Tests lernen)? Wie sieht die Organisation Ihre Rolle und stimmt sie mit Ihren beruflichen Zielen und Interessen überein? All dies wären nützliche Dinge, über die Sie in einem 1:1-Gespräch mit Ihrem Vorgesetzten sprechen können.

Wie soll ein Scrum-Master/Scrum-Team mit einer Situation umgehen, in der sie einen funktionsübergreifenden „Experten“ von einer anderen Stelle im Unternehmen bei einer vermeintlichen 100-prozentigen Auslastung assimiliert haben, wenn es nicht 100-prozentige Arbeit gibt und der „Experte“ erhält weiterhin externe Anfragen, wie es in ihrer Position zu erwarten wäre?

Der beste Ansatz, den ich gesehen habe, ist, dass der Spezialist die Arbeit des Scrum-Teams priorisiert, aber andere Arbeiten akzeptiert, um etwaige Lücken zu schließen.

Priorisierung ist wichtig, weil sie es dem Team ermöglicht, seine eigene Kapazität zu kennen. Wenn der Spezialist auswählen könnte, welche Teile der Arbeit des Teams er erledigt und wann er dies tut, dann ist er effektiv zu einer externen Abhängigkeit geworden.

bei jedem Stand-up muss ich zurückmelden, "was ich gestern gemacht habe" usw. (was praktisch nichts sein kann), was ich heute holen möchte usw.

Die Absicht des täglichen Scrums ist es, die Bemühungen des Teams für den Tag zu synchronisieren. Mit Berichterstattung hat das nichts zu tun. Ich würde vorschlagen, dass Sie nur über Aktivitäten sprechen, die sich auf das Team auswirken und daher Teil dieser Synchronisation sein müssen.

Ich könnte wahrscheinlich, will aber nicht wirklich, anfangen, "funktionsübergreifend" zu werden

Das sollte kein Problem sein. Funktionsübergreifende Teammitglieder mit unterschiedlichen Fähigkeiten machen ein Team oft produktiver, aber das ist sicherlich keine zwingende Voraussetzung. Solange Sie und die Organisation akzeptieren, dass es dadurch zu einem kleinen Verlust an Produktivität und Flexibilität kommen kann, sollte es in Ordnung sein.

Die Erwartung scheint zu sein, dass wir alle bei voller (Geben oder Nehmen) Auslastung sind

Es gibt gute Beweise dafür, dass Mitarbeiter bei voller Auslastung ihre Produktivität verringern. Der Grund dafür ist, dass ein gewisser Spielraum erforderlich ist, um:

  • Stellen Sie einen Puffer für ungeplante Arbeiten bereit
  • Ermöglichen Sie den Menschen, ihre Fähigkeiten zu erweitern
  • Lassen Sie Wissensaustausch zu
  • Zeit haben, Verbesserungen vorzunehmen

Wir hatten dieses Problem ziemlich oft in unserem Team. Ihrer Definition nach hatten wir zwei Arten von Experten :

  • Einer, der die Legacy-Details der Anwendung ein wenig zu gut kannte und aufgefordert wurde, alte Produktionsprobleme zu lösen
  • Domänenexperte: wie die UX-Design-Expertise, auf die Sie anspielen.

Wir hatten alle diese X-funktionalen Leute gebeten, alles auf dem "Board" zu verfolgen, um zu verstehen, wie viel Prozent ihrer Zeit wo verbracht wurde.

Manchmal sahen wir eine 50-50-Aufteilung und andere waren es etwa 70-30 (30 für externe Teamarbeit).

Dies half uns, ihre „Kapazität“ für einen Sprint zu ermitteln. Wir haben in idealen Tagen geschätzt, wenn also ein Sprint 2 Wochen dauert, haben Sie 10 ideale Tage und bei 50 % Kapazität sind das 5 ideale Tage Ihrer Zeit.

Aufgrund der Unvorhersehbarkeit sollte man immer eine 100-prozentige Kapazitätsauslastung vermeiden, daher haben wir uns für eine 75-%-Faustregel entschieden. Jeder füllt bis zu 75 % der Kapazität und hält die verbleibenden 25 % der Artikel „oben auf dem Frühjahrsrückstand“ (bereits präpariert und bereit zum Verzehr, wenn wir unsere 75 % aufgebraucht haben). 75 % von 5 idealen Tagen sind ungefähr 4 ideale Arbeitstage, was bedeutet, dass man ungefähr 2-4 Geschichten schreiben könnte (1+3, 2+2, 1+1+1+1, 2+1+1).

Die Experten hatten auch ein "Eimer-Ticket" für Out-of-Team-Arbeit, das auf der Tafel bleiben würde, geschätzt auf 5 Punkte. Die gesamte Arbeit würde dann zu einer „Aufgabe“ unter diesem Ticket, die nachverfolgt/geschätzt werden muss usw. Wenn sie in einem bestimmten Sprint nicht viel abgezogen wurden, holten sie Arbeit aus dem Rückstand und machten weiter.

Es ist möglich, dass sie "auf halbem Weg" hineingezogen wurden und es sozusagen eine "Verschleppung" gab, und das ist in Ordnung. Es wurde in die Kapazität des nächsten Sprints eingerechnet.

Vielleicht könnte so etwas nützlich sein, wenn alle Informationen darüber, wo Ihre Zeit geteilt wird, und die Planung gegen Ihre Kapazität auf einer anderen Ebene als den standardmäßigen 10 idealen Tagen des Teams (sagen wir) erfolgen.

PS: Um einen idealen Tag zu verankern, sind wir davon ausgegangen, dass 1 idealer Tag einer ist, an dem Sie etwa 5-6 Stunden produktive Zeit haben können. Alles andere ist Overhead für Meetings, Pausen usw. Dies wurde auch gemacht, um zu verstehen, wie viel Overhead auf dem Team lastet (wir haben festgestellt, dass einige Teams einen idealen Tag von nur 3 Stunden haben! Dies impliziert viel zu viel Overhead/Meetings, also haben wir die Dinge gesetzt in Bewegung, um solche Störungen zu verhindern). Dies ist möglicherweise nicht ganz relevant für Ihre Frage und füge dies nur zur Klarstellung / zum Kontext hinzu.

Dabei gibt es zwei Seiten: das funktionsübergreifende Team und den Experten-Spezialisten. Ich denke, wir müssen beide klar definieren, bevor wir darüber sprechen können, wie sie zusammenarbeiten.

Funktionsübergreifendes Team: Dieses Team verfügt über alle erforderlichen Fähigkeiten, um ein Produkt bis zur Fertigstellung zu liefern. In fortgeschrittenen funktionsübergreifenden Teams haben sie ihr Fähigkeitsprofil so abgestimmt, dass es der Häufigkeit entspricht, mit der eine Fähigkeit benötigt wird, und auf welchem ​​Niveau sie diese Fähigkeit benötigen (Anfänger, Profi, branchenführender Experte usw.).

Experte-Spezialist: Jede Fertigkeit aufrechtzuerhalten braucht Zeit. Um eine Fertigkeit auf einem bestimmten Niveau zu halten, bleibt keine Zeit, andere Fertigkeiten beizubehalten. Experten-Spezialisten sind oft die Besten ihrer Branche. Sie lösen Probleme, die andere Menschen mit dieser Fähigkeit nicht können. In der Medizin ist das der Facharzt für den Hausarzt.

Jetzt ist die erste Frage für Ihre Situation, haben Sie beides? Füllen Sie eine Lücke, weil das Team nicht funktionsübergreifend ist? Um die medizinische Analogie zu verwenden, gehen Sie zum Spezialisten, wenn Sie an die Grenzen des Allgemeinmediziners stoßen, aber die meiste tägliche Arbeit in diesem Bereich wird vom Hausarzt erledigt. Wenn Sie als Facharzt für dieses Team wie ein Hausarzt agieren, ist das Problem nicht Ihre Querschnittsfunktion, sondern deren. Das Beste, was Sie für das Team tun können, ist, nicht die Arbeit zu erledigen, sondern dabei zu helfen, die Fähigkeiten und Ressourcen im Team aufzubauen, damit sie die meiste Zeit die meiste UI/UX-Arbeit erledigen können. Die harte Wahrheit in diesem Fall ist, dass der Experte das dysfunktionale Verhalten des Teams ermöglicht und ihm die Verantwortung zurückgeben muss.

Als nächstes sind Sie ein Experte-Spezialist? Machen Sie branchenführende UX-Arbeiten, schreiben Papiere, halten Vorträge? Ich habe mit vielen Organisationen zusammengearbeitet, die sagen, dass sie sie haben, aber ich habe nur mit einer gearbeitet, die dies wirklich getan hat. Öfter sehe ich Menschen, die in einem Silo zusammengepfercht sind. Das ist eine harte Realität, der man sich stellen muss, aber sie kann befreiend sein. Wenn Sie feststellen, dass Sie es sind, müssen Sie und Ihre Organisation eine Wahl treffen. Sie wollen Hausarzt oder Facharzt werden? Und schätzt Ihr Unternehmen einen Spezialisten? Ich habe den Eindruck, dass viele dieser gefangenen Menschen woanders hingehen, um einen Ort zu finden, der tatsächlich ihr Wissen und ihre Fähigkeiten erfordert, und sich darüber sehr freuen. Oder Fachärzte, die später feststellen, dass sie es lieben, die Hausärzte ihrer Branche zu sein.

OK, nehmen wir an, Sie haben beides. Wie funktionieren sie nun in Scrum? Zunächst einmal optimieren wir niemals einen Spezialisten für das Geschäft. Sie haben spezielle Kenntnisse und Fähigkeiten, die andere Menschen brauchen. Wenn sie nicht verfügbar sind, werden ganze Teams von Menschen aufgehalten. Optimieren Sie immer einen Spezialisten für die Verfügbarkeit und die Aufrechterhaltung seines Spezialisierungsgrads. Als nächstes möchten Sie nicht viele Regeln erstellen oder eine dieser Gruppen verwalten. Denken Sie daran, dass Sie ein Scrum-Team haben und die Spezialisten Scrum verwenden können oder nicht (ich würde es wahrscheinlich nicht tun, wenn es meine Wahl wäre). Tatsächlich sind die Spezialisten ein Service-Delivery-Team. Ich könnte Kanban verwenden, um ihren Prozess zu verfeinern und Transparenz zu schaffen. An diesem Punkt geht es um SLAs und Verhandlungen.