Scrummenarij

Door Jaap Kloppenburg op 22 jul 2017

Ik scrum, hij scrumt, zij scrummen, wij hebben gescrumd….

Zullen we er zo op terug kijken als we 5 jaar verder zijn? Zo van: ‘Wat hadden we gescrumd!’ Nu – anno 2017 – is dat bijna niet voor te stellen. Scrum is in. Iedereen scrumt. Als je niet scrumt, wat doe je dan nog wel? Toch geen waterval?!! Dat is zo van de vorige eeuw! Scrum! Het toverwoord van deze tijd! Het wondermiddel van de 21^e eeuw! Iedereen doet doet het. Iedereen gelooft er in. Met scrum zijn alle problemen met mismatches en verbaasde gebruikers, met alle communicatieverschillen, met planningsverschillen, met uitloop enzovoort voorbij! …… Toch? En toch….

In deze blog wil ik stil staan bij het belang van de context van de organisatie waarbinnen scrum succesvol wordt toegepast. Als er sprake is van een organisatorische context waarbinnen scrum succesvol kan worden toegepast, impliceert dat, dat er ook een organisatorische context is, waar dit niet het geval is. Deze bewering roept misschien wat weerstand op. Scrum-evangalists zullen misschien het tegendeel beweren. Met deze beschrijving vanuit de praktijk, wil ik de de bewustwording stimuleren dat scrum een toepasselijke werkmethode kan zijn, maar niet in alle gevallen hoeft te zijn.

Scrum

De ideeën wat scrum is en hoe het moet worden toepast zijn helder. Zie bijvoorbeeld de website van (iSense) Prowareness over scrum: www.scrum.nl. Scrum gaat uit van een evolutionair ontwikkelmodel waarbij de functionaliteit van een applicatie meegroeit met het inzicht van de gebruiker en waarbij een periodieke kortcyclische terugkoppeling wordt gerealiseerd met demonstraties van nieuwe functionaliteit en frequente releases. Het scrumproces wordt afgehandeld door een min of meer autonoom team. Of zoals het in de organisatiekunde wordt genoemd: een zelfsturend team. Het team bepaalt zelf hoe wordt voldaan aan de gestelde prioriteiten. Hier wordt het principe van decentralisatie toegepast: verantwoordelijkheden en taken worden decentraal bij het scrumteam/zelfsturende team belegd. Het team bepaalt namelijk zelf wat wanneer kan worden opgepakt en hoeveel tijd er aan moet worden besteed.

De genoemde concepten maken al helder dat scrum meer is dan een andere manier van plannen of een andere presentatie van de planning. Het is een andere werkwijze (1), die vraagt om duidelijk meer betrokkenheid van de (hoofd) gebruikers (2) en vraagt om een andere aansturing qua management (3) en qua planning (4). Deze werkwijze vraag ook om andere vaardigheden en interesses in het ontwikkelteam (5). Met deze 5 aspecten wil ik scrum plaatsen in de organisatorische context.

Werkwijze

Het centrale principe achter een zelfsturend team is vertrouwen. Het management moet het team het vertrouwen geven om zelfstandig haar taak te doen. Dit botst met bijvoorbeeld het principe van controle van bovenaf. Een typische machine bureaucratie wordt juist ingericht vanuit de visie dat alles van bovenaf moet worden gecontroleerd. Het invoeren van scrum in zo’n bureaucratische organisatie, plaatst het ontwikkelteam in een uitzonderingspositie die wezensvreemd is aan de organisatie. Niet iedereen zal daar dan begrip voor hebben of zich daaraan kunnen aanpassen.

Het verschil zit diep, namelijk in de cultuur. Deze cultuur wordt gevormd door normen en waarden. Dit cultuurverschil mag niet onderschat worden. Aan de ene kant de vrijheid van het zelfsturende team met als norm dat besturing plaats vindt vanuit een vorm van zelfbeschikking en aan de andere de bureaucratisch ingerichte organisatie waarbij de van bovenop opgelegde aansturing met regels en controle de norm is voor aansturing. Veel R&D afdelingen zitten in een soortgelijke uitzonderingspositie. De vraag is of de softwareontwikkeling een zelfde geïsoleerde positie in de organisatie kan innemen als R&D.

Het verschil in werkwijze kan ook worden ingegeven door de opzet van een project. Voor bepaalde projecten wordt van te voren vastgesteld wat wanneer moet zijn opgeleverd. Dit betekent veelal dat vooraf bekend is wat de oplossing is en wat daarin de planning is. De aansturing wordt daarmee van bovenaf opgelegd. Een scrumteam kan in zo’n geval slechts de schijn van zelfsturing hoog houden. Op het moment dat een scrumplanning over het budget gaat, zal hierop vanuit de projectleiding worden gestuurd.

Gebruikersparticipatie

Om te scrummen heb je de gebruiker nodig. In het scrumteam wordt deze vertegenwoordigd door de Product Owner. Hiermee wordt een volledige afhankelijkheid van de gebruiker voorkomen. Op het moment echter, als de Product Owner de gebruiker volledig vervangt, wordt het scrumsproces wat onnatuurlijk. Vergelijk het met een verjaardagsfeestje zonder jarige. In het proces van het onderkennen van behoeften, het vertalen van deze behoeften naar veranderingen in het systeem en de controle of de systeemwijzigingen hun toegevoegde waarde hebben in de praktijk, speelt de gebruiker de cruciale rol. De gebruiker doorgrondt zijn eigen werkzaamheden en weet wat daar bij nodig is.

De organisatie die gaat scrummen zal gebruikers vrij moeten maken om deel te kunnen gaan nemen aan het scrumproces. Peace of cake zou je denken! Alleen blijkt dat in de praktijk nogal tegen te vallen. Het dagelijkse werk van de gebruiker gaat ook door. Veelal wordt eerder gedacht dat de gebruiker de scrumtaken er wel bij kan doen, dan dat de gebruiker echt vrij wordt gemaakt om te kunnen participeren in het scrumproces. Juist omdat scrum nogal afhankelijk is van deze gebruiker, vormt een gebruiker die onvoldoende tijd heeft een groot risico. Een evident risico is dat de voortgang van het proces in gevaar kan komen. Minder evident is het risico dat er een misverstand ontstaat over de behoeften/wensen van de gebruiker; omdat de gebruiker onvoldoende tijd heeft zich te verdiepen in de voorstellen, gaat hij akkoord met voorstellen die hij niet helemaal overziet en veronderstelt dat dat wel goed zit. Als op een later tijdstip blijkt dat het anders is dan was verondersteld, moeten alsnog de herstelwerkzaamheden worden uitgevoerd die men met scrum wilde voorkomen.

In andere trajecten is er helemaal geen gebruiker in beeld, bijvoorbeeld omdat het processen betreffen die gebruikers nauwelijks aangaan. Of omdat het over zaken gaat waar gebruikers op lange termijn mee te maken krijgen, zoals in R&D projecten, nadat het ontwikkelde concept wordt toegepast in een product. Bij R&D kan de voorwaarde om kortcyclisch werkende releases op te leveren zelfs knellend werken voor het R&D proces

Management

Een zelfsturend team vraagt een andere managementaanpak. Het is niet zo dat een luie manager nog verder achterover kan leunen, zo van, die scrummers besturen zichzelf wel. En voor een manager die gewend was dat hij de controle had, betekent het niet dat hij alle controle kwijt is. Een zelfsturend team manage je door doelen te stellen en te bewaken, door coaching of andere technieken waarbij de zelfsturing door het team wordt gerespecteerd. Deze andere aanpak, betekent dat er ook andere vaardigheden worden gevraagd van het management. Managers in een bureaucratische organisatie, zijn geselecteerd om binnen die structuur, volgens die norm leiding te geven. Deze managers beschikken niet als van zelf over de juiste inzichten en vaardigheden om een zelfsturend team of scrumteam te managen.

Planning

Een ander element in de organisatorische context van een scrumteam is, zoals hiervoor al is aangegeven, de manier waarop het project en de planning is opgezet. Een aanbesteed project waarbij de specificaties vooruit volledig zijn uitgedacht en waarin de mijlpalen voor oplevering zijn vastgelegd, leent zich niet heel goed voor scrum. Feitelijk is het idee achter deze wijze van aanbesteding dat van de waterval-aanpak.

Hoewel de zekerheid die wordt verkregen via deze watervalplanning ten dele schijn is, biedt het toch enige houvast die scrum vanuit haar aard niet geeft. In principe wordt bij scrum pas aan het begin van een sprint in een planningspokersessie definitief bepaald hoeveel punten aan een wijziging wordt besteed. Deze punten geven zuiver beschouwd enkel een indicatie voor het tijdsbeslag dat nodig is voor een wijziging (taak). Overkoepelend over de sprints worden ook aan de Epics (die in meerdere sprints worden gerealiseerd) punten toegekend. Ook deze punten zijn indicatief van aard voor de verwachte te besteden tijd.

In de praktijk kom je wel tegen dat scrum wordt toegepast in een project dat is gepland volgens de mijlpalen methode. En als dan de dingen, zoals Murphy stelt, slechter worden onder druk, wreekt zich het verschil tussen de in principe zachte planning van scrum en de harde eis van de mijlpalen. En eigenlijk wreekt zich hier het moment dat er commitment wordt gegeven aan een planning. Bij scrum commit het scrumteam zich pas aan een planning op het moment dat in een planningspoker de sprintplanning is vastgesteld. Een projectplanning krijgt van begin af het commitment van de projectleiding.

Ontwikkelteam

Het laatste element in de organisatorische context waar ik hier aandacht voor wil vragen en dat van belang is bij de overweging of scrum de meest passende manier van werken is, is het ontwikkelteam zelf. Het scholingsniveau van ontwikkelaars varieert van MBO+ tot en met WO. De interesses zijn heel divers: van heel technisch tot functioneel gericht. De vraag is in hoeverre de scrumaanpak en de scrumtaken passen bij het ontwikkelteam dat tot de beschikking staat van de organisatie. Vindt dit team het leuk om zich bezig te houden met planningen, demo’s, interactie met de gebruikers en andere niet-programmeertaken. En is het daartoe ook in staat? Vind dit team het leuk om vergaand samen te werken? Of vinden de verschillende ontwikkelaars het leuk om zelf uit te vinden hoe iets werkt. Zijn het mensen die oplossingen verzinnen of zijn het juist mensen die vooral oplossingen implementeren? Wat spreekt hen aan in het softwareontwikkelvak? Daagt scrum hen uit of jaagt het hen weg?

Een ander teamgerelateerd aspect is de mate waarin het team kan samenwerken door geografische spreiding en tijdsverschillen. Demo’s en stand-ups moeten bij voorkeur op 1 moment gehouden worden en elke teamlid moet daar zo veel mogelijk bij aanwezig zijn. Geografische spreiding is op te lossen met techniek. Tijdsverschillen moeten worden meegenomen in de planning. Ideaal gezien echter, zit een scrumteam op 1 locatie en zijn de teamleden vrijwel gelijktijdig aan het werk.

Passende tooling is essentieel voor het slagen van de missie

Tot slot

Het mag duidelijk zijn dat dit enkel wat eerste notities zijn vanuit de praktijk. Over dit onderwerp valt meer te zeggen. Net als Mintzberg (een organisatiekundige) ben ik uitgegaan van het getal 5: ik heb 5 elementen uit de organisatorisch context genomen om onder de aandacht te brengen. Wellicht zijn er meer aspecten te bespreken. En zijn er meer uitgangspunten te vergelijken. Ik hoop dat ik met deze blog een stukje bewustwording heb bewerkt, dat overwogen moet worden of scrum de meest geschikte methode is. Scrum is op zich genomen een goede werkwijze waarmee veel goede resultaten zijn geboekt. Dat geldt ook voor het onderliggende evolutionaire ontwikkelmodel. Het zou jammer zijn als scrum over een aantal jaar als “hype” wordt afgedaan, doordat scrum nu ondoordacht in allerlei situaties wordt toegepast en in een aantal gevallen ontoereikend lijkt te zijn. Een passende organisatorische inbedding bepaalt voor een groot deel het succes van de implementatie van scrum. En ook daarvan zijn in de praktijk goede voorbeelden te vinden.