5 feiten over de agile transformatie
Ik ben nooit een fan geweest van horrorfilms. Maar Halloween vond ik altijd al geweldig. Als kind vond ik het heerlijk om enge kostuums aan te trekken en daarmee mijn vrienden en andere mensen te laten schrikken. En ik geef toe dat ik de spanning geweldig vind om met Halloween een goed ingericht spookhuis binnen te gaan.
Toch zijn er ook bij elke agile transformatie aspecten die je koude rillingen over je rug kunnen bezorgen – en die momenten zijn een stuk minder opwindend.
Laten we daarom samen deze vijf dingen hun angstaanjagende kant ontnemen en bespreken wat ze precies inhouden en waarom ze helemaal niet zo beangstigend zijn als je ze eenmaal goed begrijpt.
1) Ahhh! In Agile bestaat er geen ontwerpfase!
Vaak maken architecten en medewerkers van de ontwikkelafdeling zich zorgen omdat er in Agile geen expliciete designfase is. Hoewel het klopt dat agile teams designfases aan het begin van een project vermijden, betekent dat niet dat het design wordt verwaarloosd.
Design in een agile project wordt door twee kenmerken gekarakteriseerd: het is emergent en intentioneel.
Emergent design ontstaat geleidelijk. In plaats van een initiële designfase is het design een doorlopend proces. Het design ontstaat tijdens het bouwen van software.
Maar design is ook intentioneel. Dat betekent dat het design niet toevallig ontstaat. Het design wordt aangestuurd door de leidende technische medewerkers van een project of zelfs door een specifieke architect.
Als deze personen zich zorgen maken over een bepaald deel van het systeem, zou de [Product Owner]/nl/product-owner/ "Product Owner") een of twee [Product Backlog Items]( "Product Backlog Item") uit dat gebied moeten prioriteren. Daardoor krijgt het team de kans om dat deel van het systeem beter te leren kennen door er een klein stukje van te ontwikkelen. Dit helpt om het juiste design ervoor te vinden.
Wanneer het design op deze manier ontstaat door de beslissingen van het team, is het feit dat er in Agile geen expliciete designfase is, helemaal niet meer zo beangstigend.
2) Help! Ik word een generalist!
Een van de meest verspreide mythes in Agile is dat agile teams geen specialisten willen en in plaats daarvan willen dat iedereen in het team een generalist is.
Dat jaagt veel mensen om twee redenen angst aan: Ten eerste doet niet iedereen graag elk type werk. Ten tweede is er vaak de zorg dat het gevolgen kan hebben voor je arbeidsmarktpositie als je vier dingen half goed kunt in plaats van één ding extreem goed.
Het idee dat iedereen in een agile team een generalist moet zijn, is onjuist. Als ik een team coach dat de beste JavaScript-expert ter wereld heeft, wil ik dat die superster geweldige dingen doet met JavaScript en niet dat hij leert om databasebeheerder te worden.
Ja, in agile teams wil je teamleden met uiteenlopende vaardigheden hebben: bijvoorbeeld de tester die ook een beetje kan programmeren. De eenvoudigste optie is om iemand te hebben die beide soorten werk even goed kan doen. Als je team bijvoorbeeld een onbalans heeft tussen programmeer- en testwerk, is het handig om iemand in het team te hebben die zowel kan programmeren als testen.
Een doel in Agile is het vormen van interdisciplinaire teams. Dat betekent dat een team over alle vaardigheden beschikt om een voltooid, werkend productincrement in een iteratie op te leveren. Dat betekent echter niet dat elk teamlid elke vaardigheid moet bezitten die in het interdisciplinaire team nodig is.
Als het idee om een generalist te worden je de rillingen bezorgt, zul je opgelucht zijn om te horen dat specialisten ook in interdisciplinaire teams welkom zijn.
3) Oh nee! We hebben geen plannen en ook geen voorspellingen!
Managers schrikken vaak bij het idee dat een agile team geen plannen kan maken of voorspellingen kan doen die verder reiken dan de huidige iteratie of sprint.
Gelukkig klopt dat niet helemaal.
Ja, agile teams geven het valse comfort op van overgeplande projecten met onoverzichtelijke Gantt-diagrammen en exacte tijdschema's die ver in de toekomst reiken. Dat betekent echter niet dat agile teams niet in staat zijn om te plannen en de toekomst te voorspellen.
Een groot voordeel van agile methoden is dat het team in elke iteratie het volledige ontwikkelproces evalueert en aanpast. Het neemt een idee in de vorm van een eenvoudige User Story en implementeert deze feature. Dat betekent dat teams elke paar weken hun voortgang kunnen meten. Zo komen ze erachter hoeveel werk ze kunnen verzetten.
Vergelijk dat eens met een traditioneel ontwikkelproject dat misschien een analysefase, een designfase, een codeerfase en tot slot een testfase heeft. Als zulke teams hun voortgang willen meten, kunnen ze alleen maar vaststellen hoe snel ze één (of misschien twee) van deze werkzaamheden afronden. Hoe snel een team is met het design, zegt niets over hoe snel het vordert met de code of het testen.
Het belangrijkste bij de agile transformatie is om de onzekerheid te omarmen – toe te geven dat het onmogelijk is om alle functionaliteit vóór de start van het project te kennen – en vervolgens een van de vele mogelijkheden te kiezen om je daaraan aan te passen. Als teams dat eenmaal begrepen hebben en de hoeveelheid werk in elke iteratie meten, zou dit het management moeten geruststellen en tot betrouwbare planning moeten leiden.
4) Help! Ik ga mijn baan verliezen!
Het idee van een agile transitie van een team of een heel bedrijf kan menig manager behoorlijk de schrik aanjagen, want velen zijn bang dat hun baan na de transitie overbodig zal zijn.
Dat is begrijpelijk. Natuurlijk zou het verschrikkelijk zijn om een transitie te starten en te weten dat dit je eigen rol overbodig maakt.
Maar ik heb nog nooit een bedrijf geholpen bij een agile transformatie en meegemaakt dat er gezegd werd: "Oké, mensen met die en die rol hebben we nu niet meer nodig. Ze worden allemaal ontslagen." Dat gaat niet gebeuren. Natuurlijk kan het zijn dat een bepaalde functietitel niet meer nodig is of niet meer passend is, maar die mensen hebben dan nog steeds een baan. Ik geloof zelfs dat ze in de meeste gevallen achteraf met betere, passendere banen zitten dan daarvoor. Zeker, het kan zijn dat sommige mensen daardoor minder directe controle over medewerkers en beslissingen hebben en daar gefrustreerd over zijn – soms zelfs zo gefrustreerd dat ze het bedrijf verlaten.
Omdat ik nog nooit heb gezien dat mensen met bepaalde rollen of vaardigheden bij een agile transformatie zomaar ontslagen worden, denk ik dat de angst daarvoor net zo ongegrond is als die voor een zombie-apocalyps.
5) Uhhh! In Scrum zijn er te veel meetings!
Zoals de meeste mensen heb ik een hekel aan meetings. Over het algemeen gaat het mij om waarom ik doe wat ik doe. Op de meeste dagen heb ik helemaal geen meetings. Wat een geluk.
Toch kan zelfs ik toegeven dat sommige meetings belangrijk en nuttig zijn. Dit omvat de vier standaard meetings in Scrum: de Sprint Planning Meeting, de Daily Scrum, de Review en de Retrospective.
Alleen al de gedachte aan al deze meetings doet sommige mensen het zweet uitbreken.
En het probleem met Scrum Meetings: ze hebben een naam. Als iets een naam heeft, kun je het makkelijker aanvallen. In mijn ervaring hadden de meeste teams vóór Scrum meer meetings. Maar die meetings hadden geen namen en werden meestal spontaan gehouden om bepaalde zaken te bespreken.
Met een experiment kun je dat snel controleren. Zoek in je agenda een willekeurige maand waarin je nog niet agile werkte. Tel de tijd bij elkaar op die je in die maand in meetings hebt doorgebracht. Tel vervolgens de tijd op die je nu in Scrum Meetings doorbrengt en vergelijk de twee getallen.
Ik denk dat je verrast zult zijn door het resultaat. Omdat de meetings in de tijd vóór de agile transformatie niet regelmatig en herhaaldelijk werden gehouden, hadden ze geen namen en bleven ze daardoor ook niet in het geheugen hangen zoals bijvoorbeeld een "Sprint Planning Meeting".
De belangrijkste tip om niet meer bang te zijn dat je te veel tijd in meetings moet doorbrengen, is om de meetings kort te houden. Af en toe werk ik met teams die ik moet aanmoedigen om wat meer tijd te nemen voor hun meetings.
De meeste teams besteden echter te veel tijd aan de Scrum Meetings. Zodra je erin slaagt om ze kort en bondig te houden, zouden ze niemand meer angst moeten inboezemen.
Conclusie: Ontspan je… deze spoken zijn niet echt!
Door een spookhuis lopen en je verkleden is leuk, omdat we allemaal weten dat het alleen maar schijn is. De spoken, monsters, vampiers, weerwolven en gekken met een kettingzaag zijn niet echt.
En de vijf agile mythes die hier beschreven zijn, zijn dat ook niet. Het is niet vreemd om in het begin wat angstig te zijn. Voorlichting en ervaring zullen deze mythes echter snel ontmaskeren en je een veilig gevoel geven.
Maar als je zelf een beeld wilt vormen van de agile realiteit en de mythes rond Scrum & Co, neem dan een kijkje bij onze Agile Journey, waar we je de rollen uitgebreid voorstellen, of word nu gecertificeerd Scrum Master of volg onze Agile Leadership Training.
Deze tekst is afkomstig uit de blog van Mike Cohn en door ons vertaald naar het Duits.
Innovatie in het bedrijf
=> Wat kenmerkt innovatieve bedrijven?
Geleefde strategie
=> Ontdek hoe je jouw bedrijfsstrategie naar een hoger niveau tilt.
Onoverwinnelijke bedrijven
=> Hoe ziet modern innovatiemanagement er in een bedrijf uit?
