Maar al te vaak hebben bedrijven de missie om "agile te worden" voordat ze echt begrijpen wat dat betekent. Scheuren beginnen zichtbaar te worden en er wordt niet aan verwachtingen voldaan, waardoor iedereen twijfelt aan de waarde van "agile worden" – en de kans kleiner wordt dat je dit ooit bereikt.
De waarheid is dat agile worden resulteert in productievere teams en snellere levering van projecten, maar alleen als iedereen het eens kan worden over de spelregels. Luister naar Heather Fleming en Justin Riservato, van e-commerce gigant Gilt, terwijl ze bespreken waarom consensus bereiken over de principes van agile belangrijker is dan een proces implementeren.
Heather en Justin zijn met name op zoek naar de antwoorden op drie essentiële vragen die elk team moet kunnen beantwoorden voordat ze aan het agile avontuur beginnen:
- "Maar wanneer ben je klaar?" Waarom het concept deadlines loslaten het belangrijkste (en moeilijkste) gesprek is als je agile wilt worden.
- "Dit heeft mijn hoogste prioriteit, maar ik kan je pas volgende week spreken." Wat je moet doen als je zakenpartner geen volwaardig lid van het team kan (of wil) zijn.
- "Ik wil gewoon coderen. Waarom moet ik bij al deze meetings aanwezig zijn?" Waarom de implementatie van Scrum niet de eerste stap is om agile te worden.
Kijk en leer
Q&A
Heather en Justin selecteren een paar van de belangrijkste vragen uit de vraag en antwoordsessie van deze presentatie. Lees meer om dieper in tactieken te duiken voor het toepassen van agile methoden.
Vraag 1: Digitaal agile bord vergeleken met fysiek agile bord? Wat vind jij hiervan?
Antwoord 1: Het hangt echt af van hoe je team is samengesteld. Zitten jullie allemaal op dezelfde lijn? Hoe groot is je team? Heb je ruimte voor een groot fysiek bord? We hebben beide gedaan bij Gilt, maar hebben gemerkt dat naarmate we groeien en uitbreiden naar tientallen teams, de agile borden in JIRA Software praktischer zijn dan fysieke borden. Ze zijn eenvoudiger op te stellen en te wijzigen, en eenvoudiger te delen met externe teamleden. Wat we zo leuk vinden aan fysieke borden is dat je ze gewoon niet kunt negeren, ze vallen echt op. En ze zijn een geweldige plek om geïmproviseerde discussies te voeren over huidige werkzaamheden, of om standups te houden als je dat doet.
Vraag 2: Hoe kun je samenwerken met een manager of klant die het agile proces niet volgt of begrijpt? Ik voel me soms een mislukte workflow-coach.
Antwoord 2: Het is belangrijk om na te denken over de volgorde van je activiteiten. Als je in een agile proces probeert samen te werken met mensen die er niet in geloven, dan loop je een beetje op de feiten vooruit. Het belangrijkste om dit te laten werken, is consensus bereiken over de filosofie voordat je een proces uitvoert. Dit hebben we in het verleden gedaan door naar specifieke problemen te kijken die een team heeft met het huidige proces en deze op een agile manier op te lossen. Kun je je manager of klant helpen bij echte problemen die ze proberen op te lossen en hoe zou je het benaderen in een agile framework? Kun je ze stap voor stap meenemen in het proces van agile worden, in plaats van het proces volledig om te gooien? Vervolgens kun je op deze manier stapsgewijs echte resultaten laten zien, omdat het team beter werkt. Kortom, benader agile worden op een agile manier. ;)
Vraag 3: Hoe kun je een agile proces implementeren wanneer het project een vaste prijs en/of een vaststaand schema heeft met een lijst met vereisten die geïmplementeerd moeten worden?
Antwoord 3: Ten eerste is het onmogelijk om een project succesvol af te ronden met een vaststaand schema EN als er een lijst is met vereisten die moeten worden geïmplementeerd. Is er dus een manier om iedereen duidelijk te maken dat dit een sprookje is? De meeste beperkingen rond deadlines en vereisten zijn geen echte beperkingen: het zijn wensen. Bespreek waarom je het werk doet, of wat het probleem is dat je probeert op te lossen. Als je de doelen van het project en de redenen voor de beperkingen echt begrijpt, kun je ervoor zorgen dat het team het juiste werk op het juiste moment uitvoert. Als je alle vereisten noteert met datums ernaast, betekent dit niet dat alles op magische wijze op tijd af is.
Vraag 4: De meeste projecten hebben een releasedatum die vaak met partners en klanten wordt gedeeld. In dit scenario valt alleen te onderhandelen over de functieset (hoewel er compromissen op het gebied van kwaliteit zijn). Hoe werk je binnen de beperkingen van een vaste deadline?
Antwoord 4: Volgens ons heb je deze vraag al beantwoord — je doet dit door te onderhandelen over de scope. Als je dit niet doet, klopt het dat de kwaliteit eronder zal lijden. Denken dat je hoe dan ook gewoon de scope er doorheen kunt drukken, is een utopie. Je moet ervoor zorgen dat je teams de realiteit niet uit het oog verliezen, zelfs als mensen dit niet willen horen. Heather heeft hier een korte blogpost over geschreven die je hier kunt lezen.
Vraag 5: Hoe vind je dat de manier waarop Scrum wordt geïmplementeerd moet worden veranderd?
Antwoord 5: Ons grootste probleem met Scrum is de stroefheid. Denken dat één uiterst normatief proces werkt voor alle teams, ongeacht waar ze aan werken en wie ze zijn, is aanmatigend. We hebben gezien dat het werkt voor teams, maar Scrum is niet de enige manier om agile te zijn, en veel teams falen met agile omdat ze denken dat ze Scrum op een specifieke manier moeten implementeren met alle voorgeschreven functierollen, userstory's, acceptatiecriteria, meetings en artefacten. Heather heeft ook een probleem met de titel 'scrummaster'. ;)
Vraag 6: Hoe kun je voorkomen dat belanghebbenden de teamleden rechtstreeks beïnvloeden?
Antwoord 6: Nou, een goede belanghebbende IS een teamlid. Idealiter voeg je de belangrijkste belanghebbende dus toe aan je team, zodat jullie allemaal samen kunnen werken! Als je belanghebbenden zomaar dingen doorschuiven naar je team, of zich zomaar met projecten bemoeien en alles willen veranderen, is het belangrijk dat het hele team begrijpt waar ze mee bezig zijn en waarom. Dat belanghebbenden hetzelfde antwoord krijgen, ongeacht met wie ze praten. Dat maakt jullie een team in plaats van een groep individuen. Je moet veel communiceren en ervoor zorgen dat iedereen op dezelfde lijn zit en in dezelfde richting gaat.
Vraag 7: Schat je story's in op basis van ruwe schattingen van de grootte (in uren) of op basis van punten?
Antwoord 7: We doen beide, en sommige teams maken helemaal geen schattingen. Punten zijn geweldig omdat ze abstracter zijn en niet gebonden zijn aan een specifieke deadline. Uren kunnen handig zijn als transitie als je team geen schattingen wil maken, omdat het tastbaarder is. Het punt van schattingen maken is om te kunnen zien of je sprint te zwaar of te licht is en ze dan aan te passen, en ze dienen geen doel meer zodra de sprint begint. We merken dat als je eenmaal een tijdje met een team hebt gewerkt, het proces van schattingen maken overbodig wordt. We kunnen allemaal de werkzaamheden bekijken en vrij eenvoudig zien of het de juiste hoeveelheid is voor de sprint.
Vraag 8: Hoeveel waarde hecht je aan projectleiders/managers met uitgebreide analysevaardigheden en productkennis ten opzichte van alleen meetings coördineren tussen tech- en biz-belanghebbenden om vereisten te verzamelen?
Antwoord 8: Enorm veel waarde :) Meetings coördineren, notuleren, etc. … zijn geen speciale vaardigheden. Iedereen kan dit. Hoewel ze belangrijk zijn, hebben ze niet echt de grootste toegevoegde waarde die je het team kunt bieden. Als je alleen administratief werk verricht, dan vraagt het team zich terecht af waarom je er deel van uitmaakt. Iedereen binnen de PMO bij Gilt is goed geïnformeerd over het relevante onderwerp en de tools en technieken om werkzaamheden uit te voeren en dit bieden ze elk team waarin ze werken. Velen van ons waren engineer of hebben samengewerkt met andere afdelingen binnen Gilt en brengen unieke vakkennis met zich mee.
Vraag 9: Hoe groot zijn de teams over het algemeen en welke achtergrond hebben mensen bij Gilt?
Antwoord 9: Idealiter willen we onze teams klein houden, maar groot genoeg om zelfvoorzienend te zijn, zodat ze verder kunnen gaan met projecten zonder afhankelijk te zijn van andere teams. We hanteren het 'twee pizza's' principe: teams moeten genoeg hebben aan twee pizza's. We zijn er ook sterk van overtuigd dat elk individu binnen het team een aantal unieke talenten met zich meebrengt, en ze moeten deze talenten aan het team toevoegen, ongeacht hun functietitel. Dus als de producteigenaar altijd verantwoordelijk is geweest voor alle presentaties, maar hij of zij er niets van bakt en er een engineer is die geweldig verhalen kan vertellen en het publiek voor zich kan winnen, laten we de engineer dit talent aan het team toevoegen. Je bent meer dan je functietitel!
Vraag 10: Hoe stuur je een apart QA-team aan, vooral waar getest kan worden in een andere sprint dan ontwikkeling?
Antwoord 10: Dit is een van de meer controversiële standpunten die we innemen, maar we hebben geen apart QA-team bij Gilt. We geloven in automatiseringstesten tijdens het ontwikkelings- en implementatieproces. Teams zijn verantwoordelijk voor de kwaliteit van hun code. Als je de tijd en expertise hebt om code te schrijven, heb je de tijd en expertise om er testen voor te ontwikkelen. Dit over de schutting gooien naar een QA-team heeft nooit goede resultaten voor ons opgeleverd, en vereist veel aanvullende documentatie en tijd om QA-teams te informeren.
Vraag 11: Als je teams hebt die tegelijkertijd aan meerdere 'producten' werken, zou het dan werken om alle productmanagers in de ruimte te hebben tijdens de sprintplanning en ze relatieve prioriteiten voor verschillende producten te laten bepalen? Nog andere ideeën?
Antwoord 11: Stop! Dit gaat natuurlijk niet werken. Het team moet een eigen productmanager hebben en niet aan meerdere producten werken voor meerdere productmanagers buiten het team. De teamleider moet hier naar voren stappen en duidelijk de manier van prioriteren van het team schetsen, en in welke volgorde ze de uitvoering van dat werk op basis van deze methode gaan aanpakken. Het sluit aan bij ons punt dat “de methode duidelijk moet zijn voordat je een proces kunt implementeren”.
Vraag 12: Ik probeer een team voor creatieve marketingservices agile te maken. We hebben een aantal deliverables die op een bepaalde datum MOETEN worden geleverd (een advertentie voor in een tijdschrift ontwerpen). Hoe integreren we deze projecten in een agile kader?
Antwoord 12: Agile kan dergelijke beperkingen aanpakken. Het is aan het team om te bepalen wat er moet gebeuren en wanneer en dienovereenkomstig sprints te plannen. Agile zou je moeten helpen deze deadlines te halen, omdat het je de mogelijkheid biedt om je prioriteiten en geplande werk (scope) aan elke sprint aan te passen. Als je je snelheid bij begint te houden, kun je snel zien of je die deadlines wel of niet gaat halen. Vervolgens onderhandelt een goede teamleider over wat het team nodig heeft om succesvol te zijn.
Vraag 13: Lijkt het veranderen van doelen niet op scope-creep?
Antwoord 13: Ja, maar we noemen het geen ‘scope-creep’, omdat we verandering tijdens een project willen stimuleren. Een van de grootste voordelen van een agile filosofie is dat je je kunt aanpassen aan dingen waar je geen controle over hebt. Als de concurrentieomgeving verandert, of de behoeften van je bedrijf veranderen, of als er een nieuwe technologie beschikbaar is, wil je dan echt verder ploeteren met de vereistenmatrix die maanden geleden is opgesteld? Als je je klant het beste product wilt leveren, omarm verandering dan en gebruik het in je voordeel. Er is geen ‘scope-creep’ in agile (voeg hier het Jedi-raadsel toe).
