Ich arbeite als Softwareentwickler in einem Team von 5 Entwicklern, die 4 verschiedene Projekte entwickeln und betreuen
Ich bin hauptsächlich für 2 Produkte verantwortlich:
1 Entwickler und 1 Praktikant arbeiten an einer Finanzanalyse-App
1 Entwickler und 1 Praktikant arbeiten an einer HR-App, die die Produktivität von Buchhaltern misst
Ich bin ein bisschen ein Tech Lead & Scrum Master im Team, aber nicht vollständig:
Ich hatte einige Entwicklungsaufgaben in den anderen Produkten. Aber jetzt konzentriere ich mich mehr auf meine alten.
Ich helfe den anderen Entwicklern, technische Entscheidungen zu treffen. Aber sie können auch ihre eigenen Entscheidungen treffen, wenn sie sich dafür entscheiden.
Ich bin nicht unbedingt an allen Diskussionen beteiligt, der Product Owner (CEO) kann sich direkt an einen Entwickler wenden und ihm eine Aufgabe geben oder Probleme klären.
Der Entwickler kann sich an einen Designer wenden, um UI und UX zu besprechen.
Ich mache mit jedem Unterteam eine Sprintplanung, aber manchmal bitte ich die Entwickler, mir einige Spezifikationen zu erklären. Kürzlich bitte ich meine Kollegen, das Sprint-Planning ohne mich zu machen, weil ich viel Arbeit in meinen Hauptprodukten habe.
Ich bin etwas verwirrt, weil sie die Details besser kennen als ich.
Ich bin auch dafür verantwortlich, Produktentwicklungsstände in den Management-Meetings zu präsentieren und darüber zu sprechen (der CEO kann diese Rolle in diesen Meetings nicht spielen).
Ich bin der einzige Entwickler, der an den 4 Produkten arbeiten kann. Andere Entwickler arbeiten ausschließlich an einem Produkt. Sie wissen nichts über die anderen Produkte (insbesondere Minen).
Unsere Organisation ist sehr flach, sie fördert Empowerment und wir haben ein Dutzend Produkte (as a Service). Wir haben keine echten Manager, dh nur Chief-Rollen, Entwickler und Helpdesk
Es sieht so aus, als ob SCRUM unsere Bedürfnisse nicht erfüllt, und wir sind agiler als es ??
Ich denke, mein Team arbeitet gleichzeitig an vielen Projekten, und in letzter Zeit führen wir nicht mehr so viele Code-Reviews durch.
Soll ich den Manager bitten, sich abzuwechseln und während eines Sprints oder eines Releases nur an zwei Produkten statt an 4 zu arbeiten?
Sollten wir das Team in 3 aufteilen und Verantwortlichkeiten und Rollen neu definieren?
Gibt es andere Lösungen?
Wenn Sie Teams haben, die nur an einem Projekt arbeiten, können Sie sie bei Scrum-Iterationen belassen. Wenn sie Dinge planen und die Arbeit erledigen können, ohne zu sehr von externen Ressourcen abhängig zu sein (ich denke hier an „Sie“), dann großartig, lassen Sie sie das tun. Soweit ich Ihre Frage entnehme, scheint dies nicht das Hauptproblem zu sein, sondern die Tatsache, dass Sie eine gemeinsame Ressource mit Ihren eigenen Projekten und Verantwortlichkeiten in Managementsitzungen sind.
Wenn Sie Ihre Arbeit in vier Richtungen erledigen, können „Sie“ Scrum nicht wirklich nutzen.
Scrum kann die Lösung sein oder auch nicht (z. B. Scrum mit Teams von nur zwei Personen zu machen, könnte auf der Prozessseite ein bisschen schwerfällig sein, während es gleichzeitig zu wenig auf alle notwendigen Fähigkeiten ankommt, die in jedem Team vorhanden sein müssen ohne dass sie andere um Hilfe und Unterstützung bitten müssen).
Wofür Sie sich auch entscheiden, Sie müssen die gesamte Situation analysieren und sehen, wo die Schmerzpunkte liegen, und erst dann entscheiden, was zu tun ist: Scrum in allen Teams weiterführen, Teams neu organisieren, Rollen neu organisieren, Kanban in allen Teams verwenden, beides verwenden Kanban und Scrum usw.
Soll ich den Manager bitten, sich abzuwechseln und während eines Sprints oder eines Releases nur an zwei statt an vier Produkten zu arbeiten? Ja, ist die kurze Antwort.
Der gleichzeitige Umgang mit vielen Produkten als gemeinsam genutzte Ressource wird immer schwierig sein, unabhängig davon, welche Arbeitsweise Sie anwenden (z. B. in diesem Fall Scrum).
Es hört sich so an, als könnte Ihnen eine bessere Visualisierung der vielen Dinge, die vor sich gehen, dabei helfen, herauszufinden, ob eine Neuorganisation erforderlich ist oder wie Sie die Zeit anders verwalten können. Dies kann mit einem Kanban-Ansatz oder einem anderen Informationsstrahler-Stil erfolgen, der zu Ihnen passt.
Je nachdem, wie streng die Teams Scrum einsetzen, sollten sie theoretisch sowieso nicht an mehreren Produkten arbeiten, da Scrum nicht für solche Prioritätskonflikte ausgelegt ist – stattdessen sollten sie einen Rückstand abarbeiten, auf den sie sich konzentrieren sollten ein Produkt, und jeder Sprint hat ein Ziel usw. Wenn dies der Fall ist, können Sie die Zeit organisieren, indem Sie X Geschichten / Story-Punkte pro Produkt zuweisen.
Das größte Problem bei der Arbeit an mehreren Dingen gleichzeitig sind die Kosten für den Kontextwechsel. Die Reduzierung auf die Arbeit an 2 statt 4 Produkten wird dazu beitragen, diese verlorene Zeit, Mühe und Energie zu reduzieren - da Sie nur an 2 Dinge denken müssen und nicht an 4!
Das Reduzieren kann auch dazu beitragen, ein WiP-Limit (Work in Progress) zu schaffen. Wenn viel los ist, kann es oft hilfreicher sein, langsamer zu werden und die Dinge auf einmal zu erledigen, anstatt mehrere rotierende Platten zu haben, da Sie sich dann konzentrieren, sich anstrengen und die Arbeit erledigen können.
Sollten wir das Team in 3 aufteilen und Verantwortlichkeiten und Rollen neu definieren?
Es hört sich so an, als wäre dies sowohl für Sie in Ihrer Rolle als auch für Ihre Teammitglieder sehr nützlich. Es wird Ihnen helfen, einige Dinge von Ihrem Teller zu nehmen, damit Sie nicht das Gefühl haben, ständig nachsehen zu müssen, und auch andere befähigen, ihre eigenen Entscheidungen zu treffen, ohne sich so stark auf Sie zu stützen. Es gibt online viele Ressourcen für einige einfache R+R-Sitzungen, sehen Sie sich diese an oder schreiben Sie mir eine DM und ich kann Ihnen eine einfach zu verwendende Vorlage zur Verfügung stellen.
Gibt es andere Lösungen?
Ich frage mich, ob eine umfassendere Neuorganisation diskutiert werden muss? Sowie R+R von einer höheren Ebene? B. den CEO bitten, sich zurückzuziehen und das Team ungestört weiterarbeiten zu lassen. Es ist schwer, sich zu konzentrieren und etwas zu erledigen, wenn der Chef immer einwirft: „mach das als nächstes/jetzt/stattdessen“
Je nachdem, wie groß Sie sind, können flache Hierarchien Zusammenarbeit schaffen und Barrieren abbauen oder zur Anarchie beitragen. Wenn Sie also eine wachsende Organisation sind, könnte es sich lohnen, einige Sprungbretter zu implementieren. Nicht, um eine „Genehmigung muss erteilt werden“-Kultur zu schaffen, sondern um dabei zu helfen, R+Rs zu definieren, damit Sie sich alle auf Ihre Arbeit konzentrieren können. Es ist auch möglich, sowohl eine Hierarchie als auch eine super offene, ehrliche und kooperative Kultur zu haben!
Hoffe, das ist hilfreich!
RL.
reda la
Mike Robinson
Bogdan