Innerhalb eines recht jungen und frischen Startups habe ich derzeit die Rolle eines Scrum Masters sowie eines Entwicklers inne. Meine Aufgaben sind 50/50 zwischen diesen Rollen aufgeteilt. Die 1,5 Jahre davor habe ich als Vollzeit (FTE) Scrum Master gearbeitet, also ist diese Rolle nicht ganz neu für mich.
Das Team besteht aus 2 Vollzeit-Entwicklern, 1 freiberuflicher Entwickler, 1 sehr begabter Praktikant für QA & Prototyping, einem PO und mir. Insgesamt haben wir also etwa 3,5 FTE-Entwickler, 1 FTE für PO und 0,5 FTE für Scrum Master.
Für den Product Owner (PO) ist es das erste Mal in dieser Rolle, zum ersten Mal in einem Softwareunternehmen und auch zum ersten Mal in einem Software- / Scrum- / Agile-Projekt. Er macht sich sehr gut und lernt recht schnell. Er hat noch einige Ecken und Kanten, aber ich bin mit seiner bisherigen persönlichen Entwicklung zufrieden.
Unter den 2 Vollzeit-Entwicklern gibt es diesen einen, der mein direkter Vorgesetzter ist und Anteile an der Firma hält. Diese Person hat einen gewissen Scrum-Hintergrund, aber meiner Meinung nach einen ziemlich schmutzigen und ineffektiven. Nennen wir ihn einfach Mike.
Um alle Teammitglieder zum Nachdenken über den Scrum-Prozess zu bewegen, habe ich am Anfang jeden nach seiner Rolle im Team gefragt. Mike gab mir die Antwort, dass er nur ein Entwickler sei. Zeitraum.
Im Moment stehe ich vor der Schwierigkeit, dass Mike durch seine organisatorische Rolle Dinge vorantreibt und durchsetzt. Ich als Scrum Master mag diese Situation massiv nicht, da sie dem Prozess schadet und uns auch verlangsamt. Mit drängen und erzwingen meine ich zB
Meine Fragen sind jetzt
Unternehmen haben viele Möglichkeiten in Bezug auf Projektmanagement-Frameworks. Wenn sie sich jedoch für Scrum entscheiden, dann haben sie sich dafür entschieden, sich an die Methodik des Frameworks zu halten. Dazu gehört die Durchsetzung der Scrum-Rollen und Einsatzregeln. Wer den Prozess auf unkonstruktive Weise stört, muss aus dem Team entfernt werden.
Das Versäumnis, störende Teammitglieder zu entfernen, untergräbt den Scrum-Prozess, entmachtet das Team und hindert die Organisation daran, aus dem formellen Scrum-Framework Nutzen zu ziehen. Willst du das sinkende Schiff kommandieren? Wahrscheinlich nicht.
In jeder Organisation hat eine Person drei Möglichkeiten:
Ihr Gründungsentwickler macht keines dieser drei Dinge richtig. Ehrlich gesagt ist dies sowohl aus methodischer als auch aus organisatorischer Sicht nicht tragbar, und Sie erleben bereits toxische Ergebnisse in dieser Situation.
Als Prozessreferent ist es Ihre Aufgabe als Scrum Master, die Organisation über Scrum aufzuklären. Wenn Sie ein unterstützendes Führungsteam haben, müssen Sie es über die Scrum-Rollen, die Notwendigkeit von Work-in-Progress (WIP)-Limits und die nicht verhandelbare Anforderung, alle Prioritäten durch den Product Owner verwalten zu lassen, aufklären. Der Product Owner selbst sollte an Ihrer Seite sein und Sie anfeuern, wenn Sie dies den Stakeholdern mitteilen, denn es wirkt sich auch auf seine Fähigkeit aus, ein effektives Produkt zu liefern.
Da Sie bereits ein privates Gespräch mit dem Gründungsentwickler geführt haben, er weiß, dass er gegen die Kernprinzipien des Frameworks verstößt, und sich nicht verpflichtet hat, seine Vorgehensweise zu ändern, müssen Sie den Rest der Führung engagieren, um ihn aus dem Framework zu entfernen Mannschaft. Wenn sie dies nicht tun, können sie genauso gut den Scrum Master und den Product Owner durch diesen Typen ersetzen und ihn die Projekte auf seine Weise verwalten lassen.
Sie müssen bereit sein, den Scrum-Prozess und die Kapazitätsgrenzen und Selbstorganisationsprinzipien des Teams zu verteidigen. Wenn Sie nicht bereit sind, sie gründlich zu verteidigen, bis hin zum Verlassen der Scrum Master-Rollen (und möglicherweise des Unternehmens), wenn sie sich nicht an den Rahmen halten wollen, den sie selbst gewählt haben, dann stellen Sie sich darauf ein Fehler.
Wenn „Mike“ genug Einfluss hat, um sich durchzusetzen, obwohl er das Scrum-Framework und die Prinzipien missachtet, nennen Sie es einfach Mikes Pseudo-Scrum und lassen Sie ihn für die Ergebnisse verantwortlich sein. Wenn Sie und der Rest des Teams weiterhin so tun, als würden Sie einem formellen Prozess folgen, während Sie wirklich nur das tun, was Mike für wichtig hält, geben Sie Ihre Verantwortung auf und geben stillschweigend Ihre Zustimmung zu dieser Abweichung vom Prozess. Mitglieder des Scrum-Teams, die einem beliebigen Teammitglied erlauben, den Prozess zu kapern, sind zumindest teilweise für alle daraus resultierenden Prozessfehler verantwortlich.
Folgen Sie dem Prozess. Sei nicht „wie Mike“.
Ich denke, Scrum passt einfach nicht perfekt zu kleinen Softwareentwicklungs-Startups. Es ist schwer, sich für einen festen Zeitraum auf einen festen Arbeitsumfang zu binden und zu konzentrieren, wenn täglich neue Erkenntnisse eintreffen und Kunden/Benutzer Ihre Welt verändern.
Kleine Unternehmen brauchen die Flexibilität, ihren Fokus schneller zu ändern, als es Scrum zulässt, es sei denn, Sie machen einwöchige Sprints.
Ich würde vorschlagen, einen Blick auf ScrumBan zu werfen . Die Flexibilität von Kanban und die agile Denkweise, Rollen und Meetings von Scrum. Ein kontinuierlicher Arbeitsfluss und Planungen/Freigaben erfolgen just-in-time. Planen Sie einen schönen Rhythmus für Rückblicke und Retrospektiven ein.
Ich würde privat mit Mike sprechen und darauf hinweisen, dass es in Ihrer Verantwortung als Scrum Master liegt, sicherzustellen, dass der Scrum-Prozess eingehalten wird.
Besprechen Sie mit ihm, was sein Verhalten motiviert. Vielleicht hat er Bedenken wegen Fristen oder der Leistung des Teams? Sobald Sie seine Motivation besser verstehen, können Sie zusammenarbeiten, um einen Weg zu finden, seine Bedenken zu zerstreuen.
Meiner Erfahrung nach ist der beste Weg, diese Art von Problem zu lösen, die Probleme hervorzuheben und Ansätze vorzuschlagen, die die Dinge verbessern könnten. Versuchen Sie, eine positive und konstruktive Atmosphäre zu schaffen, in der das Team bereit ist, sich zu engagieren und sein eigenes Problem zu lösen.