In mijn vorige artikel ben ik de discussie begonnen over slecht ontwikkelde gewoonten binnen een scrumteam die uiteindelijk (vroeg of laat) zullen leiden tot het mislukken van de oplevering. In dit artikel wil ik dit onderwerp nog een keer uitwerken en me nu concentreren op functionele processen binnen het workforce.
Die zijn web zo belangrijk als de technische uitmuntendheid van het workforce. Zelfs als de mensen binnenin superbekwaam zijn voor de taak die ze gaan uitvoeren, zijn er nog steeds gebieden die hun streven naar perfectie kunnen verpesten. En het zal niet zozeer hun schuld zijn, maar de directe verantwoordelijkheid van de projectmanagementbeslissingen en hun vermogen om het workforce te bedienen met geschikte processen om het workforce te ondersteunen met een duidelijke bedoeling en voorspelbare activiteiten.
Sterk gescheiden workforce met verschillende vaardigheden
Stel je voor dat het workforce bekwame ontwikkelaars heeft, volkomen onafhankelijk en met het vermogen om hun beloften na te komen en de afgesproken sprintinhoud web op tijd voor het einde van de dash op te leveren. Zelfs in zo’n good state of affairs (wat toch hoogst onwaarschijnlijk is) zal het workforce problemen hebben met het bijhouden van de (steeds groter wordende) achterstanden als de vaardigheden strikt gescheiden zijn tussen de teamleden.
Weinig voorbeelden
- Het workforce heeft 1 of two DevOps-ingenieurs die eventuele wijzigingen in de geautomatiseerde pijplijnen kunnen doorvoeren of de companies binnen het platform kunnen verzorgen, maar de relaxation van het workforce heeft daar geen idee van. Het vervolgens bespreken van die verhalen tijdens scrumceremonies zoals verfijningen zal voor de meerderheid van het workforce leiden tot tijdverspilling door zonder enige deelname aan de vergadering te blijven hangen en vice versa – de DevOps-ontwikkelaar zal geen interesse hebben in de relaxation van de op functionaliteit gerichte verhalen, en de tijd op de vergadering zal ook grotendeels worden verspild.
- Er is één database-expert voor het hele workforce. Afhankelijk van de complexiteit en het gebruik van de dataoplossingen in het systeem dat het workforce ontwikkelt, kan deze persoon voortdurend overladen worden met verhalen die hij niet snel genoeg kan voltooien, vooral als hij rekening houdt met zijn prioriteiten. Erger nog, andere verhalen zullen ook moeten wachten, omdat deze afhankelijk zijn van de gegevensbron die door de databaseverhalen wordt aangeleverd.
- Wanneer een bepaald product vooral gericht is op backend-ontwikkeling, is de enige front-end-ontwikkelaar aanwezig voor het geval dat (omdat er van tijd tot tijd toch een kleine verandering nodig is, zelfs in de UI-applicatie). In dat geval zijn de meeste scrumceremonies tijdverspilling voor dit teamlid, omdat hun kennis alleen beperkt is tot de voorkant en niets anders er toe doet.
Waar het eindigt
In elk van de bovenstaande gevallen is het resultaat dat mensen ofwel hun tijd verspillen, ofwel niet in staat zijn de achterstand in te halen. Ze verhinderen dat de relaxation van het workforce aan de volgende verhalen begint te werken, of ze verminderen effectief de algehele effectiviteit van het scrumteam omdat er te veel tijd is die niet wordt benut binnen de dash.
Het workforce heeft echter nog steeds dit aantal ontwikkelaars. Van buitenaf is het niet zichtbaar (zelfs als ze niet willen worden blootgesteld) dat de mensen binnen het workforce sommige verhalen niet kunnen overnemen, alleen maar omdat ze te veel gericht zijn op een bepaalde specifieke vaardigheden. Ze kunnen de andere teamleden dus niet helpen met de verhalen, ook al zou hun capaciteit dat toelaten, en de prioriteiten voor verhalen zouden daar ook in het voordeel van zijn.
Het is zelfs moeilijk voor de producteigenaar om betekenisvolle sprintcontent voor het workforce samen te stellen, omdat de producteigenaar altijd in gedachten moet houden hoeveel mensen aan elk afzonderlijk verhaal kunnen werken en of er meer vergelijkbare verhalen tegelijkertijd naar de dash worden gebracht. Uiteindelijk wordt de capaciteit van het workforce overschreden, ook al zijn er inderdaad mensen die mogelijk aan die verhalen zouden kunnen werken, maar die niet over de vaardigheden beschikken om daarmee te beginnen.
Het dilemma oplossen
Het is een dilemma dat moet worden opgelost, en projectmanagers moeten zich bewust zijn van de route die ze moeten kiezen. Concreet een keuze tussen:
- Er zijn veel full-stack-ontwikkelaars die aan bredere inhoud kunnen werken, maar die niet echt specialists zijn in veel onderwerpen. Ze kunnen dus breed gaan, maar niet diep. Dan kan de levering snel verlopen, maar kan de kwaliteit eronder lijden.
- Voor elke technologie toegewijde specialists hebben, maar dan de beperking accepteren en tougher werken aan beter passende gedrukte inhoud. Dan kunnen mensen diep gaan en geweldige verhalen bouwen, maar de verhalen zullen opeenvolgend moeten worden benaderd, waardoor het langer duurt om ze op te leveren.
Zwakke producteigenaar
Dit is niet noodzakelijkerwijs per definitie een ‘procesprobleem’, maar ik behandel het zo, alleen maar omdat het creëren van solide verhalen kan worden opgevat als een proces dat het workforce zeer solide en compatibel met het ontwikkelingsteam zou moeten hebben.
Wat ik met zwak bedoel, hoeft niet te verwijzen naar de kenniseigenschap van een persoon, maar eerder naar het vermogen van de producteigenaar om de teamverhalen te dienen die ontwikkelaars kunnen begrijpen en die vanuit het perspectief van de productroadmap duidelijk zinvol zijn. Beide zijn erg belangrijk voor een succesvol scrumteam.
Als de verhalen particulars missen zodat ontwikkelaars het doel, de functionele waarde of de technische verwachtingen duidelijk kunnen begrijpen, kunnen er in principe twee state of affairs’s plaatsvinden:
- Ontwikkelaars zullen iets anders bouwen dan wat de producteigenaar eigenlijk wilde. Het is zelfs moeilijk te vangen tijdens de dash zelf, omdat de producteigenaar meestal niet de mogelijkheid heeft gehad om de voortgang van de verhalen op zo’n gedetailleerd niveau te volgen, en meestal zal PO gewoon verwachten dat het ding (magisch) zal gebeuren.
- Ontwikkelaars zullen veel te veel tijd besteden aan het verduidelijken van de verhalen en het steeds opnieuw bespreken ervan, in plaats van ze te gaan bouwen. Dit brengt veel additional telefoontjes, herhaalde afspraken en het uitstellen van het werk naar de late sprintfase met zich mee. Het bereikt een punt waarop de oorspronkelijke schattingen voor de verhalen niet langer als accuraat kunnen worden beschouwd, en de verhalen niet meer binnen de dash kunnen worden afgesloten en doorrollen naar de volgende sprints. In het ergste geval herhaalt de situatie zich vervolgens in de volgende sprints.
Tijd voor zelfreflectie
Het is meestal moeilijk om toe te geven, maar de producteigenaar moet de tijd vinden om na te denken, naar de gecreëerde backlog-verhalen te kijken en deze uiteindelijk te vergelijken met de productroadmapvisie, als er nog steeds een verstandige hyperlink is tussen die twee – als er een roadmap is helemaal niet. Zo niet, dan is dat het eerste dat moet worden opgelost. Soms is de oplossing om toe te geven dat de producteigenaar te ver van het workforce en te ver van het eigen doel verwijderd is.
In een dergelijk geval moet het producteigenaargedeelte van het workforce worden opgelost. Als er niets anders is, zou het binnenhalen van een solide bedrijfsanalist die zich meer op de inhoud van het workforce richt dan op de zakelijke inhoud (daarvoor hebben we in dit geval al een producteigenaar) een geldige optie kunnen zijn, zelfs voor de prijs van hogere totale kosten van het workforce.
Processen testen zonder vaste tijdlijn
Wat als de testactiviteiten niet strak volgens een concreet schema zijn binnen een scrumsprint?
Op het eerste gezicht lijkt dit misschien iets goeds dat we willen voor een agile/scrum-team. Flexibiliteit is altijd welkom en klinkt goed als deze buiten wordt gepresenteerd.
Mijn ervaring leert dat het resultaat van deze vrijheid meer chaos dan flexibiliteit is. Het betekent niet dat de oplossing hiervoor het creëren van “watervallen binnen de dash” zou moeten zijn, waarbij speciale testfasen gevolgd moeten worden vlak nadat de ontwikkeling voltooid is. In dit geval is dit zeker niet de juiste aanpak. Je kunt hier meer over lezen in mijn berichten over de scrumteststrategie en de agile testlevenscyclus.
We kunnen nog steeds enige flexibiliteit toestaan en het testschema kiezen omdat dit het meest geschikt lijkt voor het huidige ontwikkelingsteam en de gegeven producteigenschappen die het workforce levert. Er zijn echter twee hoofddoelen die met deze keuze moeten worden bereikt:
- Minimaliseer de verstoring van de ontwikkelingsvoortgang tijdens de testactiviteiten.
- Maak het solide (vanuit een inhoudelijk perspectief), betrouwbaar (vanuit een gebeurtenisperspectief) en herhaalde (vanuit een voorspelbaarheidsperspectief) activiteit binnen het workforce.
Als aan deze voorwaarden wordt voldaan, zal het workforce zich uiteraard aanpassen aan het montageproces en zal het leveringsschema niet worden beïnvloed door ongeplande langdurige testactiviteiten.
Uiteindelijk gaat het erom dat de betrouwbare en voorspelbare sprintrelease het belangrijkst is, wat me naar het laatste punt van deze weblog brengt.
Ongedefinieerd vrijgaveproces
Dit is zo vanzelfsprekend voor elk scrumteam. Toch is het merkwaardig genoeg meestal ook een van de meest onderschatte processen.
Heel vaak zal een scrumteam gewoon zeggen dat de launch na elke dash zal plaatsvinden, maar dit wordt niet ondersteund door een solide proces. Wat er dan gebeurt, is dat er tijdens de releaseperiode veel chaotische, onvoorspelbare activiteiten zullen plaatsvinden. Opeens zijn alle mensen bezig met ‘vrijgavetaken’ en kan niemand zich concentreren op het verder ontwikkelen van nieuwe sprintverhalen. De sprintstatistieken zijn uitgeschakeld en de launch ziet eruit als willekeurige, onvoorspelbare activiteit vanuit het perspectief van de derde persoon (meestal de klant).
Mensen zijn zo gefocust op de backlog, de inhoud van de dash, de ontwikkeling, het testen en het uiteindelijk presenteren van de resultaten, dat ze vergeten dat als ze hiermee klaar zijn, de volgende dash al aan de gang is en ze al tijd verliezen.
Op zoek naar een goed second om los te laten
Dus wanneer moet het workforce precies de daadwerkelijke launch voor productie uitvoeren? Het enige belangrijke dat er uiteindelijk toe doet.
Het antwoord op die vraag zit in het proces, ervan uitgaande dat je er een hebt. Afhankelijk van:
- de complexiteit van de inhoud die het workforce produceert in de sprints,
- duur van een dash,
- aantal getroffen componenten in het systeem
- het aantal mensen dat de wijzigingen gebruikt en aanvraagt,
er moet een proces voor herhaalde vrijgave worden vastgesteld en in de toekomst gevolgd. De exacte regels van het proces kunnen opnieuw flexibel worden gedefinieerd. Maar web als bij testactiviteiten, is het iets om op te vertrouwen en naar te verwijzen als je er een rotsvaste gewoonte van maakt die voorspelbaar is en gepland staat voor concrete dagen in de toekomst.
Keuzes om te kiezen
De mogelijke vormen van een dergelijk proces kunnen een van de volgende zijn:
- Voltooi het testen van de functies van de huidige dash tijdens de volgende dash en geef de inhoud vrij aan het einde van die dash (zodra het testen is voltooid). Dit betekent dat elke launch geen inhoud van de allerlaatste dash bevat, maar wel verhalen van de twee sprints ervoor.
- De laatste dash vóór de launch staat altijd in het teken van het testen van de inhoud van de voorgaande twee sprints.
- Dit betekent niet dat de ontwikkeling tijdens de “testsprint” wordt stopgezet; er staat alleen dat de inhoud die in die testsprint is ontwikkeld, nog niet zal worden opgenomen in de volgende launch.
- Als er al voldoende geautomatiseerde testactiviteiten zijn uitgevoerd, streef er dan naar om de launch na het einde van elke dash uit te voeren. Dan moet dit een heel strikt proces zijn waarbij toegewijde mensen zich voor 100% op die paar dagen concentreren. Het zou op geen enkele manier invloed moeten hebben op de relaxation van het ontwikkelingsteam.
- U kunt er ook voor kiezen om één keer per maand of één keer per N maanden uit te brengen, vooral als dat vanuit het perspectief van de eindgebruiker goed is. Dit zal de inspanning aan de testkant voor elke dash vergroten (aangezien de inhoud voor elke launch groter zal zijn). Maar aan de andere kant zal het in de loop van de tijd minder herhaalde activiteiten betekenen, wat in dit geval voordelen kan hebben voor het workforce. Als gevolg hiervan kan het workforce meer nieuwe functies tussen de releases door bouwen, ondanks het feit dat de functies in een langzamer tempo in productie zullen komen.
Maar zoals al een paar keer eerder is gezegd, is het niet zo belangrijk welke van deze processen wordt gekozen. Het is veel belangrijker hoe goed het workforce zich vervolgens aan dat proces zal houden en er een slijtvaste gewoonte van zal maken.
U kunt ook deze handleiding lezen over het releasebeheerproces en de -praktijken.