Ich habe in einer Organisation gearbeitet, in der wir Scrum implementiert haben, aber wir haben die Rollen „Junior“ und „Senior“ gestrichen. Ältere Entwickler betrachteten sich selbst immer noch als Senioren (mit all der damit verbundenen Einstellung).
Ich arbeite jetzt als Scrum Master in einer anderen Organisation und denke darüber nach, dieselbe Richtlinie umzusetzen. Aber diese Organisation hat Junioren, Senioren, Qualitätssicherungs- und Entwicklungsmanager. Ich denke darüber nach, alle Titel fallen zu lassen und jeden zu einem Entwickler zu machen und einen leitenden Entwickler in jedem Team zu haben.
Ist das ein praktikabler Ansatz?
Ein Scrum-Entwicklungsteam ist selbstorganisierend und vermeidet die traditionellen hierarchischen Rollen wie zum Beispiel Lead Developer.
Die Idee ist, dass die Teammitglieder führen, indem sie mit gutem Beispiel vorangehen und den Respekt der anderen Teammitglieder gewinnen. Wenn Sie beispielsweise einen sehr erfahrenen Entwickler im Team haben, übernimmt dieser aufgrund des Respekts, den das Team ihm entgegenbringt, oft die technische Führung mit voller Kooperation des Teams.
Die Gefahr bei der Rolle eines leitenden Entwicklers besteht darin, dass andere Mitglieder des Teams entmachtet werden können. Nehmen wir zum Beispiel an, dass 3 Entwickler im Team Ansatz X verwenden möchten, der leitende Entwickler jedoch Ansatz Y verwenden möchte. Die Rolle des leitenden Entwicklers ermöglicht es ihnen, die Meinung der anderen Teammitglieder zu überschreiben. Wohingegen sie in einem Scrum-Team für Ansatz Y argumentieren würden, mit einer guten Chance, den Streit zu gewinnen, da die anderen Teammitglieder sie respektieren.
Der Vorteil dieses Ansatzes besteht darin, dass alle Teammitglieder das Gefühl haben, am Entscheidungsprozess beteiligt zu sein. Das hilft dem gesamten Team, an einem Strang zu ziehen und mit Begeisterung für den gewählten technischen Ansatz zu arbeiten.
Ich denke, Barnaby hat das ziemlich gut auf den Punkt gebracht.
Sie können Erfahrungsstufen in Ihrem Unternehmen haben und sich möglicherweise nicht davon lösen, da die Personalabteilung häufig Berufsbezeichnungen schichtet. Was Sie jedoch allen klar machen müssen, ist, dass es das Team ist, das am gemeinsamen Erfolg oder Misserfolg des Teams gemessen wird. Es gibt keine Rockstars im Team, nur Lehrer und Schüler, die je nach Können austauschbar sein können (Bob ist ein großartiger C++-Programmierer und unterrichtet Sally. Sally ist eine Göttin in Java Script und unterrichtet Bob).
Wenn Sie ein Rockstar-Programmierer sind und Ihr Team Schwierigkeiten hat, Leistung zu bringen, bekommen Sie kein neues Team. Stattdessen werden Sie gefragt: „Was tun Sie, um dem Team zu helfen, besser zu werden?“ Ich nehme so ziemlich jeden Tag ein Team von durchschnittlichen Programmierern, die wirklich gut zusammenpassen, über ein paar individualistische Rockstar-Programmierer.
Es gibt ein neueres HR-Bewertungsmodell, das dies wirklich unterstützt. Anstatt eine Einzelperson auf ihren persönlichen Erfolg hin zu überprüfen, wird das Modell 50/50 zwischen Team- und Einzelentwicklung aufgeteilt. Die ersten 50 % Ihrer Bewertung basieren auf dem Erfolg des Teams. Wenn die Mannschaftswertung 100 % beträgt, erhalten Sie 50 Punkte. Wenn das Team 50 % erreicht, erhältst du 25 Punkte.
Die zweite Hälfte basiert ausschließlich auf der individuellen Entwicklung auf der Grundlage der von Mitarbeiter und Führungskraft festgelegten Ziele. Hast du die neue Sprache gelernt, für die du dich angemeldet hast? Dann erhalten Sie eine hohe Entwicklungspunktzahl.
Der Schlüssel ist, dass nicht der Einzelne an der geleisteten Arbeit gemessen wird, sondern das Team.
Scrum hat nur drei Rollen. Die Verwendung anderer Titel oder Rollen innerhalb des Teams (einschließlich „Lead Dev“) ist sehr stark ein Anti-Pattern von Scrum.
Während Sie im Scrum-Team Personen mit unterschiedlichen Fähigkeiten und Spezialisierungen haben können, hat das Scrum-Framework nur drei Rollen innerhalb des Teams:
Das ist es. Sie können es nicht Scrum nennen, wenn Sie in Ihrem Scrum-Team Rollen wie „Junior Assistant Flunky in Charge of Bending Paperclips“ haben. Es kann eine nützliche Fähigkeit sein, die Ihrem Projekt einen Mehrwert verleiht, aber es ist keine legitime Rolle innerhalb von Scrum.
Das Wichtigste, wofür man arbeiten muss, ist auf jeden Fall die tatsächliche Teamarbeit zwischen den verschiedenen Entwicklern. Es ist unvermeidlich, dass einige älter sind als andere – oft mit sehr unterschiedlichen Fähigkeiten. Die Nummer 1, auf die Sie achten sollten, ist, dass die Leute, die in einer bestimmten Sache sehr gut sind, nicht einfach " von alleine losgehen und es tun". Sie müssen sicherstellen, dass sie anderen zuerst erklären, was sie tun werden (und warum), und dann den anderen zeigen, was sie getan haben. Jeder ist also involviert, jeder bekommt die Chance zu lernen, und unweigerlich fällt jemandem etwas auf, was der erfahrenere Mensch versehentlich übersehen hat.
Der Begriff „Plane die Arbeit, arbeite den Plan“ hat einen Grund. Aber viele Teams, die sich "Teams" nennen, folgen ihm nicht wirklich.
Vor ungefähr einem Jahr wurde ich Teil eines „Teams“, das eigentlich nur aus „Einzelkämpfern in einem Rudel“ bestand. Ihr ehemaliger "Manager" war damit zufrieden, nur ein Vorgesetzter zu sein, fragte sie einmal pro Woche, was jeder von ihnen tat, und beendete das Treffen, indem er ihnen sagte, sie sollten damit fortfahren. Jeder verbrachte seinen Tag damit, an dem zu arbeiten, was „sie“ taten, als ob alle anderen im Raum gar nicht da wären. Für sie war es zunächst ein kleiner Kulturschock – aber alle mussten zugeben, dass „eigentliches“ Projektmanagement den hohen persönlichen Druck, mit dem sie alle zu leben gelernt hatten, stark reduzierte.
Ich denke, dass Scrum ein fantastisches Framework für Softwareprojekte ist. Trotzdem hinterlässt das Vorhandensein dieser drei Rollen eine klaffende Lücke im Team. Unabhängig davon, ob Sie die Titel der Entwickler entfernen oder nicht, ändert dies nichts an der Tatsache, dass es tatsächlich Junior-Level-, Intermediate- und Senior-Level-Entwickler im Team gibt.
Ich habe es so oft gesehen, wo der Product Owner (PO) alle User Stories schreibt. Und natürlich ist dieser PO, auch wenn er es vielleicht einmal in der Vergangenheit war, keine technische Person. Die von einem PO geschriebenen Geschichten sind nicht so technisch wie die technischen Daten früher im Waterfall-Framework. Aber wenn Sie an die Tage von Waterfall zurückdenken, wer hat die technischen Daten geschrieben? Die Senior-Entwickler taten es. Der FA (Funktionsanalytiker) schrieb die Geschäftsanforderungen, und die leitenden Entwickler nahmen diese Anforderungen und erstellten technische Spezifikationen, denen die Entwickler folgen sollten.
Schneller Vorlauf bis heute, diese technischen Daten fehlen. Wenn Sie keine erfahrenen Entwickler haben, die die Entwickler "führen", haben Sie am Ende eine Menge technischer Schulden. Ich habe es gesehen. Ich würde eine kleine Anpassung vorschlagen...
Stellen Sie sicher, dass jedes Entwicklungsteam einen Senior-Entwickler hat und der Rest Intermediate- und Junior-Entwickler sind. Der PO schreibt die Epics und die High-Level-Storys, aber der Senior Developer schreibt die Low-Level-Storys, die den Entwicklern zugewiesen werden.
Und unter keinen Umständen sollte ein PO technische Entscheidungen treffen; diese sollten vom leitenden Entwickler vorgenommen werden, oder sie sollten zumindest die endgültige Zustimmung zu technischen Entscheidungen geben. Ich habe so oft gesehen, dass der PO technische Entscheidungen trifft und darauf basierend Versprechungen gemacht werden, bevor das Entwicklungsteam überhaupt die Anforderungen sieht.
Todd A. Jacobs