Het succes van agile valt of staat met een goede samenwerking binnen het team. Agile is hierop ingericht en het ondersteunt ook samenwerking. Het is namelijk geen ontwikkelmethodiek of ontwikkelproces. Dit heeft, zeker in grotere organisaties waar veel agile teams werken, nadelen. Zo wordt er vanuit agile bijvoorbeeld geen aandacht besteed aan vragen als ‘hoe ontwikkelen we onze software?’ ‘Welke eisen stellen we eraan?’ Of ‘Welke beslismomenten zitten er in het proces?’
Zodra in kaart is gebracht wat de agile-omgeving is, kan het team daarin een bijdrage leveren via projecten. Ieder team doet netjes de stand-ups en de andere agile-onderdelen en levert keurig zijn producten op. Maar welke plaats de oplevering inneemt in het geheel of enig besef omtrent de lange termijnwaarde van iets ontbreekt grotendeels. In het lineaire proces is de volgorde eenvoudig. Eerst verzamelen we de requirements, dan maken we het ontwerp, dan ontwikkelen we en volgt het testen – moduletesten, systeemtesten en acceptatietesten – waarna hetin productie kan worden genomen. Iedere stap levert zijn eigen te toetsen producten op en na iedere stap is er een go/nogo.
Voorspelbaarheid
Binnen agile werken we multidisciplinair en doen we alle activiteiten gelijktijdig. We gaan door tot het product gereed is om te laten zien. In de praktijk komt dat erop neer dat er veel variatie zit in de manier waarop iets worden ontworpen en ontwikkeld. Dit hangt namelijk af van de mensen die in het team zitten. Vergeleken met de lineaire methode neemt de voorspelbaarheid met werken volgens agile sterk af. Deze voorspelbaarheid kan worden vergroot door een aantal checks in te bouwen na iedere sprint. Hierbij kan je bijvoorbeeld kijken of de opgeleverde producten aansluiten op de producten van andere teams (functioneel en qua standaards) en of de producten qua tijdigheid op elkaar aansluiten. Als we voor een project bijvoorbeeld een front- en een backoffice ontwikkelen,is het zinvol om te weten of we eerst gezamenlijk werken aan het frontoffice en daarna aan de backoffice of dat dit kriskras door elkaar loopt. Voor de kwaliteit is het van belang dat we met de verschillende teams productgewijs werken zodat we in een vroeg stadium het systeem in zijn totaliteit kunnen uitvoeren.
Deel 1 van snelcursus agile plus
In de maarteditie van ICT Magazine verscheen het eerste deel uit deze serie. Daarin beschreef Bert van der Zee het belang van samenwerking binnen agile-teams. Een agile-team bestaat uit mensen uit verschillende disciplines en ook is de samenstelling van het team iedere keer anders. Het succes van ieder agile-traject valt terug te voeren op de mate waarin er werd samengewerkt. Hoe beter de verbinding binnen het team, hoe beter de samenwerking en hoe succesvoller de output of het succes.
Dat klinkt eenvoudiger dan het er in de werkelijkheid aan toe gaat. Ook gaf Van der Zee waardevol advies mee: “Door je beweeglijk op te stellen, houd je het langer uit met elkaar.” Maar hoe doe je dat? Hoe leer je elkaars habitat, elkaars eigenheden respecteren en accepteren? Dat kan dankzij spiegelneuronen. Dit zijn neuronen in onze hersenen die actief worden wanneer we iemand een bepaalde handeling zien uitvoeren. Spiegelneuronen zorgen voor sociaal begrip, voor het begrijpen van de interactie en ze zorgen ervoor dat we ons kunnen verplaatsen in de intentie van de ander. Ze werken echter niet als er iets gebeurt wat voor ons onbegrijpelijk is. Wanneer we iets tegenkomen wat wij in onszelf niet herkennen, kunnen we de ander dus niet begrijpen.
Om beter te kunnen afstemmen op de personen met wie je samenwerkt, zette de auteur de vier verschillende typen mens aan de hand van temperamenten die Carl Jung heeft gebruikt op een rijtje: de melancholicus, de sanguinicus, de cholericus en de flegmaticus. Tegelijkertijd waarschuwt Van der Zee: “deze menstypes vormen een aardige richtlijn, maar moeten niet vergeten dat mensen niet zijn onder te brengen in schema’s. Werkelijk oprechte belangstelling voor elkaar leidt tot wederzijds begrip. Dit kan geen schema of invullijst van ons overnemen.”
Buffers
Een ander punt in het ontwikkelproces is de planning en de uitvoering. Ieder agile-team hanteert een eigen planning en ieder agile-team heeftook een eigen buffer in deze planning om onvoorziene omstandigheden op te vangen. Dit zijn weliswaar kleine buffers, maar al deze kleine buffers van veel teams vormen tezamen een flinke buffer die niet als zodanig kan worden ingezet. Om gebruik te kunnen maken van deze buffer is het noodzakelijk dat de agile-teams onderling per sprintbepalen wie echt behoefte heeft aan eenbuffer en wie niet. Teams die met relatief eenvoudige sprints bezig zijn, werken dan strak op hun planning, zonder buffer. Teams die op het kritieke pad zitten of met iets moeilijks bezig zijn, krijgen de beschikking over de buffer.
Scrummaster plus
Om de buffers in de praktijk zinvol te benutten, moet iemand de rol vanoverall scrummaster op zich nemen, iemand die bufferbeheerder is en kwaliteitsbeheerder. Deze scrummaster is betrokken bij het testen van het integrale systeem en neemt dus een sturende taak op zich bij het ontwikkelen van de software. En hij is kwaliteits- en capaciteitsbewaker. Deze persoon is dus een scrummaster plus. De scrummaster plus heeft zijn focus op vier gebieden:
De samenwerking tussen de teams
- – In hoeverre sluiten de opgeleverde producten aan op elkaar en gebruiken we dezelfde kwaliteitsnormen?
De snelheid van het totale project
- – Wat is de ontwikkelsnelheid van alle teams? Deze snelheid wordt bepaald door het langzaamste team of het team dat de zwaarste opdracht heeft.
De verdeling van de sprints
- – Het kennis- en kundeniveau verschilt per team. Daarom is het verstandig om aan het begin van een project en aan het begin van een nieuwe sprint te evalueren of het werk door het juiste team gedaan wordt.
De verdeling van de buffers
- – Sommige teams hebben een buffer nodig om de opdracht goed te kunnen voltooien. Dit kan extra mankracht betekenen of meer tijd en faciliteiten die beschikbaar worden gesteld.
Opbouwen
De scrummaster plus heeft een vrije rol en mag communiceren met iedereen die in een scrumteam werkt. Er is niet een extra organisatielaag die uitsluitend met de scrummaster communiceert. Hij heeft geen leidende rol in het ontwikkelproces, maar een adviserende. Wel bewaakt hij de kwaliteit en de buffer. Daarin heeft hij een beslissende stem. De rol van de overall scrummaster is bepaald niet eenvoudig en er zijn maar weinigmensen die zo’n brede kennis hebben en voldoende ingangen hebben om dit allemaal te kunnen realiseren.
Het daarom goed je te realiseren dat het opbouwen van deze rol binnen een agile-organisatie enige tijd zal vergen. In ervaren agile-organisaties lopen sinds een tijdje agile-coaches rond, mensen die losse teams begeleiden. Bezien vanuit het kostenaspect is datvrij duur, omdat de coach niet direct betrokken is bij het ontwikkelen. De scrummaster plus is daar wél bij betrokken en levert daarom meer op voor een organisatie. Mijn advies aan de agile-coaches is dan ook: zorg ervoor dat je zo snel mogelijk scrummaster plus wordt!
