Het was kennelijk het vijfde increment, maar voor mij het eerste dat ik bijwoonde. Wat ik heb onthouden is de dolfijn! Deze duikt onder, maar komt snel weer naar boven. En laat zien wat aan het product is gedaan, om feedback te ontvangen, om bij te stellen en weer verder te gaan. Kennelijk was een ‘increment’ een dolfijnsprongetje en was ik getuige van het vijfde.
De programmamanager tekende op het bord een neerwaartse curve die van hoog op de y-as diep tot de x-as liep en vervolgens even steil weer omhoog. Dat was de ‘duikboot’. Ze vertelde dat ontwikkelaars van bijvoorbeeld software in het verleden vaak zo te werk gingen. Ze begonnen met de ontwikkeling van een product, lange tijd hoorde je niets meer van ze, ze werkten hard maar wel in splendid isolation, om later naar boven te komen met het eindproduct. Tadaa, het was af! Het kon niet meer worden aangepast als de wensen van de klant of de omstandigheden in de markt waren bijgesteld. Ontevreden klanten, gefrustreerde ontwikkelaars, verspilling van tijd, geld en talent. Nee, nu ging het anders.
De programmamanager tekende in dezelfde grafiek een rijtje sierlijke golfjes. Dat was de ‘dolfijn’. Deze duikt ook onder, maar komt snel weer naar boven om adem te halen. En om een blij sprongetje te maken, vulde ik zelf maar aan. De dolfijn komt naar boven om te laten zien wat er al aan het product is gedaan, een stukje of een versie, om feedback te ontvangen, om bij te stellen en weer verder te gaan. En na een tijdje, een paar weken, komt de dolfijn weer naar boven.
Mijn beschrijving klinkt kinderlijk voor de mensen die gewend zijn om ‘Agile’ te werken. Voor een buitenstaander is het abracadabra. Als deze werkwijze is bedoeld om transparanter en toegankelijker te zijn, dan helpt het jargon met sprints, product owners, scrum masters, backlogs, impediments en the definition of done niet echt. De programmamanager zei: “in het donker zet je toch ook kleine stapjes?” Dat kon ik weer prima volgen. Mijn introductie in de wereld van Agile en scrum was een feit.
Is projectmatig werken passé?
Dat traditioneel projectmatig werken niet altijd ideaal is ervaren we allemaal. Een projectplan schrijven is een oefening in koffiedik kijken, onderbouwd met waarschijnlijkheden, het geloof in een maakbare wereld en een flowchart-werkelijkheid. Wat ook helpt dat is taal. Taal helpt om houvast te bieden, maar ook om ruimte te creëren, om interpretaties in te bouwen voor alle belangen en uiteindelijk min of meer richting te geven. Doelen en resultaten formuleren in een projectplan is nog betrekkelijk eenvoudig vergeleken met het maken van een realistische tijdsplanning en een haalbare begroting. Toch zal de gemiddelde manager juist zo’n projectplan verlangen. Dat kan hij mooi aan zijn stuurgroep voorleggen om op deze manier met schijnbare zekerheid te kunnen sturen op de gestelde doelen. Voor veel standaard producten en voorspelbare processen is dit toch de best mogelijke methode. Tegenwoordig gaan dingen echter net wat sneller dan het tempo waarop we daarop kunnen anticiperen, zijn er onzekerheden die we helemaal niet kunnen voorspellen en weten we soms niet eens wat we niet weten. Maar, als alles vastleggen in een projectplan niet de manier is, wat dan wel?
Ik volgde, na mijn dolfijn-experience, een cursus voor scrum masters. Scrum is een manier van Agile werken. Ik was benieuwd of scrum ook voor niet ICT-projecten van toepassing kan zijn. Mijn medecursisten waren overigens voornamelijk mensen uit de ICT-wereld, die net wat soepeler omgingen met abstracties en werkprocessen, dan ik dat deed. Een cultuurkloofje, laat ik maar zeggen. Het duurde even voordat ik de vertaling maakte van ‘product owner’ naar de persoon die beschrijft wat de wensen zijn van de klant, deze terugkoppelt aan het team dat een product moet maken en daarmee in verbinding blijft. En dat een ‘user story’ dus gewoon een wens is van een klant. Jargon en taalgebruik kunnen verbinden en ook vervreemden, wil ik maar zeggen. Scrum is niet alleen een werkwijze en een kader, maar ook een filosofie en een overtuiging. Dat kan ervoor zorgen dat het gedachtegoed ontoegankelijk wordt voor buitenstaanders.
Shoppen binnen scrum
Wat ik heb opgehaald uit mijn introductie in de wereld van scrum is dat het in elk geval belangrijk is om manieren te vinden om telkens met elkaar te kijken of je op de goede weg bent. Om kennis, ervaringen en inzichten uit de dagelijkse praktijk steeds binnen te halen. Om te voorkomen dat je wordt opgesloten in een project en niet meer naar buiten kijkt. De scrum-manier met kleine stapjes in het donker helpt wel.
Beter contact tussen wat je traditioneel de ‘opdrachtgever’ zou noemen en de ‘leverancier’ is een tweede punt. Als je telkens zichtbaar bent en laat zien wat je al af hebt, ontstaat dat contact bijna vanzelf. Dan kan er beter worden afgestemd en bijgestuurd. Als de opdrachtgever nog niet helemaal helder voor ogen heeft wat hij wil, dan helpt dit al werkende om specifieker en gerichter te sturen op de wensen. Er is niet alleen achteraf, maar gedurende het proces veel ruimte voor voortschrijdend inzicht. Aan de andere kant is de opdrachtgever, c.q. product owner de schakel naar de klanten, c.q. stakeholders en hun wensen. Vaak komt er geen eind aan wensen. Het helpt om te focussen op wat echt bijdraagt aan bijvoorbeeld meer waarde en betere dienstverlening voor de klant. Dat gesprek wordt binnen scrum voortdurend gevoerd.
Voor beter contact en meer commitment is een kleiner team fijner en wendbaarder om in te werken. Bij scrum gaat de voorkeur uit naar teams van minimaal drie en maximaal negen leden. Dagelijks beginnen met een kort werkoverleg om het werk te bespreken dat op die dag moet worden gedaan helpt enorm. Niet alleen om de taken door te nemen, maar ook om de werkdruk en de planning in de gaten te houden. Er pas na maanden achter komen dat een team zwaar overbelast is, bepaalde kennis mist of dat er andere belemmeringen zijn die het werk in de weg zitten, is de spreekwoordelijke mosterd na de maaltijd. Het team heeft een eigen verantwoordelijkheid als het gaat om de rolverdeling. Mensen weten zelf het beste hoe ze bij kunnen dragen aan het gewenste resultaat. Samenwerking groeit dan vanzelf binnen het team.
Hoewel scrum met goede begeleiding al vanaf de eerste dag kan worden toegepast vergt het toch een lange ‘inleeftijd’. Het is niet alleen een werkwijze, maar een mindset. Veel vanzelfsprekendheden moeten op de schop. Voor mensen die gewend zijn om te werken met projectplanningen, SMART-doelen en uitgebreide projectverantwoordingen, is scrum een hele omschakeling.
Slim en flexibel samenwerken kan op vele manieren. Als er tussen afdelingen bijvoorbeeld niet goed wordt samengewerkt, dan gaat scrum dat ook niet in een dag oplossen. Het helpt als er binnen een organisatie al zelfsturende teams zijn, als teamverantwoordelijkheid hoog in het vaandel staat en er een open werkcultuur is. Of scrum de oplossing is voor alle organisatieproblemen en het alternatief is voor elk denkbaar mislukt project durf ik niet te zeggen. Maar je hoeft niet alle elementen en het hele pakket te gebruiken, maar die verbeteringen die je verder brengen.