De voorbije maanden heb ik veel tijd gespendeerd aan uitleggen aan ‘de business’ (in mijn geval vooral redactie en marketing) waarom sommige zaken langer duren om te ontwikkelen voor digitale platformen. Evenveel tijd heb ik al gestoken in uitleggen aan onze technologische vrienden dat het ook voor een groot deel aan hen ligt dat ik die discussies tot vervelens toe moet voeren. Ik heb geprobeerd in deze blogpost dat wat meer helder te krijgen voor mezelf en er ook een tekeningetje bij te halen.
Hoe de business soms nog denkt
Ik kan alleen spreken voor media, en daar zie ik dat onze ‘business’ soms nog lineair denkt als het gaat om het opleveren van digitale producten. Het is al veel verbeterd, maar het blijft toch hardnekkig. Niet zo raar trouwens, want een nieuwsredactie werkte in het verleden grotendeels lineair: bedenken, schrijven/opnemen, bijschaven, publiceren, distribueren. Een proces dat in de loop van 100 jaar tot in de puntjes is verfijnd. Een heel efficiënt proces bovendien, dat het mogelijk maakt om elke zoveel uur, dag, week een vers product voor de lezer te presenteren. En door de jaren is daar ook wat speling op gekomen: de machine zit zo in de vingers, dat aanpassingen er nog snel worden tussengefietst. Dat is aangenaam en spannend werken, op het scherp van de snee.
Hoe technologie ontwikkelen werkt
Ik dacht tot een jaar of twee geleden ook ‘lineair’, of toch zeker over dit onderwerp. Ik heb dat helemaal omgegooid, omdat het gewoon niet opgaat voor technologische ontwikkelingen. Om te beginnen moeten veel dingen vaak voor de eerste keer gedaan worden, uitgevonden bijna. Daarom moet alles uitvoerig worden getest, waarbij dingen soms niet blijken te werken. Dan moet je terug naar af. Niets eindproduct. Opnieuw beginnen.
Ook mogelijk: je hebt dat twee jaar geleden gebouwd, maar ondertussen is er ergens anders iets nieuws gekomen waardoor je ontwikkeling verouderd is, of niet meer past in de nieuwe systemen. Of je bedrijf is overgenomen door een ander, en die werken nu toch wel net met die andere oplossing zeker… Ook opnieuw beginnen.
Even lang dacht ik ‘we zetten daar gewoon volk bij’, dan gaat het sneller. Maar dat helpt ook niet zomaar. De metafoor die collega’s daarbij gebruiken is: ‘je kunt 3 vrouwen ook niet samen een zwangerschap laten reduceren tot drie maanden'. Dat wil zeggen dat sommige zaken de tijd nodig hebben die ze nodig hebben: noden capteren, analyseren, capaciteit checken, beginnen, nog eens checken, al dan niet herbeginnen, weer testen, peer-reviewen, testen, enz…
Een tekeningetje
Ik besefte bovenstaande wel, maar ik kon het moeilijker uitleggen, en al zeker niet visualiseren. Tot ik de opleiding ‘Scrum voor Product Owners’ van iLean volgde. Dat was heel inzichtelijk voor mij, ik raad het iedereen aan die een business-functie heeft en in aanraking komt met technologische ontwikkeling. Joke Vandemaele gebruikte daarin twee tekeningen:
Links een lineaire tijdslijn, rechts een ‘kromme’ of ‘agile’ tijdslijn.
Lineair
De linkse tekening toont een ‘lineair’ project. Er staan allerlei woorden en termen bij, maar ik heb het zo onthouden: dit is een tijdslijn van hoe IT-projecten vroeger gingen. Eerst een grote scope bepalen, met een groot budget en grote ontwikkelingstraject met milestones en een gedefinieerd eindpunt. Dat voelt veilig en geeft een gevoel van ‘perceived control’. Je denkt dat je het onder controle hebt, want alles is beschreven in dikke bundels, met veel analyse en grafieken.
Zo een project start ‘groen’, want er is een kick-off, er is budget, er zijn mensen, er zijn doelen gedefinieerd en let’s go. De eerste milestone haal je nog vlot, de tweede ook, maar vanaf dan wordt het wat lastiger. Blijkt dat toch een en ander niet in de scope van je project zit, dat een bepaald stukje technologie niet doet wat je dacht dat het zou doen, dat het budget verminderd wordt door een besparing, dat een nieuwe baas een nieuwe visie meeheeft, dat het probleem van de klant ondertussen is veranderd, enz… Het project krijgt de status oranje en eindigt veelal ‘rood’. Zowat ieder groot bedrijf heeft ergens een zwart gat waar zo een project is in beland, vermoed ik.
Krom
Nee, dan denk ik dat de rechter tekening interessanter is. Toon het aan een ervaren project manager of developper en die zegt ‘ja, dat is gewoon een agile tijdslijn, toch?’. Ja, dat is zo. Alleen wil ik hier getuigen waarom het voor mij een openbaring was om het zo uitgelegd te krijgen. Wat je ziet is een tijdslijn met kleine sprongen, gelijk lopend met de ‘sprints’ die technologische teams graag gebruiken. Vaak zijn dat projectperiodes van twee weken (kan meer of minder zijn hoor). Je bepaalt wat je met je team in die twee weken wil bereiken, welke problemen je wil oplossen. Soms ga je goed vooruit, soms maak je maar een kleine vordering, soms moet je alles terugrollen omdat het foutgaat, … Je weet het niet op voorhand, maar je zorgt ervoor dat iedereen z’n stinkende best doet om naar best vermogen en met de inzichten die er zijn, dat doel te bereiken.
Zo een proces is veel stress in het begin, niet in het minst voor de business-mensen. Zij hebben immers het gevoel zo goed als geen controle te hebben op het proces. Ze hangen af van de projectteams. Het project start dan ook ‘rood’: stress, waar gaan we naartoe, wanneer gaat dat klaar zijn, het kan toch niet dat er geen duidelijke deadline is, hoe moeten we dat met onze marketing nu opvangen, hoezo er is geen big bang waar we kunnen over communiceren, zonder dat ene knopje kunnen wij geen nieuwe strategie uitrollen, ... Maar geleidelijk aan wordt de scope duidelijker en blijkt wat allemaal wel al kan, en geraakt je project meer in het groen. Je einddoel evolueert mee met de inzichten, zodat het minstens haalbaar is.
Ik wou dat iemand bij de technologie-mensen mij dat met dat ene tekeningetje eens had uitgelegd, dan had ik dat zelf veel sneller kunnen echt begrijpen en uitdragen. Want dat is waar techies echt niet goed in zijn: iets communiceren en bevattelijk uitleggen aan andere delen van de bevolking. Daar is aan die kant nog veel werk. Net als aan ‘neen’ leren en vooral durven te zeggen in een project. Als iets niet kan, zeg het dan meteen of minstens zo vroeg mogelijk. Dan creëer je geen valse verwachtingen en bespaar je een hoop gezever achteraf.
Multidisciplinair
Nog 1 ding: het enige wat ik tot nu heb gevonden om de twee werelden dichter bij elkaar te brengen, is multidisciplinair werken nog meer omarmen. Ik wil geen roemloos heen-en-weer pingpongen tussen business en technologie, maar wel een project dat door een heel team is gedragen, en waar ze samen voor verantwoordelijk zijn. Een team leert elkaar kennen als collega’s, met namen en gezichten. Ik denk zelfs dat het een goed idee is die ‘agile’ manier van werken ook buiten technologie in te voeren. Waarom zou je hetzelfde niet kunnen bereiken binnen een marketingafdeling, of zelfs een nieuwsredactie? Ondertussen vooral hopen dat de multidisciplinaire aanpak iets opbrengt, maar het gaat vooruit met kleine sprintjes :-)
PS: er is ook nog iets te zeggen over de eindklant meenemen in het hele proces. Daar ga ik het later nog eens over hebben.