Optimaal inrichten van scrum teams met meerdere klanten/prod

[Acroach]

Hey tweakers,

Ik ben development manager bij een bedrijf met ongeveer 35 developers waarvan er 25 in 4 zelfsturende teams werken aan verschillende e-commerce shops.

Er is een redelijke manier gevonden om hier goed mee om te gaan maar we merken dat we tegen de grenzen van de mogelijkheden aanlopen.

Een aantal dingen waar we tegen aan lopen:

Context switchen, ad hoc vragen en issues van klanten zorgen ervoor dat er vaak van context gewisseld moet worden, het is bekend dat enorm veel tijd en cognitieve load kost. Hier komt bij dat alle klanten zichzelf het belangrijkst vinden en alles een prio 1 is.

Cross-functionaliteit, we zien dat de developers onderling afspraken maken over wie welke klant doet. In principe niets mis mee totdat de vakantieperiode er aan komt of als iemand langdurig ziek is. Single point of knowledge

Meetings, door dat er meerdere klanten in een team zitten die allemaal een sprintplanning, sprintreview en refinement hebben zijn de developers veel aan het vergaderen.

Facturering, we werken nu op basis van uurtje factuurtje waarbij alle developers (junior tot lead) het zelfde uurtarief hebben. Als een lead developer iets oppakt is die aanzienlijk sneller klaar, dus korter bezig met een PBI (product backlog item). Een junior die 5 uur met een PBI bezig is levert meer op dan een lead die het zelfde werk in een uurtje kan doen.

Scrum (in name only). De klanten willen scrum, want hot & happening, maar ze willen ook micromanagen en waterval. Hoeveel uur is er per PBI besteed, hoeveel effort wordt daar ingestoken en hoeveel heeft dat item dan gekost. Alles is een musthave en heeft topprioriteit.

Ik geef graag meer informatie als jullie iets missen in de uitleg.

TL;DR 4 klantteams die per team op basis van Scrum werken met verschillende klanten. Hoe dit het beste in te richten.

[Davidshadow13]

Een paar vragen die ik dan heb op basis van jouw verhaal. Waar overigens als IT consultant veel herkenbaar is.

• Heeft elk team een Product Owner / Project Manager welke de klanten managed en de developers afschermd van de klanten zodat zij hun werk effectief kunnen doen. Die PO/PM kan dan ook zaken prioriteren en zorgen dat er niet teveel werk tegelijk richting het team komt?
• Voor context switching, als er veel inhoudelijke vragen zijn / 3e lijns support nodig is doen wij vaak elke sprint één iemand aanwijzen binnen het team die verantwoordelijk is hiervoor. Dit roteert per sprint zodat iedereen dit rot klusje een keer doet (noemen hem/haar ook de Sjaak of the Sprint). Dit is de enige persoon die ad-hoc zaken mag oppakken, troubleshooten met een klant, vragen beantwoorden.
• Opvoeding van klanten, blijkbaar kunnen ze losse features afnemen en worden die per uur betaald. Dit is gewoon geen ideale manier van afnemen binnen een scrum team. Beter kun je features fixed price aanbieden of een klant een hele sprint af laten nemen zodat je 2 weken kunt focussen op alleen die klant. Productiviteit binnen een Agile team meten op basis van gewerkte uren per PBI/US is vragen om problemen. Dan kan je bijv beter Kanban gaan werken met een WIP limit en gewoon tijdregistratie met Tempo (JIRA) plugin doen per US en dan de werkelijke tijd factureren aan je klant. Ook een PO/PM kan hierbij helpen.

Probeer Sprint reviews van de klanten binnen één team de combineren en besteed dan maximaal 10-15 minuten per klant, ik ga ervanuit dat die features niet zo complex zijn. Dus 1 uurtje per sprint moet dan voldoende zijn. Doe specifieke klant refinements in 3Amigo sessies zodat niet het hele team aanwezig hoeft te zijn maar de kennis wel gedeeld kan worden en probeer zoveel mogelijk features generiek te implementeren zodat re-use hoog is en de technische implementaties tussen de klanten onderling niet teveel afwijkt. Dit helpt ook met het overdragen van kennis.

Verder zou je eens kunnen kijken naar Team Topologies (https://teamtopologies.com/) en TeamOps (https://about.gitlab.com/teamops/) om te kijken hoe je jouw Agile teams efficiënter kunt inrichten en laten werken. Ik haal uit deze twee initatieven in ieder geval veel waardevolle inzichten.

[Acroach]

Davidshadow13 schreef op donderdag 5 oktober 2023 @ 10:08:
Een paar vragen die ik dan heb op basis van jouw verhaal. Waar overigens als IT consultant veel herkenbaar is.

• Heeft elk team een Product Owner / Project Manager welke de klanten managed en de developers afschermd van de klanten zodat zij hun werk effectief kunnen doen. Die PO/PM kan dan ook zaken prioriteren en zorgen dat er niet teveel werk tegelijk richting het team komt?
• Voor context switching, als er veel inhoudelijke vragen zijn / 3e lijns support nodig is doen wij vaak elke sprint één iemand aanwijzen binnen het team die verantwoordelijk is hiervoor. Dit roteert per sprint zodat iedereen dit rot klusje een keer doet (noemen hem/haar ook de Sjaak of the Sprint). Dit is de enige persoon die ad-hoc zaken mag oppakken, troubleshooten met een klant, vragen beantwoorden.
• Opvoeding van klanten, blijkbaar kunnen ze losse features afnemen en worden die per uur betaald. Dit is gewoon geen ideale manier van afnemen binnen een scrum team. Beter kun je features fixed price aanbieden of een klant een hele sprint af laten nemen zodat je 2 weken kunt focussen op alleen die klant. Productiviteit binnen een Agile team meten op basis van gewerkte uren per PBI/US is vragen om problemen. Dan kan je bijv beter Kanban gaan werken met een WIP limit en gewoon tijdregistratie met Tempo (JIRA) plugin doen per US en dan de werkelijke tijd factureren aan je klant. Ook een PO/PM kan hierbij helpen.

• Iedere klant heeft een eigen PO, hier is zeker nog ruimte voor verbetering, wat we vaak zien is dat een marketing medewerker er een rol bij krijgt en een PO by Proxie is. Dus alleen een doorgeef-luik en geen duidelijke acceptatie criteria kan opgeven.
• Dit zou een mooie optie kunnen zijn. "Engineer of the week" of iets dergelijks.
• Mooie inzichten, meer richting value based pricing begrijp ik uit je suggestie.

Ik ga zeker even kijken naar de suggesties die je doet. Bedankt voor je inzichten!

[happysan]

Wat is nu eigenlijk precies je vraag? Of wil je dat wij jouw werk voor je doen en jouw bedrijfsprocessen inrichten? Want in dat geval lopen hier vast mensen rond die je een offerte voor een consultancy traject willen sturen.

Als je zelf al een opzet hebt kun je die het beste plaatsen, dan kunnen mensen gericht wat feedback geven.

[Davidshadow13]

happysan schreef op donderdag 5 oktober 2023 @ 11:14:
Wat is nu eigenlijk precies je vraag? Of wil je dat wij jouw werk voor je doen en jouw bedrijfsprocessen inrichten? Want in dat geval lopen hier vast mensen rond die je een offerte voor een consultancy traject willen sturen.

Als je zelf al een opzet hebt kun je die het beste plaatsen, dan kunnen mensen gericht wat feedback geven.

Ik wilde al bijna zeggen tot zover mijn gratis consult voor vandaag .

Maar ik vind het absoluut niet erg om gratis was inzichten en links te delen om een collega uit de brand te helpen hoor. Ik denk dat @Acroach best een aantal uitdagingen schets die veel voorkomen bij zelfstandige software leveranciers / digital agencies. Om dan een aantal pointers te krijgen van hoe collega's die aangevlogen zijn kan net het juiste zetje zijn om dit zelf ook weer te kunnen toepassen.

[happysan]

Davidshadow13 schreef op donderdag 5 oktober 2023 @ 11:29:
[...]


Ik wilde al bijna zeggen tot zover mijn gratis consult voor vandaag .

Maar ik vind het absoluut niet erg om gratis was inzichten en links te delen om een collega uit de brand te helpen hoor. Ik denk dat @Acroach best een aantal uitdagingen schets die veel voorkomen bij zelfstandige software leveranciers / digital agencies. Om dan een aantal pointers te krijgen van hoe collega's die aangevlogen zijn kan net het juiste zetje zijn om dit zelf ook weer te kunnen toepassen.

Helemaal eens, maar dan kan hij zelf beginnen met het delen van zijn idee hoe hij het aan wil pakken. Dan kan iedereen meedenken en is het iets waar iedereen iets aan heeft.

[Acroach]

happysan schreef op donderdag 5 oktober 2023 @ 11:14:

Als je zelf al een opzet hebt kun je die het beste plaatsen, dan kunnen mensen gericht wat feedback geven.

We hebben een oplossingsrichting maar die is nog lang niet concreet genoeg. Die bestaat uit het verkopen van sprints en het factureren van een vast bedrag per maand. Inzetten op extra duidelijke plannings- en reviewsessies, dan weet de klant op voorhand wat hij kan verwachten en achteraf krijgt hij inzicht wat er is opgeleverd. Dat bevordert het bijsturen naar concrete businessvalue in plaats van het "dom afwerken" van de backlog. Deze oplossing haalt de last van het uren registeren bij de developers weg. We zijn ook actief bezig met het coachen van de PO's zodat er kwalitatief betere PBI's worden opgeleverd.

De uitdagingen zijn:
Hoe verreken je eventuele ziekte/vakantie in de factuur naar de klant.
Verschillende klanten nemen verschillende hoeveelheden uren van ons af, het is een enorme puzzel (wel oplosbaar) om het optimale uit de teams en de bezetting BE/FE te halen.

[BLN]

Welke ticketing systeem gebruiken jullie nu? Ik heb ervaring met het implementeren van de Atlassian stack, en op basis daarvan zou ik het volgende doen:

Slim opgezette service request portal (JSM in het geval van Atlassian) waarbij de klanten tickets voor hun eigen product kunnen aanmaken, met de juiste informatie daar in.

Die kunnen op de backlog van een team komen, en bij de inschatting van de hoeveelheid werk kan daar een tijdsduur tegenover gezet worden. Tijdens het doen van het werk kan de tijd gelogd worden op het service ticket (al dan niet geautomatiseerd) en op basis daarvan kun je rapportage draaien over de kosten per klant.

Daarmee is nog niet je operating model opgelost, maar het kan een stap zijn naar het overzicht creëren wat je nodig hebt om je operating model te verbeteren.

[Acroach]

Dit is inderdaad een oplossing om meer inzicht te krijgen in de tijd die we besteden aan klanten per PBI/ticket. Ik durf te zeggen dat we redelijk inzichtelijk hebben waar de tijd aan op gaat en wat de doorlooptijd etc is.

Het is lastig om hier conlusies uit te trekken die een operating model kunnen valideren :-)

[worldfastest]

Wat ik hier lees is dat men wel Scrum wil doen alleen niet de Scrum manier van werken.
Het is een (lastige) omschakeling wat tijd kost. Echter moet de scrum master er op toe zien dat Scrum manier van werken wordt gevolgd. Ook al zijn sommige mensen het hier niet mee eens.

Zorg dat alle scrum rituelen worden uitgevoerd (daily standup/sprint planning/retro/refinement) en dat de PO zijn werk doet.

Zorg dat je goede software hebt waarop je je PBI en sprint planning bijhoudt. Plan nooit een sprint helemaal fol maar laat tijd over voor incidenten.

[Davidshadow13]

worldfastest schreef op donderdag 5 oktober 2023 @ 12:29:
Wat ik hier lees is dat men wel Scrum wil doen alleen niet de Scrum manier van werken.
Het is een (lastige) omschakeling wat tijd kost. Echter moet de scrum master er op toe zien dat Scrum manier van werken wordt gevolgd. Ook al zijn sommige mensen het hier niet mee eens.

Zorg dat alle scrum rituelen worden uitgevoerd (daily standup/sprint planning/retro/refinement) en dat de PO zijn werk doet.

Zorg dat je goede software hebt waarop je je PBI en sprint planning bijhoudt. Plan nooit een sprint helemaal fol maar laat tijd over voor incidenten.

Ik lees eerder dat zijn klanten willen dat zij Scrum werken want het enige wat zij gehoord hebben is dat Agile hip is en gehoord hebben dat je je features dan sneller krijgt. Aan de andere kant willen ze wel volledige controle over de tijd die een implementatie kost en dus hoe hoog de rekening is. Dat werkt gewoon niet samen.

@Acroach Ik zou beginnen met die markering medewerkers die als PO aangesteld zijn het Agile manifesto te laten lezen en dan een cursus PSPO I laten volgen minimaal. Dan hebben ze de juiste kennis en tools om lastige klanten te kunnen vertellen hoe Scrum écht werkt. Dan kunnen ze ook het team beter afschermen.

Verder is het afsluiten van contracten op deliverables i.p.v. gepresteerde uren veel beter om micromanagen tegen te gaan en dan geef je het team ook de vriheid om hun sprint in te delen. Want zelfsturend zijn ze nu niet echt want iedereen wordt gestuurd door de wil van de klant zo lijkt het.

Ik doe met onze organisatie met name detachering maar we hebben ook een kleinere producttak. Daarbij kunnen klanten voor features of wel minimaal één sprint afnemen met een heel team ofwel één developer fulltime inhuren op detacheringsbasis. Dus ofwel iemand voor 32/40 uur per week voor minimaal 1 maand of twel één team voor minimaal 1 sprint van twee weken. Aan dat team hangt dan een vaste prijs voor één sprint en wordt er gecommiteerd op een bepaalde scope qua deliverable. Als er dan iemand ziek is wordt die ofwel vervangen binnen het team ofwel het team werkt door langer dan één sprint om de overeengekomen deliverables te halen. Dit prijzen wij atijd in in de sprint prijzen voor een heel team. Meestal verdien je daarop want is het team in 2 weken klaar, soms duurt het drie weken en dan leg je er geld bij. Zolang de balans over het grote geheel maar positief is, dan is het prima.

[Voutloos]

Acroach schreef op donderdag 5 oktober 2023 @ 11:38:
[...]
De uitdagingen zijn:
Hoe verreken je eventuele ziekte/vakantie in de factuur naar de klant.
Verschillende klanten nemen verschillende hoeveelheden uren van ons af, het is een enorme puzzel (wel oplosbaar) om het optimale uit de teams en de bezetting BE/FE te halen.

Als je met deze vragen zit, ben je zelf de micromanager / werk je het zelf in de hand.
Klap er een stukje marge op, en scherm je teams af. Dat laatste is beide richtingen! Dus niet elke scheet hoeft naar de klant te gaan.

Zoals je het nu vertelt klinkt het alsof elke gast er in de keuken bij mag staan. In de meeste restaurants mag dat niet.

[Acroach]

Voutloos schreef op donderdag 5 oktober 2023 @ 17:19:
[...]
Zoals je het nu vertelt klinkt het alsof elke gast er in de keuken bij mag staan. In de meeste restaurants mag dat niet.

Bedankt voor je input, ik begrijp wat je zegt, ik ben recent begonnen bij dit bedrijf en wil graag meer ademruimte voor de developers, dus juist niet micromanagen. Mijn doel is om alle uren rompslomp bij ze weg te halen. De klanten zijn voorheen "verwend" door alles tè inzichtelijk te maken, daar ligt nu een grote uitdaging om de klanten op te voeden.

[Acroach]

Davidshadow13 schreef op donderdag 5 oktober 2023 @ 13:20:
[...]

@Acroach Ik zou beginnen met die markering medewerkers die als PO aangesteld zijn het Agile manifesto te laten lezen en dan een cursus PSPO I laten volgen minimaal. Dan hebben ze de juiste kennis en tools om lastige klanten te kunnen vertellen hoe Scrum écht werkt. Dan kunnen ze ook het team beter afschermen.

Ah dat heb ik misschien niet helemaal duidelijk uitgelegd, de marketing medewerkers die als PO fungeren zijn van de klant zelf, we hebben op die projecten geen interne PO's. We hebben wel plannen om een PO van 1 van onze andere projecten in te zetten als consultant om de PO's van de klant op te leiden.

Davidshadow13 schreef op donderdag 5 oktober 2023 @ 13:20:
[...]

Verder is het afsluiten van contracten op deliverables i.p.v. gepresteerde uren veel beter om micromanagen tegen te gaan en dan geef je het team ook de vriheid om hun sprint in te delen. Want zelfsturend zijn ze nu niet echt want iedereen wordt gestuurd door de wil van de klant zo lijkt het.

Ik vind dit een mooi inzicht, ik neem dit zeker mee om de mensen op C-level te overtuigen. Bottom line komt het neer op Developers op 1, klant op 2 (door op te voeden en duidelijke afspraken en verwachtingen te managen).

[Oon]

Klinkt alsof je niet zelfsturende teams hebt, maar klantgestuurde teams. Een account/projectmanager tussen de developers en de klant zetten is je oplossing voor zowel 4 van de 5 punten.

Vwb kennis, dat is een kwestie van documentatie, verplicht iedere developer een uurtje of 2 per week aan documentatie te werken en dat probleem is binnen een kwartaal opgelost.

[indigo79]

Acroach schreef op donderdag 5 oktober 2023 @ 11:38:
Hoe verreken je eventuele ziekte/vakantie in de factuur naar de klant.

Dit moet je echt in je prijsmodel verwerken, zeker in een uurtje-factuurtje-model betaalt de klant voor werk dat gedaan wordt en is afwezigheid (om welke reden dan ook) geen zorg voor de klant. Er wordt een bepaald aantal uren gewerkt voor de klant en de klant betaalt die. Dat tarief moet gewoon hoog genoeg liggen om vakantie en ziekte en dergelijke op te vangen.

Verschillende klanten nemen verschillende hoeveelheden uren van ons af, het is een enorme puzzel (wel oplosbaar) om het optimale uit de teams en de bezetting BE/FE te halen.

Wij proberen daar de planning weg van de developers en naar de project manager/product owner te halen. Elke klant vindt zijn eigen problemen uiteraard het belangrijkst, maar met wat kennis van je klanten kan de project manager/product owner/account manager typisch de volledige backlog wel redelijk ordenen naar prioriteit en op die manier de developers laten focussen op het developen. Een beetje standaardisatie in de manier van werken kan helpen en voor de rest zorgen we dat kennis over een project of klant nooit bij één persoon zit, al is het door code reviews met iemand anders te doen (maar dan moeten ze wel serieus gebeuren, niet gewoon aftekenen in je version control system).

Developers moeten dan alleen hun tijd een beetje loggen en dan maakt het verder niet uit dat die klanten verschillende hoeveelheden uren afnemen.