Ist es für einen Scrum Master in Ordnung, einem Entwickler zu erlauben, an einer Story zu arbeiten, die nicht vom Product Owner priorisiert wurde, wenn es in seiner Freizeit ist?

TL;DR

Ich sagte dem Entwickler, er solle aufhören, an irgendetwas zu arbeiten, das nicht vom Product Owner priorisiert wurde, unabhängig davon, ob er Zeit hat oder nicht.

Aus Sicht des Frameworks dürfte dies der richtige Ansatz sein. Es ist sicherlich das, was ich als Grundsatzerklärung der Organisation empfehlen würde. Es verstärkt Scrum-Prozesse und -Praktiken (z. B. Timeboxing) und reduziert Risiken für die Organisation, das Team und den Entwickler selbst.

Aus psychologischer Sicht ist die richtige Teammanagement-Antwort jedoch weniger eindeutig. Die Persönlichkeit und Motivation einer Person sowie ihre individuellen Anforderungen, um sich weiterhin intensiv in einem Projekt zu engagieren, müssen im Hinblick auf den Gesamtnutzen sowohl für sie als auch für das Projekt als Ganzes ausgewogen sein.

Im Folgenden werden einige der Vorteile und Risiken untersucht, die mit der Zulassung von Arbeiten außerhalb der Uhr verbunden sind. Es ist sicherlich nicht vollständig, sollte aber einen soliden Ausgangspunkt für Ihre eigene Risiko-Ertrags-Analyse bieten. Ihre Laufleistung wird auf jeden Fall variieren.

Leistungen

Es gibt einige potenzielle Vorteile, wenn man den Entwickler in seiner Freizeit an etwas arbeiten lässt, das ihm am Herzen liegt. Dazu können gehören:

1. Unterstützung seiner Leidenschaften.

   Viele Wissensarbeiter schätzen persönliche Leistung, Stolz auf ihre Arbeit und die Anerkennung ihrer Kollegen mindestens so sehr wie einen Gehaltsscheck. Die Unterstützung dieser Werte kann für die Moral des Einzelnen und des Teams gut sein.

2. Persönliches Wachstum.

   Die Ermutigung von Entwicklern, als Programmierer zu wachsen, indem sie ihr Wissen über Programmiertechniken erweitern, um Probleme zu lösen, die sie interessant finden, kann zu einer verbesserten Codequalität und neuen Erkenntnissen für das Team führen. Dies außerhalb der Arbeitszeit zu tun, kostet das Unternehmen finanziell nichts.

3. Individuelle Investition.

   Jemand, der leidenschaftlich genug für eine Dienstleistung oder ein Produkt ist, um in seiner Freizeit daran zu arbeiten, ist wahrscheinlich engagierter als jemand, der einfach jeden Tag auftauchen und einen Gehaltsscheck kassieren möchte.

4. Produktqualität.

   Menschen, die sich für ihre Arbeit begeistern, können durch ihre Freizeitaktivitäten inspiriert werden, unabhängig davon, ob diese Aktivitäten in direktem Zusammenhang mit dem Projekt stehen oder nicht. Das Projekt kann sicherlich von einer solchen Inspiration profitieren, und (vorbehaltlich der unten aufgeführten Risiken) können solche Beiträge den Gesamtwert oder die Qualität des Produkts des Teams verbessern.

Kurz gesagt, sich um seine Arbeit oder ein Projekt zu kümmern, das fast 40 % seines wachen Lebens in Anspruch nimmt, ist im Allgemeinen eine gute Sache™. Auf den ersten Blick scheint es wenige Gründe zu geben, davon abzuraten, aber die potenziellen Vorteile sollten sorgfältig gegen die potenziellen Nachteile für alle Beteiligten abgewogen werden.

Risiken für das Team

Das Risiko für das Team besteht darin, dass es die Organisation dazu anregen könnte, über nicht abrechenbare Stunden nachzudenken, die für ihre Schätzungen verfügbar sind. Bei Scrum geht es insbesondere darum, ein nachhaltiges Tempo innerhalb zeitlich begrenzter Iterationen festzulegen, sodass Arbeiten, die außerhalb der zeitlich begrenzten Iterationen stattfinden, die Metriken verzerren und unhaltbare Erwartungen an das Team wecken.

Darüber hinaus besteht die Gefahr, dass Verwirrung über einige grundlegende agile Prinzipien entsteht, wie zum Beispiel:

1. Zeitboxen. Innerhalb einer Timebox wird etwas getan oder nicht erledigt , und Sie möchten nicht den Präzedenzfall schaffen, dass Timeboxen außer Acht gelassen werden können.
2. YAGNI . Wenn das Feature nicht Teil des aktuellen Sprints ist und für das Projekt nicht wichtig genug ist, um eine Priorität im Product Backlog zu haben, dann ist es nicht wichtig genug, um Ressourcen dafür aufzuwenden. Selbst wenn es nur um die persönlichen Ressourcen des Entwicklers geht, schafft die Arbeit an YAGNI-Gegenständen einen schlechten Präzedenzfall für das Team. Es kann auch den Respekt vor der wesentlichen Rolle des Product Owners bei der Festlegung von Projektprioritäten verringern.

Risiken für die Organisation

Auch wenn es unwahrscheinlich ist, dass die einseitigen Arbeitsverträge, die die meisten IT-Mitarbeiter heutzutage unterschreiben, ein erhebliches rechtliches Problem darstellen, ist es dennoch ein schlechter Präzedenzfall, unbezahlte, private Arbeit in eine kommerzielle Codebasis zu integrieren, die nicht offen ist -Source-Lizenz. Vielleicht möchten Sie sich diesbezüglich an Ihre Rechtsabteilung wenden, aber für mich scheint es einfach eine schlechte Idee zu sein.

Risiken für den Entwickler

Der Entwickler selbst geht hier ein paar Risiken ein. Im Speziellen:

1. Er riskiert, schlechte Gewohnheiten im Zusammenhang mit Timeboxing und nachhaltiger Trittfrequenz zu entwickeln.
2. Er riskiert eine schlechte Work-Life-Balance, die ein nachhaltiges Tempo bei der Arbeit erschwert.
3. Er läuft Gefahr, das kollektive Eigentum am Code aus den Augen zu verlieren, indem er Teile des Codes als „seinen“ betrachtet.
4. Er riskiert, sich eher mit der Codequalität seiner Beiträge zu identifizieren als mit der Fähigkeit des Teams, innerhalb eines Zeitfensters einen Mehrwert zu liefern.

Das ist eine interessante Situation, die du da beschreibst!

Natürlich kann man es dem Entwickler nicht verwehren, in seiner Freizeit nach einer Lösung zu suchen. Allerdings muss eine klare Trennung zwischen Freizeit und Projekt erfolgen. Wenn er am Code des Projekts arbeitet und eine Lösung versucht/integriert, ist die Trennung nicht mehr klar. Dies ist ein Problem, das Sie als Scrum Master verhindern müssen.

Ich habe vor nicht allzu langer Zeit eine ähnliche Situation erlebt: Ich habe in einem Studententeam an einem 1-Jahres-Projekt gearbeitet. Wir haben Scrum verwendet. Ein Kollege war sehr daran interessiert, eine elegante Lösung für die Bootstrapping-Logik unseres Programms zu finden. Trotz unserer "funktionierenden Lösung" verbrachte er mehr Zeit damit, eine noch bessere zu implementieren; aus persönlichem Interesse. Es stellte sich als komplizierter heraus, als er erwartet hatte, aber da er bereits viel Zeit investierte, verbrachte er immer mehr. Am Ende reduzierte dies effektiv seine Arbeitszeit, denn nachdem er viel Zeit mit dem Thema verbracht hatte, würde er nicht so lange an etwas anderem arbeiten. Er hatte vor, die Aufgaben zu trennen, aber das gelang ihm nicht, weil irgendwo in seinem Kopf Projektarbeit noch Projektarbeit war.

Soviel zum Risiko. Das Ende der Geschichte ist: Der Entwickler kam mit einer sehr eleganten Lösung, die uns seitdem viel Arbeit erspart hat. Ich weiß nicht, ob er so viel ausgegeben hat, aber am Ende könnten einige sagen, dass es sich gelohnt hat.

Der Unterschied zwischen meinem und Ihrem Projekt besteht jedoch darin, dass wir Studenten waren, während Sie Angestellte sind. Das macht die Trennung vielleicht einfacher, aber in meinen Augen auch wichtiger. Vor allem, wenn die Bestellung Ihnen bereits (mehrmals) zusätzliche Zeit für das Problem gegeben hat und Sie es nicht beheben konnten. Wenn es für ihn ein Eckfall ist, der keine weiteren Anstrengungen wert ist, dann ist dies seine Entscheidung. Entwickler sehen solche Dinge tendenziell anders, besonders wenn ihr persönlicher Stolz im Spiel ist. Aber es ist die Entscheidung der PO. Das muss die Mannschaft akzeptieren. Zeitraum.

Wenn er einen Workaround für den Fehler im Open-Source-Framework finden möchte, kann er das zu Hause in seinem eigenen Setup tun. Er sollte nicht von der Firma aus daran arbeiten oder den Code des Projekts verwenden. Sollte er auf eine Lösung kommen und trotzdem Interesse an der Integration haben, kannst du nochmal mit dem PO sprechen. Dann kannst du ihm sagen, dass es so und so viel Aufwand wird und du weißt es, weil dein Entwickler es tatsächlich schon ausprobiert hat und es funktioniert hat. Wenn es nicht zu viel Arbeit ist, bin ich mir ziemlich sicher, dass die PO die Änderung akzeptieren wird. Schließlich will er ein robustes Produkt.

Hoffe das hilft etwas.

Als Scrum Master habe ich dem Entwickler gesagt, er solle aufhören, an irgendetwas zu arbeiten, das nicht vom Product Owner priorisiert wurde, unabhängig davon, ob er Zeit hat oder nicht.

Dies ist ein schrecklicher Ansatz und riecht nach einem Mangel an Führungssinn. Es ist möglich, dass er nicht daran arbeiten sollte, aber es ist auch möglich, dass er sollte. Anstatt zu diktieren, wie es weitergehen soll, müssen Sie einen Dialog öffnen, der Entwickler-Feedback in die Sprints integriert.

Wenn Sie dies nicht tun, werden die besseren Entwickler gehen. Wenn die verbleibenden Entwickler immer qualifizierter werden, werden sie auch gehen, und Sie werden mit hoher Fluktuation, Schulungsaufwand und mittelmäßigen Entwicklern zurückbleiben.

Das ist eine unangenehme Situation. Ich mochte die TL;DR-Antwort sehr und stimme allen unter den Vorteilen voll und ganz zu – Unterstützung von Leidenschaften, persönlichem Wachstum, individueller Investition und Produktqualität.

Die Risiken für das Team könnten leicht durch eine Teambesprechung gemildert werden, um den Wunsch dieses Teammitglieds zu besprechen. Auf diese Weise hat jeder im Team die Möglichkeit, entweder Unterstützung oder Bedenken diesbezüglich zu äußern. Fällt die Entscheidung dafür, geht das Team als Ganzes das Risiko ein. Wenn es nicht geht, wird diese Entscheidung vom Team weitergegeben, nicht von Ihnen, wodurch möglicherweise gezieltere Ressentiments vermieden werden.

Wenn die Aufgabe außerdem aus allen aktiven Sprints entfernt und an das Ende des Rückstands verschoben wurde, was ist, wenn sie aus dem Rückstand entfernt oder auf 0 skaliert wird, um die Geschwindigkeit nicht zu beeinflussen? Es könnte einen schlechten Präzedenzfall schaffen, aber es könnte eine Möglichkeit sein, die Geschichte hineinzuziehen, ohne Geschwindigkeit und Nachhaltigkeit zu beeinträchtigen.