Management verantwoordelijkheid bij zelfsturende scrumteams 

Volgens de theorie is een scrumteam zelfsturend. De product owner bepaalt WAT er moet gebeuren en met welke prioriteit. De developers bepalen HOEVEEL ze binnen een sprint kunnen doen, HOE ze het gaan doen en WIE het gaat doen. De scrum master coacht het team en de omgeving. Je zou kunnen denken dat het lijnmanagement achterover kan gaan leunen. Maar dat is zeker niet het geval. Het lijnmanagement is nog steeds cruciaal. Deze blog gaat over de verantwoordelijkheid van het lijnmanagement bij de implementatie van scrum en daarna. Deze wordt behandeld vanuit drie aspecten: organisatie, mensen en hulpmiddelen.

Organisatie
De wens om met scrumteams te gaan werken komt meestal voort uit de wens of de noodzaak om meer agile en lean te werken. Zoals in de blog ‘Met Lean naar Scrum’ al is aangegeven, is scrum EEN oplossing om meer agile en lean te werken, maar zijn er vele andere oplossingen denkbaar, die wellicht beter aansluiten op de organisatie. De keuze om meer agile/lean te werken en of daarbij gebruik wordt gemaakt van scrum, is de verantwoordelijkheid van het lijnmanagement. Als het lijnmanagement er niet voor 100% achter staat, en dat uitdraagt, is de implementatie gedoemd te mislukken.

Als het besluit om met scrumteams te werken eenmaal is genomen, volstaat het niet om tegen de werknemers te zeggen dat ze zelf teams moeten formeren. Het managent zal een besluit moeten nemen over de scope van de scrumteams in termen van werkzaamheden. In theorie zou een scrumteam in staat moeten zijn om een hele change zonder hulp van buitenaf te ontwerpen, realiseren, testen en implementeren. Bij DevOps teams komt daar ook het beheer bij. Soms alleen het technische beheer, soms ook het functionele beheer. In de praktijk zie je dat bepaalde expertises buiten de teams worden belegd. Soms gaat dat om schaarse, specialistische expertises die het team maar af en toe nodig heeft, zoals DBA-ers. Soms worden hele delen van het proces buiten scope gelaten, zoals regressietests, acceptatietests en implementatie.

Als eenmaal is vastgesteld DAT er met scrumteams gewerkt gaat worden en welke expertises daarin zitten, komt de vraag of de werkzaamheden in één team kunnen worden uitgevoerd. Meestal zal het antwoord ‘nee’ zijn. Het is dan de verantwoordelijkheid van het lijnmanagement om te besluiten hoeveel teams er komen en wat de inhoudelijke scope-afbakening wordt. Die scope-afbakening moet dusdanig zijn dat de afhankelijkheid tussen de teams zo klein mogelijk is. Meest gebruikelijk is het toewijzen van hele applicaties aan teams. Of, bij grote applicaties, het toewijzen van modules. De ontwikkelaars hoeven dan alleen kennis over de applicaties in scope op te bouwen. Ze kunnen ook zelfstandig fundamentele besluiten nemen over deze applicaties, zoals ten aanzien van inrichting en documentatie. Het is wel verstandig om de beoogde teamleden te betrekken in de knip tussen de verschillende teams.

Tot slot is de vraag hoe de teams gaan samenwerken. Er zijn verschillende ‘scaled agile frameworks’, zoals Less, Nexus, ‘Spotify’ en SAFe. De eerste twee gaan alleen over de samenwerking met betrekking tot de op te leveren changes. De laatste twee gaan ook in op de samenwerking tussen mensen met dezelfde expertise binnen verschillende teams. Bijvoorbeeld een samenwerkingsverband van alle analisten, testers of Java-programmeurs. De keuze van de samenwerkingsvorm moet door het lijnmanagement worden gemaakt. Veel organisaties hebben momenteel nog hun eigen samenwerkingsvorm. De laatste jaren komt SAFe echter steeds meer bovendrijven als een markt standaard. Dat framework wordt ook steeds uitgebreider. De laatste versie, versie 5, beschrijft het belang van het management, de alignment met het strategisch management, het inrichten van teams met specialisten buiten de scrumteams (system teams en shares services) en overleg tussen mensen met dezelfde expertise (communities of practices). Ook beschrijft het hoe je SAFe kan implementeren en hoe je daarbij de teamafbakening kunt bepalen. SAFe beschrijft ook hoe je daarbij meerdere niveaus kunt gebruiken (portfolio, solutions trains en release trains).

Bij het gebruik van scrum verandert de verantwoordelijkheid van het lagere lijnmanagement. Lagere lijnmanagers zullen hun mensen niet meer dagelijks aansturen. Het werk zal nu worden verstrekt door de product owners. Het scrumteam stuurt zichzelf aan en wordt daarbij gecoacht door de scrum master. Het lijnmanagement blijft wel de HR taak houden. Doordat hun rol beperkter is, zie je vaak dat het aantal lijnmanagers op dit niveau wordt teruggebracht, of dat er zelfs een laag lijnmanagers verdwijnt. De scrum master en de developers vallen vaak onder het lijnmanagement van IT. Product owners hebben een inhoudelijke rol en vallen daarom vaak onder het lijnmanagement van de business. Die heeft daarbij vaak naast de HR taak ook de taak om de inhoudelijke richting aan te geven. Omdat de product owner het scrumteam niet als lijnmanager aanstuurt, kan het lijnmanagement de product owner zelf niet overal verantwoordelijk voor houden. Er ontstaat zodoende een soort matrix organisatie, met via de ene as de HR aansturing en via de andere as de inhoudelijke aansturing. Technische changes, vroeger het domein van het lijnmanagement van IT, komen nu ook op het bordje van de product owner te liggen. Hij zal het belang van deze changes ten opzichte van de functionele changes moeten afwegen.

De organisatie zal minder behoefte hebben aan projectmanagers. De changes die normaal door kleine projecten worden gerealiseerd, zullen vaak in hun geheel belegd kunnen worden bij één scrumteam en worden gewoon vanuit de backlog van dat team gemanaged. Voor grotere initiatieven is coördinatie en afstemming over de teams nodig. Daarvoor zijn nog steeds projectmanagers nodig, al hebben die dan een regiefunctie, en geen eigen projectteam. In het ‘spotify’ model worden ze IT integrators genoemd. In SAFe epic owners.

De scrumteams kunnen zelf invulling geven aan de organisatie aspecten binnen hun team. Ze kunnen zelf invulling geven aan de ‘scrum events’ en hun ‘definition of done’ bepalen (als er meerdere scrumteams zijn, zullen ze dat wel met de andere teams moeten afstemmen). Ze zijn ook zelf verantwoordelijk voor het verbeteren van hun proces. Ook kunnen ze, binnen de kaders van het gekozen framework, de samenwerking met andere teams zelf invullen.

De wereld verandert continue. Het lijnmanagement zal dus regelmatig moeten checken of het aantal teams en de scope per team nog optimaal is, en of de samenwerkingsvorm nog voldoet. Omdat het scrumteam verantwoordelijk is voor het verbeteren van het eigen proces, kunnen ook uit die hoek wijzigingsvoorstellen komen.

In figuur 1 is het verschil tussen een traditionele organisatie en een scrum organisatie schematisch weergegeven. In het plaatje zijn de teammanagers na de implementatie helemaal verdwenen, maar het kan ook zijn dat dit er alleen minder worden. De samenwerking tussen de scrumteams is voor de overzichtelijkheid weggelaten.

Figuur 1: Impact van scrum op de organisatie structuur

Mensen

Als duidelijk is welke teams er zijn, en wat hun scope is, moeten de teams bemenst worden. Het aanstellen en toewijzen van mensen aan teams blijft ook bij scrum een taak van het lijnmanagement. Natuurlijk is het verstandig dat dit met de mensen zelf wordt afgestemd, maar als het volledig aan die teams wordt overgelaten, bestaat de kans dat de kwaliteiten niet evenwichtig verdeeld worden of dat er mensen buiten de boot vallen die wel goed in hun werk zijn, maar minder populair.

Werken in een zelfsturend scrumteam is anders dan in een traditioneel team. Het betekent dat je ook initiatief moet durven nemen, elkaar durft aan te spreken of om hulp durft te vragen, zelf met verbeterpunten komt en bereid bent om zaken op te pakken die niet jouw primaire expertise zijn. Wellicht hoeft niet iedereen in het team aan al die kwalificaties te voldoen, maar er moeten voldoende mensen in het team zitten die dat wel doen, om het team te laten slagen. De rollen product owner en scrum master zijn nieuw en moeten worden vervuld door mensen die daarvoor geschikt zijn. Het zonder meer benoemen van mensen die vrijvallen bij de reorganisatie, zoals teammanagers en projectmanagers, is niet verstandig. Eén en ander betekent dus feitelijk een reorganisatie, waarbij de medewerkers en de OR betrokken moeten worden. Het kan betekenen dat men afscheid van mensen moet nemen, mensen moet omscholen en/of andere mensen moet aantrekken.

Alle mensen die een rol krijgen in de nieuwe organisatie moeten in ieder geval getraind worden in de nieuwe aanpak en de achterliggende mindset. Met name dat laatste is erg belangrijk, de overstap naar de scrumaanpak vergt immers een grote cultuurverandering. Het management moet daarbij rekening houden met het feit dat het minimaal een half jaar duurt voor een team optimaal is ingewerkt. Het management en de andere stakeholders buiten het team, moeten begrijpen wat de impact van de reorganisatie is. Volgens de theorie zouden de scrum masters de rol van coach moeten kunnen vervullen. Als zij dat (nog) niet kunnen, is het verstandig om de organisatie tijdelijk uit te breiden met scrum coaches.

Scrum gaat er vanuit dat het team dagelijks fysiek bij elkaar is. Het lijnmanagement moet daarom kaders stellen voor het parttime werken en het thuiswerken. Als het lijnmanagement heeft aangegeven dat parttime- en/of thuiswerken mag, en onder welke voorwaarde, kunnen de teams zelf bepalen hoe ze daar verder in de praktijk mee omgaan.

Het team moet zelf aangeven of het aanvullende technische kennis nodig heeft. Zo is er wellicht DBA kennis nodig, of moeten ontwerpers en testers op een programmeercursus zodat ze zelf kleine aanpassingen kunnen verrichten. Het lijnmanagement moet dit faciliteren en actief promoten.

Tot slot heeft het lijnmanagent zijn HR taken en zal het zijn medewerkers moeten motiveren, beoordelen en helpen ontwikkelen. Het zal commitment moeten tonen voor de nieuwe aanpak en het goede voorbeeld geven.

Hulpmiddelen

Zoals aangegeven bepaalt het zelfsturende team HOE het werkt. Daaruit kan de wens voor bepaalde technische hulpmiddelen naar voren komen, zoals een scrumboard, of een applicatie waarin de user stories en taken en hun status vastgelegd kunnen worden (elektronisch scrumboard). Het lijnmanagement zal moeten zorgen dat die hulpmiddelen er komen, maar ook dat er geen wildgroei aan hulpmiddelen ontstaat, doordat ieder team een ander hulpmiddel wil voor hetzelfde doel.

Met scrum wordt er kort-cyclisch gewerkt. Dat betekent veel kleine opleveringen. Dat resulteert weer in veel regressietests en implementaties. SAFe spreekt in dit kader van ‘continuous integration’ en ‘continuous deployment’ (CI/CD). Als dat handmatig moet gebeuren, kost dat teveel tijd. Sommige organisaties lossen dat op door de regressietest en implementaties buiten de scope van het scrumteam te plaatsen, maar dat betekent automatisch een veel langere doorlooptijd. Een automatische regressietest en automatische implementatie is een veel betere oplossing. Ook hier geldt weer dat de benodigde tooling daarvoor door het management beschikbaar moet worden gesteld en dat wildgroei aan tooling voorkomen moet worden. Het zal ook moeten accepteren dat de initiële inrichting van een automatische regressietest en implementatietooling veel tijd kost, die ten koste gaat van functionele wijzigingen. Die tijd wordt later echter terugverdiend.

De teams moeten hun software kunnen ontwikkelen zonder andere teams in de weg te zitten. Optimaal is daarom dat elk team zijn eigen ontwikkelomgeving krijgt voor zijn applicaties. Interfaces met applicaties van andere teams kunnen met zogenaamde ‘stubs’ worden afgevangen. Voor de integratietest zou elk team een aparte, stabiele omgeving beschikbaar kunnen stellen, waar andere teams tegenaan kunnen testen.

Tot slot is het budget een belangrijk hulpmiddel. Veel organisaties kennen budgetten voor het beheer en budgetten voor changes. Het beheerbudget van een afdeling ligt meestal voor een jaar vast. De changebudgetten worden aan projecten toegewezen en niet aan afdelingen. Als een afdeling onvoldoende capaciteit heeft om aan de vraag van een project te voldoen, kan zij met het changebudget tijdelijke capaciteit inhuren. Met de introductie van scrumteams verandert dat. Doordat het scrumteam een min of meer vast team is, en er dus niet meer per project mensen worden ingehuurd, staat het totaal benodigde budget min of meer vast. Idealiter komt er daarom ook maar één budget voor de scrumteams. Uitsplitsing is niet nodig omdat de product owner er immers al voor zorgt dat de capaciteit, en dus het budget, wordt ingezet voor die zaken die de meeste klantwaarde opleveren. Veel organisaties willen het budget echter toch nog verbijzonderen. De product owner moet dan niet alleen bepalen welke userstories de meeste prio hebben, maar ook rekening houden met het nog beschikbare budget voor de betreffende change. In het ergste geval kan hij userstories met een hoge prio, vanwege budgettekort, niet uit laten voeren. Als het budget van verschillende sponsors komt, of als projectkosten als investering worden gezien waarover kan worden afgeschreven, is verbijzondering niet altijd te voorkomen. De stakeholders moeten dan budget meenemen voor de userstories die ze inbrengen. Het ligt voor de hand de uitnutting van het budget door de product owner te laten bewaken. Hij heeft immers het meeste zicht op de omvang van de changes (en dus het benodigde budget) en wat er al is uitgegeven en gerealiseerd.

Samenvatting

Samenvattend kan gesteld worden dat het lijnmanagement randvoorwaardelijk is voor een goed functionerende scrum organisatie. De HR taak blijft sowieso bij het lijnmanagement liggen. Daarnaast zijn zij richting gevend en ondersteunend. De medewerkers krijgen meer invloed op hun eigen werk en de onderlinge taakverdeling.

Figuur 2: Samenvatting verantwoordelijkheid lijnmanagement versus scrumteam.