Hoe krijg ik weer controle over mijn "zelforganiserend" team?

Je geeft de scrummaster een rare blik, en je zegt “bye Felicia,” en de volgende dag bel je een vergadering van het hele team en vraagt ze wat die verdomde onzin was.

Als dit echt gebeurde, dan zou ik de idiote scrummaster in een New Yorkse minuut ontslaan. Deze scrummaster is gevaarlijk, onprofessioneel en ongeschikt voor zijn werk. De manier om daadwerkelijk “je manager te ontslaan” is door te stoppen: hij heeft in principe alleen maar ontslag genomen voor het hele team.

Ik begrijp niet waarom je je zorgen maakt. Ze zitten allemaal onder je in de hiërarchie, en hebben niet de kracht om je te ontslaan.

Nog belangrijker, je moet uitzoeken wat er verdomme aan de hand is. De scrummaster zelf moet misschien worden beëindigd, afhankelijk van de situatie.

Doe het voordat het te laat is, voordat je baas (of CIO) hetzelfde tegen je zegt.

Hoewel ik met een aantal teams heb gewerkt die dezelfde werkwijze hebben gevolgd, klinkt het niet alsof er met de nodige zorg mee is omgegaan. Ik wil graag delen wat ik heb gezien om te zien of het helpt om je een weg vooruit te helpen.

Ten eerste, Scrum moedigt zelforganiserende teams aan. Wat de Scrum gids specifiek zegt over zelforganiserende teams is dit:

Ze zijn zelforganiserend. Niemand (zelfs de Scrum Master niet) vertelt het Development Team hoe ze de Product Backlog kunnen omzetten in Increments of potentially releasable functionality;

Dat, samen met veel andere zaken over cross-functionele en brede verantwoordelijkheid, is bedoeld om teamleden aan te moedigen zichzelf harde vragen te stellen over hoe goed ze zijn ingesteld om de verzoeken die bij hen opkomen in de praktijk te brengen. Het is zeker de moeite waard om de Scrum Guide te lezen - het is kort.

Wat betreft een manager, als je hebt ontdekt dat je werk in het verleden taken en het bijhouden van werkitems heeft toegewezen, vraagt Scrum je wel om een stap terug te doen. Eerlijk gezegd, als de Scrum Master hier niet lang voor de eerste terugblik met je over gesproken heeft, is dat misschien een beetje een misser geweest van zijn kant. Een harde realiteit is echter dat veel teams die gewend zijn aan een manager die hun taken voor hen regelt, niet goed voorbereid zijn om gewoon in deze aanpak te springen. Als je het gevoel hebt dat je team zich in deze situatie bevindt, raad ik je aan om er met de Scrum Master over te praten. Er zijn veel technieken om deze overgang te vergemakkelijken. In het bijzonder zou ik kijken naar David Marquet’s Ladder of Leadership en misschien zelfs naar zijn boek Turn the Ship Around. Je zult merken dat in beide gevallen geen enkele manager wordt ontslagen.

Tenslotte, laten we eens kijken waarom je deze overgang zou willen maken als je succes hebt met het managen van mensen in het verleden. De korte versie is dat je nog meer succes zult hebben door hen te helpen zichzelf te leren managen. Er is zoveel onderzoek en data over dit onderwerp, dat het moeilijk is om te weten waar je moet beginnen - maar ik zal zeggen dat het een vrij goed gedemonstreerd feit is dat alle mensen potentieel in staat zijn om zichzelf te organiseren en in een team van bijvoorbeeld tien, elf hersenen (de jouwe inbegrepen) altijd effectiever problemen zullen oplossen dan één en met nog eens tien aan de kant om de schuld op je te schuiven als de oplossing fout is.

Ik heb veel succesvolle managers gezien in Scrum-omgevingen. Ik zou een team altijd waarschuwen tegen het “ontslaan” van een team. Zelfs als je intimiderend bent zoals je vraag zegt en je beheert elke taak die voor hen ligt, heb ik met veel van dit soort managers gewerkt die nog steeds geweldige troeven zijn voor het team. In deze zelforganiserende teams, verschuif je van het besteden van al je tijd aan het sturen van de acties van het team naar het zorgen dat het pad voor hen om te slagen duidelijk is en het komt altijd beter uit over de hele linie met teams die meer leveren en managers met een reputatie voor het creëren van rockstars.

Veel succes, ik hoop dat dit geeft je een aantal invalshoeken om mee te werken.

• In de context van scrum: Wat zegt de eigenaar van het product? Het is niet de functie van de scrummaster om meer (of minder) middelen te vragen. Dit is iets wat de producteigenaar moet afstemmen met de stakeholders

• In de context van scrum: Een retrospectief gaat over het proces en het team en het project (niet over “hoe voel ik me bij mijn baas”). Als je deel uitmaakte van het team, had je uitgenodigd moeten worden. Als je geen deel uitmaakte van het team, had de retrospectieve alleen je rol in het project moeten behandelen.

• scrummasters die lijnmanagers vertellen wat ze moeten doen zijn minstens zo absurd als lijnmanager die zich direct met scrum bezighoudt

Dus de scrummaster heeft duidelijk zijn grenzen overschreden. Het was zijn functie om de retrospectieve focus te houden op het identificeren van specifieke problemen die moeten worden aangepakt.

Hoe verder te gaan:

• Je praat met het team in één-op-één sessies en vraagt hen wat er aan de hand is. Je legt duidelijk uit dat de scrummaster niet een lijnfunctie is en dat hij niet de teams samenstelt. Vraag ook waar ze vinden dat je uit de dagelijkse gang van zaken had moeten blijven

• maak het team duidelijk aan wie de problemen aangepakt moeten worden

• Je gaat naar de volgende in de rij (als dat de CIO is, is het de CIO - het is niet acceptabel dat je al maanden geen manager hebt), waarin staat dat de situatie onmiddellijk moet worden opgelost (door de scrummaster te ontslaan of de CIO met hem te laten praten dat hij op de huidige cursus wordt ontslagen), anders brengt het het project in gevaar - voor mij klinkt het alsof de scrummaster zijn taken en grenzen niet begrijpt. Een professioneel antwoord aan het team dat probeert hun manager te “ontslaan” als onderdeel van een retrospectief zou zijn geweest “Het is niet mijn zaak om de relatie tussen u en uw baas te regelen, en het is zeker niet waar het project ons voor betaalt”.

Ik heb het team gewezen op de voordelen van zelforganiserende teams en team empowerment.

Nou, ze hebben zeker dat deel ter harte genomen.

Het lijkt duidelijk dat je op dit moment in een zeer emotionele situatie verkeert. Blijkbaar heeft je team een aantal grote problemen met de huidige relatie tussen jou en hen. Het was waarschijnlijk een goede zaak dat je niet op de terugblik was, want dat is meestal de reden dat mensen ineens bereid zijn om zich uit te spreken over wat hen echt dwarszit. Als ze het willen doen rond een Scrum Master waar ze pas een paar weken mee werken, dan vertrouwen ze de man al of zijn ze zo geïrriteerd dat ze zich niet echt bekommeren om de gevolgen.

Hoe dan ook; dit is geen nieuw probleem dat plotseling opdook toen je overstapte naar Scrum of een nieuw persoon inhuurde. Dit is een probleem dat al heel lang onzichtbaar is. Vaak wordt gesteld dat het werken Agile niet zozeer nieuwe problemen oplevert, maar de reeds bestaande extreem voor de hand liggend maakt. Dit is waarschijnlijk een geval van dat.

Dat gezegd hebbende; je Scrum Master liet de bal vallen, hard. Het is zijn taak om het team te helpen groeien naar zelforganisatie, zeker. Maar dit is niet de juiste manier. Ten eerste, hij kan je niet werkelijk ontslaan, en alleen maar zeggen “dit is wat het team wil” is volledig niet-constructief. Ik weet niet zeker wat hij denkt dat dit gaat opleveren, maar het kan niet goed zijn wat het team denkt dat het is.

Ook het verwijderen van mensen is de moeilijkste keuze die een team of Scrum-Master ) kan maken en moet nooit lichtvaardig en zonder (herhaaldelijk) te praten met de betrokkenen worden genomen. Je kunt niet zomaar iemand verwijderen die niet weet dat iemand een probleem heeft met hem of haar. Als er niets anders is, gaat het iedereen bang maken dat als ze een retrospectieve missen, ze ineens weer aan het werk gaan om te ontdekken dat ze uit het team zijn gestapt. Het gaat een sfeer van angst creëren, niet van vertrouwen. Een sfeer van vertrouwen en openheid is wat je wilt als je Agile werkt.

Dus met je Scrum Master die er niet in slaagt om te werken aan een open sfeer (tenminste buiten het team; het lijkt erop dat hij mensen intern nogal wat open heeft gekregen) en niet op zoek is naar een constructieve oplossing, lijkt het op jou te vallen om het te doen.

Op dit punt denk ik niet dat iets op basis van autoriteit nuttig zal zijn. Scrum en Agile gaan over het empoweren van mensen om hun eigen ding te doen, en je autoriteit te laten gelden op dit punt zal waarschijnlijk eindigen met het hele team te worden ontslagen. Het team heeft al verklaard dat ze op het punt staan dat ze willen dat mensen weggaan, dus terwijl ze de persoon misschien verkeerd hebben ingeschat, zal het samen met hen waarschijnlijk eindigen met ten minste een paar mensen die weggaan. (En onthoud de belangrijkste regel over weggaan: de meest waardevolle mensen zullen als eerste gaan.)

Dus als je echt Scrum wilt doen met dit team, is dit waar je hun vermogen moet accepteren om te beslissen hoe ze willen werken en een open discussie moet voeren over hoe ze hun team willen organiseren. Ze kunnen je niet ontslaan, maar ze hebben duidelijk gemaakt dat wat je nu doet niet voor hen werkt. Je moet een gesprek hebben over wat je rol in de toekomst gaat worden, wat ze van je nodig hebben, wat je nodig hebt, en hoe dat allemaal geregeld gaat worden. Hou er rekening mee dat ze mogen beslissen _ hoe_ ze werken, maar uiteindelijk is er toch een product dat geleverd moet worden; ze _zullen worden beoordeeld op de kwaliteit van wat ze leveren. En als er organisatorische dingen zijn die je van hen nodig hebt, zullen ze die dingen ook moeten doen. (Dat gezegd hebbende; werk samen met hen aan de vorm van die dingen, en zorg ervoor dat ze echt nodig zijn voordat je ze afdwingt).

Zorg ervoor dat je in die vergadering de dingen niet benadert vanuit je autoriteit; het hele idee is om iedereen op hetzelfde niveau te krijgen. Je bent collega’s en individuen die allemaal een taak hebben, allemaal goed werk willen doen, en allemaal samen moeten werken op een dagelijkse basis. Het feit dat je een autoritair iemand bent, maakt mensen meestal alleen maar vijandig tegenover elkaar, wat niet productief is. Dus probeer hier kwetsbaar te zijn, en wees bereid om de dingen toe te geven die je fout hebt gedaan. Je moet uitzoeken hoe je van hieruit als mens te werk gaat.

Het klinkt alsof je team de Stormphase van hun ontwikkeling als team heeft geraakt, en ze raken het hard. Nu is het aan het team (en ik neem jou erin op, althans voor nu) om uit te zoeken hoe je van daaruit verder moet gaan. Wees gewaarschuwd; niet alle teams komen uit deze fase en ik kan niet beloven dat deze aanpak het probleem gaat oplossen. Ik kan wel garanderen dat het niet worse is dan stoppen of iedereen ontslaan.

En zorg ervoor dat je apart met de Scrum Master praat. Ik weet niet zeker wat de oorzaak is dat hij met zo'n niet-constructief eerste bericht opent, maar hij moet werken aan zijn communicatie en probleemoplossende vaardigheden.

Veel succes met uw situatie. Je leeft zeker in interessante tijden; maak er het beste van en leer wat je kunt.

(ik ga er ook vanuit dat de Scrum Master niet het hele team tegen je in opstand zal brengen zonder dat er serieuze onderliggende problemen zijn. Als hij dat kan en hij hengelt naar je baan, dan is hij een meester-manipulator. Zodra je het punt bereikt waarop je denkt dat dat het geval is, moet je je ontdoen van die kerel asap. Dat is waarschijnlijk het enige geval waarin ik zou overwegen om uw autoriteit te gebruiken als de persoon die hem heeft ingehuurd en de man te ontslaan).

Of ze nu wel of niet de macht hebben om je te ontslaan als hun manager, je bracht deze situatie op jezelf door een verandering van scrum op te leggen, simpelweg omdat je dat liever hebt. Je hebt het niet met hen besproken. Je mag dan binnen je rechten als manager zijn geweest, maar het was toch een domme zaak, en natuurlijk vragen ze zich nu af of ze nog wel voor je willen werken.

Zie je het sarcasme in hun claimen van zelfredzaamheid en zelforganisatie niet als hun basis om zo'n actie te ondernemen?

Je moet morgen om 9:15 uur een vergadering beleggen en je verontschuldigen voor het maken van zo'n belangrijke beslissing zonder rekening te houden met hun inbreng. Je kunt dan hun feedback vragen over hoe ze dachten dat hun eerste sprint ging, en wat er anders had kunnen gebeuren.

Als je een nieuwe workflow in het proces van dit team wilt introduceren, kun je het misschien op kleinere schaal proberen, met specifieke taken als pilot-programma, met een select aantal leden van het team die open genoeg zijn om het een eerlijke evaluatie te geven.

Met geautoriseerde medewerkers is het beter om te overtuigen, op te nemen en aan te moedigen dan om het te mandateren.

Een ander perspectief: is het bij u opgekomen dat ze het Scrum-proces en het “zelforganiserende” aspect ervan gewoonweg uitlachen? Eerlijk gezegd kan ik me niet voorstellen dat ze serieus waren en goed hebben gelachen bij het lezen van je post. Softwareontwikkelaars (ik ben er een) hebben de neiging om behoorlijk cynische mensen te zijn met een droog gevoel voor humor die niet iedereen leuk vindt of zelfs maar herkent. Ik weet zeker dat ze je gewoonweg vertelden dat ze Scrum niet leuk vinden.

Misschien is de beste manier om met een aantal van hen informeel te praten over Scrum en de redenen waarom ze het niet leuk vinden.

Come @Sascha ha correttamente osservato , questo non assomiglia affatto a Scrum:

• Un team di Scrum non ha un manager, risponde invece ad un Product Owner. Il Product Owner rappresenta gli interessi degli azionisti nei confronti della squadra, organizza le consegne per lo sprint all'inizio, accetta i risultati alla fine e nel frattempo chiarisce le richieste della squadra. È essenzialmente un delegato tra la squadra e l'azienda.
• Se facessi parte della squadra di Scrum, parteciperesti ad una riunione retrospettiva. Se non fai parte del team della Mischia, la riunione avrebbe dovuto essere limitata al tuo ruolo per quanto riguarda il team all'interno del modello della Mischia.

Quindi, la domanda è: Da che parte stai in questa foto? Qual è il tuo ruolo all'interno del modello di Scrum? **Da quando sei stato tu la cui idea di provare Scrum è stata in primo luogo, ** hai sicuramente fatto ricerche su Scrum e ci hai pensato prima di suggerirlo, no?**

E se non l'hai fatto, è il momento di farlo ora. La transizione più semplice per un manager se non è considerato parte del team quando si passa a Scrum è il Product Owner. Continuerai a fare la stessa cosa - ma ora il team risponde a te collettivamente piuttosto che a ogni membro individualmente, e smetti di gestirli a meno che non te lo chiedano espressamente (quest'ultimo è probabilmente una buona cosa per entrambe le parti).

Vedendo che apparentemente hai fatto un errore critico di ricerca quando hai suggerito Scrum, credo che tu non abbia organizzato un Product Owner dedicato - quindi sei esattamente nella posizione di assumere questo ruolo ora.

** Questo non nega il fatto che il Master Scrum non ha idea di quello che sta facendo, o lo sta facendo dopo il tuo lavoro** - quali altre risposte hanno coperto adeguatamente come andare avanti.

*Hoe kan ik deze situatie onschadelijk maken en mijn autoriteit als hun manager herstellen, terwijl ik trouw blijf aan de principes van zelforganisatie en team empowerment van agile? *

Sinds wanneer ben jij de manager van dit team? Ik denk niet dat een team in opstand zal komen tegen de directe manager voor een meningsverschil over slechts 1 onderwerp. Het probleem kan ernstiger zijn dan alleen de agile methode.

Dit is iets belangrijks voor een manager en je moet het aanpakken, het zou je eerste prioriteit moeten zijn voor de komende weken.

Je n+1, n+2 zijn met verlof voor enkele maanden? misschien heeft het je team wel beïnvloed om in opstand te komen. Wat is de financiële status van je bedrijf ? ( als het slecht is, denken de werknemers misschien dat je het slecht doet en het beter kan zonder jou).

wat moet je doen : - organiseer een vergadering met het hele team : “scrum master vertelde me dat je me wilt ontslaan, wat is er aan de hand ?” (het is heel belangrijk dat je het onderwerp aan iedereen vertelt omdat ze het allemaal kennen en als het het dagelijkse werk beïnvloedt). -identificeer het echte probleem (alleen deze agile methode of heb je al eerder een probleem met het team?). -als u het echte probleem kent, moet u onderzoeken: wie heeft er gelijk? u of uw medewerkers? -identificeer wie de leider is van deze rebellie (er is altijd een medewerker die de autoriteiten meer tart dan de anderen). Als u denkt dat hij buiten zijn boekje gaat, moet u disciplinaire maatregelen nemen.

Ik weet niet zeker wat een ‘manager’ betekent in uw bedrijf, maar in het algemeen denk ik dat het iemand betekent die de teams helpt en hun prestaties verhoogt. Nu:

Ik ben een groot voorstander van agile, dus ik heb een scrummaster ingehuurd en gezegd dat we scrum zouden volgen.

klinkt meer als ‘ik heb een geweldig idee’ ik wil dat jullie het doen. In plaats van het team eerst te consolideren over jullie idee. Ik denk dat elk team het recht heeft om je idee te bekritiseren en gaten in je idee te schieten. als je idee niet houdt, zou je het moeten kunnen laten vallen.

Het is onzeker of het idee houdt kan het team vertellen dat je een try-out periode wilt en/of langzaam migreren naar de nieuwe projectstructuur.

Op deze manier kun je nog steeds op weerstand stuiten, maar waarschijnlijk niet zoveel als je nu hebt.

denk ik om samen te vatten: Je bent hun manager, niet hun baas. dat zijn twee zeer onderscheidende banen!

“De code is meer wat je noemt "richtlijnen” dan echte regels.“ - Kapitein Barabossa

Het klinkt alsof je in een moeilijke situatie verkeert, en je probeert vast te houden aan enkele onredelijke idealen.

Ik heb het team gewezen op de voordelen van zelforganiserende teams en team empowerment.

Leg je _kinderen uit dat zelforganiserende en empowerment niet betekent dat ze alles kunnen doen wat ze willen. Als je team besloten heeft om wat automatische wapens te gaan stelen en een bank te beroven, ben je niet verplicht om met hen door te gaan, alleen maar omdat ze gemachtigd zijn.

Ze kunnen je niet "ontslaan”. Dat is de rol van je manager. Vuren komt altijd van bovenaf, niet van onderaf. Tuurlijk, ze kunnen in de hiërarchie springen en met je baas werken om je te verwijderen, maar aangezien blijkbaar je baas en je baas beiden met verlof zijn zonder dat ze iemand op hun plaats hebben gezet in hun afwezigheid, is er niet veel van een hiërarchie om naartoe te gaan. Je hebt een paar maanden.

Ik heb de scrummaster verteld dat ik hier met het team over wil praten, maar hij was vastbesloten dat ze zich “geïntimideerd” voelden toen ik in de kamer was, en dat ze het niet met mij wilden bespreken.

Nou dat is gewoon te erg voor ze. Praat toch met ze. Self empowerment geeft je misschien de mogelijkheid om je eigen beslissingen te nemen, maar het bevrijdt je niet van de verantwoordelijkheid om die beslissingen na te leven. Als ik zo'n team zou hebben, zou het praten met hen het kindest niveau van respons zijn dat ik zou overwegen.

Men zou kunnen zeggen “Oh, maar de SCRUM-meester wordt verondersteld om belemmeringen als deze op te lossen”. Alles zou via hem moeten gaan.“ Nou ja, moeilijk. Hij verpestte dat toen hij naar je toe ging om je te vertellen dat je ontslagen was en faalde om dat te doen op een voldoende hoffelijke manier dat je het accepteerde. Van een SCRUM-meester wordt verwacht dat hij betere vaardigheden heeft dan dat.

Dus wat zeg je ervan?

Eerst wil je weten of ze je daadwerkelijk hebben "ontslagen”. Je hebt het woord van één persoon, en ik geloof dat dit het soort situatie is waar het team direct hun stuk moet kunnen zeggen.

Ten tweede, denk na over wat “ontslaan” betekent. Je beweert dat je een hands off manager bent, maar ze willen je weg hebben. Ze schrijven de loonstrookjes niet, dus de beslissing om je te ontslaan is niet een “oh ze trekken hun gewicht niet in de schaal” soort beslissing. Dat is een “deze persoon staat actief in de weg” soort beslissing. Iets wat hier niet klopt. Je hebt het nodig om het voor je op te tellen voordat je zinvolle beslissingen neemt. Als anoniem persoon op het internet, kan ik niet zeggen of het jou of hen of de SCRUM-meester is, maar something is echt heel erg verkeerd in dit scenario, en je kunt beter weten wat het is tegen de tijd dat je klaar bent met praten met hen.

Werk met hen. Wees een manager. Vind een manier om het probleem op te lossen. Vind een manier voor u om uw werk te kunnen doen, terwijl zij het hunne doen. Maak het mogelijk.

Nu, als hun antwoorden je voldoende afsluiting bieden om hun zelfredzaamheid te eren, moet je het team laten zien wat er gebeurt als je zo'n leiderschap “ontslaat”. Zeg “Prima. Ik zal stoppen met het optreden als je manager. Je kunt me niet _ eigenlijk_ ontslaan, want dat is niet jouw positie, maar als je dit spel wilt spelen, dan kunnen we dat wel. Ik was je manager. Ik hielp je te isoleren van de bedrijfspolitiek en de stress van het rapporteren aan het hogere management. Nu ben ik je hoger management, en je hebt die isolatie niet meer. Nu, omdat ik mezelf niet echt uit deze positie kan verwijderen, zal ik in plaats daarvan gewoon beginnen met het doorgeven van taken van bovenaf.” Leg dat maar eens uit omdat het team heeft gestemd, dat betekent niet dat je geen verplichtingen hebt aan het hoger management die je moet nakomen, en dat zal blijven doen.

Dan, haal hulp.

Een muiterij is geen kleinigheid. Je hele team heeft je net van het eiland gestemd. Onderschat het niet. Haal iemand boven je om te helpen. Misschien bel je je baas met verlof. Misschien praat je met je CIO. Iemand moet weten dat er een major mensenprobleem is in je bedrijf, _ en dat je het oplost._ De tweede helft is duidelijk belangrijk. Ga nooit naar leiderschap met problemen, ga naar hen met oplossingen.

De oplossing die ik zou aanraden is om je imago als de “manager die eisen stelt” te bewerken door dingen te kiezen om te eisen welke leiderschap (d.w.z. CIO) zou willen, die is gemaakt om wat zelfrealisatie op te bouwen om te gaan met deze zelfempowerment. Ze denken misschien dat ze vrij zijn om te doen wat ze willen, maar u bent nog steeds verplicht om van hen een succesvol team te maken._ Als u het van ver moet doen, doe het dan van ver. Zoek uit wat er zo intimiderend was aan uw hands-off aanpak, en zorg ervoor dat u dat nooit doet.

Het einddoel is om hen te laten beseffen dat u aan hun kant staat. Als ze echt zelfredzaam zijn, dan moeten ze tot het besef komen dat je een voordelig deel van het team bent. Ze zullen alleen tot dat besef komen als ze succesvol zijn. Als ze overspoeld worden met onmogelijke deadlines en hopeloze bureaucratie, ze zullen het nooit zien.

Zorg er gewoon voor dat het allemaal klopt. 2+2=4. Een “hands off” manager wordt “ontslagen” door de nieuwe SCRUM-meester omdat hij te intimiderend is terwijl twee lagen van het management met verlof zijn? Iets klopt hier niet. Je bent dichter bij de situatie. Zoek uit wat niet klopt, en los het op.

Ofwel: a) Ze hebben gelijk en je hebt je bestaan niet gerechtvaardigd. (Ze kunnen je nog steeds niet ontslaan) of b) De scrummaster wil je baan.

Ik denk dat het beste voor je is om een 2 daagse scrummaster cursus te gaan doen en je scrummaster kwijt te raken. Je kunt dan waarschijnlijk aan het eind van het jaar een bonus krijgen voor het doen van twee klussen.

Er is geen manager rol in een scrumteam. De echte vraag is waarom je dacht dat je in de eerste plaats een teamlid was. Als je niet deelneemt aan feature delivery, heb je geen plaats in dat team - dus wat het team deed was correct.

Als ze je als een belemmering beschouwen, zoek dan uit waarom - het waarschijnlijke scenario is dat je je er mee bemoeit, en de oplossing is dat je je ermee bemoeit en hen hun werk laat doen.

Wat denk je dat je rol in het team is? Kom met een nuttig antwoord dat in lijn is met de doelen van scrum, benadruk dan aan het team dat je van plan bent dat werk te doen, en bemoei je niet met dat van hen.

Dus ik zie niet in waarom je dit niet als iets positiefs kunt zien? Ik heb begrepen dat het doel van een zelfsturend team ** is om geen manager** nodig te hebben.

Wat je moet doen is kijken naar de mogelijkheden die dit biedt. Je hebt in principe een superteam dat zichzelf kan managen en nu ben je in staat om het volgende te doen:

• Je bent in staat om het team makkelijker verantwoordelijk te houden voor de verplichtingen van het bedrijf. Als ze niet kunnen voldoen aan de bedrijfsdoelstellingen, dan kunnen ze gewoonweg geen zelfsturing geven aan
• Je bent in staat om de vaardigheden in het team te laten groeien. Dus nu kun je je meer richten op het menselijke aspect van het team. Carrièregroei, enablement en dat soort dingen.
• Realiseer je dat het team + de scrummaster nog steeds aan je verantwoording afleggen in de bedrijfshiërarchie, de budgetten en het prestatiebeoordelingsproces. Het is dus niet zo dat ze over je heen kunnen gaan.

Zie dit dus voorlopig als een succes. Denk meer aan de mogelijkheden om het team te versterken. Besef ook dat je er moet zijn voor het scenario waarin deze zelfsturende aanpak faalt.

Lao Tzu zei

De slechte leider is degene die het volk veracht,

De goede leider is degene die het volk veracht,

Wanneer een grote leider leidt, zeggen de mensen “we hebben het zelf gedaan”.

Een leider is het beste wanneer mensen nauwelijks weten dat hij bestaat,

wanneer zijn werk gedaan is, zijn doel bereikt,

ze zullen zeggen: we hebben het zelf gedaan.

en ik volgen deze spreuk eigenlijk al sinds dag 1 van het leiden van de ontwikkelteams. Als iedereen weet wat hij moet doen, dan ben ik niet nodig en is mijn werk het best gediend op deze manier - genieten van het leven buiten kantoor.

Je volgt de metriek, controleert hun code, je doet kleine koerscorrecties, je moedigt & activeert wat nodig is om te stimuleren en mogelijk te maken - communicatie, samenwerking, het schrijven van testen etc, je schermt ze af van het hogere management & de klanten - en idealiter handel je nooit.

Maar als je dat wel doet, dan doe je dat wel en je schopt je neus als het nodig is, je bent immers de man die verantwoordelijk is voor hun werk - mensen worden immers op jouw aanbeveling ontslagen en je zou moeten ontslaan, en op tijd.

Ik weet niet zeker waarom een ontwikkelaar iemand zou ontslaan die hen niet in de weg staat en die er in principe is om dingen voor hen te repareren en hen te beschermen tegen klanten en af en toe zelfs hogerop, zorgt voor de beschikbaarheid van apparatuur, documentatie, duwtjes in de rug om betere programmeurs en betere mensen te zijn en stelt hen in staat om zich te concentreren op code.

Je bent nog steeds hun hogerop - je kunt ze nog steeds ontslaan als dat nodig is, je bent niet ontslagen vanuit deze positie. Je werd gewoon nutteloos geacht of schadelijk voor de ontwikkeling en ze spelen liever zonder jou.

Ofwel dit ofwel is er een serieuze pathologie aan de gang met de teamcultuur.

Ik zou zeggen dat het een geweldige kans is voor wat grote reflectie en groei.

Ik zie hier twee standpunten:

• U was de lijnmanager van een ontwikkelingsteam in een matrixorganisatie, en u bent nog steeds de lijnmanager. Je baan is misschien een beetje veranderd, maar het is fundamenteel hetzelfde - je geeft de ontwikkelaar man-dagen aan de PO in overeenstemming met de bedrijfsbudgetterings-/HR-processen, je zorgt voor de werving (en indien nodig, het ontslag), je plant vertrekt in samenwerking met het team, enzovoort. In agile ontwikkeling is je rol misschien iets minder gek dan vroeger, maar vooral als er meerdere scrum-teams zijn zal je rol nu dingen bevatten als het aanmoedigen van “communities of practice” of “guilds”. Zoals alles kan scrum schadelijk zijn als het tot het uiterste wordt gedreven, en somebody moet er bijvoorbeeld voor zorgen dat technologiestacks compatibel blijven, tenzij er een zeer goede reden is om een uitzondering te maken. Dat is de taak van het lijnmanagement in zo'n organisatie.
• Je was een lid van het ontwikkelteam en je had directe input in technologiebeslissingen, architectuur, enzovoort. In dat geval stel ik voor dat je het verprutst hebt door je niet genoeg in te zetten voor deze eerste sprint, omdat ze niet zien hoe je je vaardigheden in het team gaat inbrengen. Werk in de volgende sprint samen met het team.

Ik ben een manager van een ontwikkelingsteam.

Ik ben een groot voorstander van wendbaar

Goed! Als je met “agile” “Scrum” bedoelt (waarom zou je anders een Scrum Master hebben ingehuurd…), dan is alles goed.

Ze hebben van oudsher een zeer watervalmethode gevolgd en zijn bestand tegen verandering.

het team heeft collectief afgesproken om mij te “ontslaan” als hun manager

Good! Ze hebben hun manieren veranderd; ze hebben hun weerstand laten vallen (je hebt ons niet verteld waar ze zich tegen verzetten, voor…). Ze hebben de rollen rondom een Scrum Team geleerd.

Zoals u zeker weet, heeft een manager slechts een zeer verregaande verantwoordelijkheid in de context van een Scrum Team; u bent noch de Scrum Master, noch de Product Owner, noch een van de Stakeholders, noch een onderdeel van het Scrum Team zelf. Ik herinner me dat ik mijn Scrum Master certificaat haalde in een 3-daags seminar; de rol van “manager” stond niet eens op de kaart.

Als uw bedrijf gebruik maakt van de typische matrixstructuur van verticaal lijnmanagement versus horizontaal project- (of product-) management (d.w.z. lijnmanager), dan lijkt alles volgens plan te verlopen. U zult nog steeds managementverantwoordelijkheden hebben, dat wil zeggen, het managen van alles wat buiten het dagelijkse productieve werk van uw team valt.

Laat me uw sleutelzin herhalen:

Ik ben een groot voorstander van agile

Nu is een goed moment om dat te omarmen, en te leren wat het betekent om een Scrum Team te managen. Je verantwoordelijkheden zijn nu ook verschoven. Je doet de gebruikelijke dingen (het aan boord nemen van nieuwe leden, het omgaan met salaris, het helpen van je team om te kunnen werken (hen hun hardware/softwar/etc. en een goede werkomgeving bezorgen), misschien samenwerken met andere Scrum-managers). Het feit dat uw bedrijf organisatieonderdelen lijkt te herkennen is niet veranderd. Uw teamleden zullen nog steeds met u moeten praten; alleen niet over hun werk.

Afhankelijk van wat u eerder deed als uw dagelijkse werk (het uitdelen van werkpakketten aan individuele ontwikkelaars), wilt u misschien kijken naar andere dingen die u kunt doen. Zo kun je bijvoorbeeld zelf bepalen voor welke projecten je(!) team werkt, of als een Product Owner op een of andere manier vervelend wordt, kan het jouw taak zijn om hem te kalmeren. Je zou verantwoordelijk kunnen zijn voor het beheer van klantcontracten (verkoop, etc.). Je zult een partner zijn en een schild voor je team in het geval van escalaties. U bent beheer. Managen is niet hetzelfde als software ontwikkelen; en het toewijzen van taken aan individuele mensen is slechts een klein onderdeel ervan.

Eerlijk gezegd zou ik zeggen dat je veel geluk hebt. Rijd op de golf. Laat ze hun ding doen. Vermijd het beheer van hun nieuwe Scrum; Scrum is precies gemaakt om het team zelfvoorzienend te maken en in staat te stellen te presteren zonder constant micromanagement van buitenaf. Veel onderdelen van Scrum zijn gemaakt om een team af te schermen van ongewenst beheer.

Jouw taak kan nu heel gemakkelijk zijn. Als alles werkt zoals gepland, zullen ze een heleboel zaken afhandelen die je eerder moest doen. Iedereen kan vanaf nu erg blij zijn, vooral als ze je micromanagement voorheen niet leuk vonden.

het team heeft collectief afgesproken om mij te “ontslaan” als hun manager

Uiteraard ga ik ervan uit dat, aangezien je het woord “ontslaan” aanhaalde, ze niet letterlijk een mail naar HR hebben gestuurd om je uit te sluiten van de loonlijst, maar ze hebben je verteld dat ze Scrum in zijn volle omvang (en intentie) willen leven. Ik ga er natuurlijk van uit dat ze de lijnen op het organigram van uw bedrijf niet echt willen doorknippen. Zelfs een zuiver Scrum Team moet nog ergens in het bedrijf geworteld zijn, d.w.z. deel uitmaken van het lijnmanagement, en dat bent u. U bent gewoon niet meer betrokken bij het dagelijkse werk.