Analisten die in een agile omgeving werken, kortweg agile analist, kunnen een belangrijke rol in het scrum team vervullen. Ze helpen de product owner vaak met het helder maken van de user stories en requirements.
Vaak zie je dat agile analisten in het begin maanden en soms jarenlang zoekende zijn naar een goede werkwijze.
Misschien voel jij ook aan dat het nog niet helemaal lekker loopt, maar weet je de vinger niet op de zere plek te leggen. Of misschien heb je al van alles geprobeerd om je werkwijze en de requirements te verbeteren, maar boek je daar nog onvoldoende resultaten mee.
Omdat ik je die zoektocht wil besparen of op z’n minst vereenvoudigen, heb ik het e-book ‘Vliegende start als agile analist’ geschreven. En het mooie is dat je hem gratis kunt downloaden. Mijn doel is namelijk om het voor alle analisten mogelijk te maken hun vak goed uit te oefenen. Dan zorgen we er samen voor dat gebruikers de systemen krijgen waar ze blij van worden.
Kijk hier voor het e-book ‘Vliegende start als agile analist’.
Als voorproefje volgen hier alvast 2 do’s en 3 don’ts uit het e-book.
1. De rol van een agile analist
In agile is de rol van analist niet expliciet belegd. In agile en vooral in Scrum worden bewust zo min mogelijk rolnamen gebruikt. Dat is om de samenwerking binnen het multidisciplinaire team te bevorderen. De unieke kennis en vaardigheden van elk teamlid is belangrijk, niet de functie of rolnaam die hij heeft gekregen.
DO
Je toegevoegde waarde als analist laten zien
Gelukkig biedt de agile werkwijze ons volop gelegenheid om toegevoegde waarde te leveren. De typische vaardigheden van een analist, zoals luisteren, doorvragen, overzicht houden en prioriteren, zijn bij een agile werkwijze erg belangrijk. Alle agile teamleden zouden deze vaardigheden eigenlijk moeten bezitten.
2. Product backlog met user stories
Bijna elk agile team maakt gebruik van een product backlog met daarin user stories. Uitgebreide kennis en vaardigheden om hier goed mee om te gaan, zijn voor een agile analist onontbeerlijk. Het is bijvoorbeeld goed om je te realiseren dat een user story een beperkte scope heeft, omdat je in sprints werkt. Let als gevolg daarvan op de volgende don’t.
DON’T
De user stories als systeemdocumentatie gebruiken
Een user story omvat namelijk alleen een gewenste wijziging van de, op dat moment, reeds gerealiseerde software. Een user story weerspiegelt daarom niet de eisen die aan de uiteindelijk op te leveren software gesteld worden! En dat is precies wat je wel wilt vastleggen in systeemdocumentatie.
3. Requirements achterhalen
Binnen agile is er veel aandacht voor het achterhalen van requirements. Agile heeft een heldere en onderscheidende visie op de beste manier om dat te doen. Het belangrijkste daarbij is dat je tijdens de rit de requirements steeds verder uitwerkt. Je past ze voortdurend aan de laatste inzichten aan.
DON’T
Er van uit gaan dat gebruikers precies weten wat hun requirements zijn
Daar mag je ook niet van uit gaan als de gebruikers(vertegenwoordigers) zelf denken te weten wat voor systeem ze nodig hebben. In agile heb je volop mogelijkheden om de gebruikers te laten ontdekken hoe hun ideale systeem eruit ziet. Dat gebeurt geleidelijk gaandeweg het ontwikkeltraject.
Voor de product owner en jou als agile analist is het ook een stuk relaxter dat de requirements niet in één keer helemaal goed hoeven te zijn.
4. Requirements detailleren
Vroeg of laat moeten we concreet en tot in detail aangeven wat de requirements zijn. Agile heeft uitgesproken ideeën over hoe en wanneer je dat het beste doet. Overbodig werk wordt zoveel mogelijk vermeden. Een voorbeeld is het onderhouden van te vroeg vastgelegde requirements.
DON’T
Voorkomen dat er een grote ‘voorraad’ aan requirements ontstaat
Hoe meer requirements uitgewerkt zijn, hoe langer ze op de plank liggen te wachten totdat ze geïmplementeerd worden. De kans dat ze aangepast moeten worden doordat inzichten wijzigen, neemt dan toe. Bovendien hebben requirements nauwelijks waarde zolang ze liggen te wachten, totdat het agile team ze in een sprint oppakt.
5. Het werkproces van een agile analist
Requirements maken integraal onderdeel uit van elk agile proces. Agile is echter geen methode met voorgeschreven activiteiten en producten. Om het werk in goede banen te leiden, geeft scrum wel een raamwerk. Maar elk team moet dat zelf concretiseren. De 3 pijlers van agile kunnen je daarbij helpen.
DO
De 3 pijlers van agile omarmen
Agile is bij uitstek geschikt om complexe projecten en slecht voorspelbare processen in goede banen te leiden. Daarvoor is inspelen op de actuele situatie en continu blijven meebewegen, essentieel. De 3 pijlers van agile maken dat mogelijk en zijn: transparantie, feedback en bijsturen.
Meer do’s en don’ts
Dit was een beknopte uitleg van een vijftal do’s en don’ts uit mijn gratis e-book ‘Vliegende start als agile analist’.
Dan ben ik nu benieuwd naar jouw ervaringen met agile. Wil je de volgende 2 vragen beantwoorden in het reactieveld hieronder? Dat helpt me om het e-book nog waardevoller te maken.
- Hoe volwassen met betrekking tot agile is de omgeving waarin je werkt?
- Wat is op dit moment het belangrijkste punt waar je met agile requirements tegenaan loopt?
Dank je wel voor je antwoorden!
Nicole de Swart
Vraag 1
Zijn net gestart
Vraag 2
Overview, splitsen, detail
Vraag 1: redelijk volwassen
Vraag 2: requirements en harde deadlines voor inmplementatie.
Vraag 1: nog in groot kindschoenen. Business komt vaak nog met eigen oplossingen ipv probleem voor te leggen of business doel.
Vraag 2 zie vraag 1
Onze organisatie maakt momenteel de eerste stappen. Het is vallen en opstaan.
Korte termijn denken en vastgeroest in oude patronen botsen met agile aanpak.
1.In transformatie
2. Business verwacht een volledig uitgewerkte reeks requirments
1. Ik ben met pensioen maar geef nog les in analyse en blijf het domein volgen, het niveau is dus net starten
2. het grootste struikelblok is dat een goede user story maken niet eenvoudig is en bij redelijk grote applicaties het overzicht verloren gaat
Vraag 1:
Het is bij de overheid, dus voorlopig nog niet volwassen
Vraag 2:
Het gaat allemaal erg traag en men verandert amper doordat niemand stuurt
Vraag 1: Redelijk volwassen (5j agile/scrum/kanban en 1,5j SAFe portfolio 4/4.5)
Vraag 2: -extern: Business afspraken met harde deadlines (bv 1-1) en vaste set aan requirements (=fixed scope) blijft lastig om binnen x aantal sprints, tot bewuste deadline, te realiseren.
– intern: wisselende teamsamenstelling (disciplines) vergt continu inspanning in kennisoverdracht, -deling en -vastlegging met impact op velocity
– inbetween: op sollution (keten) niveau is het lastig om software/business oplossing over meerdere team te bewaken, met name lange termijn visie op softwareproduct.
1 redelijk volwassen
2 juiste detailniveau
Hoe volwassen m.b.t. agile is de omgeving waarin je werkt?
Dit varieert van echte beginners tot volwassen teams.
Wat is nu het belangrijkste punt waar je m.b.t. agile requirements tegenaan loopt?
Belangrijkste is nu het onbekende bij de newbee Productowener en de rest van het team. Het zijn voornamelijk starters.
– Ruim een jaar bezig
– Bussiness denkt nog steeds waterval en wil lange termijn planningen
Vraag 1: in 2017 hebben we een goede start gemaakt. Met name op de soft skills kunnen we nog veel verbeteren.
Vraag 2: klein maken requirements; goede beschrijving user stories; voorkomen van mini waterval in sprint
1. Zeer divers. Startende teams en teams die al redelijk volwassen zijn.
2. Opknippen van userstories kan nog steeds meer/beter. Dit zal het beschrijven van de requirements ten goede komen. En sowieso het agile proces.
Vraag 1: Bijna alle projecten zijn hier agile. Alleen de vorm/organisatie verschilt nogal.
Vraag 2: IT kan zaken snel opleveren, alleen de business doet er vrij lang over om beslissingen te nemen.
Vraag 1: net gestart met Agile.
Vraag 2: het spilitsen van User stories.
Vraag 1: Organisatie is nog te veel waterval-minded; geen agile-projecten dus.
Vraag 2: Gebruikers zijn niet in staat hun wensen te formuleren.
Vraag 1: 5+ jaar, redelijk volwassen
Vraag 2: de hele (business) keten betrekken in het opstellen en uitwerken van requirements
Aloys
Vraag 1: Beperkt ervaring met agile werken. Momenteel wordt Agile werken breed geïmplementeerd.
Vraag 2: Op het juiste moment aanleveren van het juiste niveau aan requirements. Negeren van details, indien het moment in de tijd daar nog niet om vraagt.
Vraag 1. IT redelijk volwassen, rest van het bedrijf nauwelijks
Vraag 2. Grote backlog, te snel te veel detail
Vraag 1: Delen in de organisatie zijn behoorlijk volwassen.
Vraag 2: Balans vinden tussen ideeën en eisen van stakeholders versus eigen/team kennis en ideeën.
Vraag 1: 2 jaar met vallen en opstaan wordt langzaam beter
Vraag 2: Niveau van de userstory’s en requirements is minimaal. Business denkt in oude structuren i.p.v. vernieuwend
Vraag 1: Grote delen van organisatie en klanten zijn agile minded, alleen MT niet.
Vraag 2: MT wil traditionele jaarplanning en voortgangsrapportages zien
Vraag 1:
Inmiddels ruim 8 jaar bezig met Agile. Eerst DSDM later met SCRUM. Daar hebben we onze weg aardig in gevonden. Binnen IT is de Agile mindset nu wel geland, maar bij de business moet er nog een transformatie plaatsvinden. Het vooraf niet precies weten wat je krijgt, blijft lastig.
Vraag 2:
Backlog refinement blijft een lastig ding. Ontwikkelaars vinden het soms niet nodig, maar als het achterwege wordt gelaten zie je direct de gevolgen in de sprint (open eindjes, voor meerdere uitleg vatbaar etc.). Het is belangrijk om refinement een standaard onderdeel van je werkwijze te maken en te houden. Met name dat laste verwaterd wel eens.
1.Hoe volwassen m.b.t. agile is de omgeving waarin je werkt?
Vrij volwassen. Het grootste deel van de projecten gebeurt al op een agile manier. We hebben 4 grote releasemomenten op en jaar en na een feasibility fase van 4 à 6 weken werken in sprints naar deze opleveringen toe.
2.Wat is nu het belangrijkste punt waar je m.b.t. agile requirements tegenaan loopt?
De juist skill’s & mindset in het project krijgen. Als financiële instelling zitten we met heel wat legacy en vaste procedures maar ook het profiel van onze personeelsleden leunt eerder bij (historische gezien) een waterval aanpak. Dit botst wel eens met de meer dynamische Agile aanpak en het leven met veranderingen en nieuwe inzichten in de agile projecten.
Vraag 1: Wisselend. In transformatie
Vraag 2: Zelfstandigheid teams, zorgt voor onvoldoende afstemming tussen de teams en over de teams heen
Vraag1 : nog in de kinderschoenen, ook nog maar zeer gedeeltelijk (ca. 10 % van de totale organisatie)
Vraag2 : (maar dat is erg persoonlijk) helaas is het oude “vak” van informatieanalist is het ongerede geraakt (lees: bij het grof vuil gezet) – daardoor wordt er niet meer gedefinieerd waar we het over hebben, vindt er geen begripsvorming meer plaats, en blijven we gezellig langs elkaar heen (mis)communiceren – maar het houdt ons van de straat….
1.Hoe volwassen m.b.t. agile is de omgeving waarin je werkt?
Vrij volwassen; Scrum wordt toegepast. Alle rituelen worden gevolgd.
2.Wat is nu het belangrijkste punt waar je m.b.t. agile requirements tegenaan loopt?
Feedback verzamelen van klanten (manier/sctructuur om dat goed te regelen) en de Backlog Refinement (opdelen in types, klanten hierbij aanhaken)
Hoe volwassen m.b.t. agile is de omgeving waarin je werkt?
IT heeft al langer tijd agile teams, waarbij agile proces wel goed werkt. Echter teams zijn nog te veel rond systemen i.p.v. business processen /functionaliteit ingedeeld.
Wat is nu het belangrijkste punt waar je m.b.t. agile requirements tegenaan loopt?
IT teveel voor de klant denkt? Echte business analyse is minder.
Vraag 1:
Beginner
Vraag 2:
Loslaten van oude gewoonten.
Vraag 1: De eerste stappen naar agile werken zijn gezet (3 a 4 jaar, maar enkel het opzetten van scrumteams maakt de organisatie niet agile), maar er is nog steeds een projectleider en geen product owner (deze rol is ‘by proxy’ bij de informatie analist neergelegd).
Vraag 2: Bij de requirements is het vooral een uitdaging wanneer ik welke requirements ga uitwerken, ik wil de uitwerking klaar hebben ruim voordat de ontwikkelaar ermee aan de slag gaan (maar door deadlines en paniekvoetbal er zijn veel wisselingen in de gewenste functionaliteit). Daarnaar is het vooral de mate van detaillering van de user stories, waar ik tegenaan loop. Ik heb soms het gevoel dat ik het op technisch ontwerp niveau moet opleveren, voordat de ontwikkelaar het ook maar willen pokeren.
1. Zijn al enkele jaren succesvol met agile projecten. Met name stand-up heeft enorm bijgedragen aan het samen ontwikkelen van software programma’s.
2. Onze klant denkt nog vaak in budgetten en overall requirements. De klant heeft een budget en daarvoor moet functionaliteit worden opgeleverd. De klant is terughoudend als wij beginnen met 1 requirement en deze dan volledig gaan maken. Daarna kijken we hoeveel budget er nog over is en welke requirement dan gedaan gaat worden. De klant denkt dat we dan niet alle requirements kunnen gaan maken voor het voorgestelde budget.
Vraag 1: we proberen agile werken zoveel mogelijk toe te passen in een hybride omgeving. Dat zorgt nog wel eens voor knelpunten en tegenstrijdigheden.
Vraag 2: niet te vroeg al te veel details beschrijven.
1. Nog niet heel volwassen. IT afdeling is een heel stuk verder dan de Business, die nog steeds deadlines aanhoudt.
2. Detaillering van de requirements. Hoever ga je wanneer.
Idem als Eric. Ik zit momenteel bij de overheid.
vraag 1: totaal niet agile.
vraag 2: gebruikers/klanten zijn slecht te bereiken
1.Hoe volwassen m.b.t. agile is de omgeving waarin je werkt?
Beginnend
2. Wat is nu het belangrijkste punt waar je m.b.t. agile requirements tegenaan loopt?
Behoefte aan lijst met requirements om in evaluatie met klant/eindgebruiker op terug te kunnen vallen.
1: IT is wel agile georganiseerd, business nog niet. Wordt wel aan gewerkt.
2: Hoe ver moet je gaan in de analyse; hoeveel onzekerheid wil je in de sprint meenemen.
Hoi Nicole,
De volgende tip kent een dubbele ontkenning: Don’t: Ga er niet van uit dat gebruikers precies weten wat hun requirements zijn.
Dit is hetzelfde als: Do: ga er van uit dat gebruikers precies weten wat hun requirements zijn.\
Ik vermoed dat dit niet hetgeen is wat je bedoelde?
Verder als antwoord op de vragen: dit doe ik op basis van mijn huidige opdracht (bij een gemeente).
Vraag 1: in het geheel niet
Vraag 2: grote uitdaging is dat er überhaupt weinig tot geen aandacht is voor business en informatie analyse en dat er op onderbuikgevoel applicaties worden aangeschaft. Soms worden er wel procesflows gemaakt maar de relatie met requirements en gegevens ontbreekt dan alsnog.
Hoe volwassen m.b.t. agile is de omgeving waarin je werkt?
Dat varieert van team tot team, in het algemeen 3 op een schaal van 5!
Wat is nu het belangrijkste punt waar je m.b.t. agile requirements tegenaan loopt?
Waarde (ValuePoints) inschatten en consequent opdelen n hapklare user stories (met StoryPoints)
1 in de kinderschoenen.
2. Formulering opdracht is vaag maar verwacht wel direct een volledig uitgewerkte reeks requirments
Ik ben docent en zie dat studenten met name moeite hebben met het opsplitsen van User Stories.
vrg1. Agile en waterval wordt naast elkaar gebruikt.
vrg2. Mate van detaillering van de User story.
Vraag 1: Als ik kijk naar de laatste 3 organisaties waar ik momenteel opdrachten voor uitvoer kan ik zeggen dat 2 organisaties aan het begin staan van Agile en DevOps en momenteel een bewustwordingsproces doorlopen.
Tenminste één van de drie heeft in de afgelopen 5 jaar enorme stappen gezet, speciaal op het vlak van mobiele app ontwikkeling, zowel met Agile (scrum) als met DevOps.
Vraag 2: Dat requirements niet meer gedetailleerd genoeg uitgewerkt worden als tijdens de sprint al begonnen is met de bouw. Het documenteren begint achter te lopen op de bouw. Dit betekent bij onderhoud e/o bij regressietesten dat er een inhaalslag gemaakt moet worden en wordt door PO gezien als “waste” of extra werk wat eerder plaats had moeten vinden.
Antwoord 1: Goed onderweg, maar nog wel een en ander te verbeteren. Bijvoorbeeld in het meenemen van de stakeholders in de “nieuwe” werkwijze.
Antwoord 2: Goede balans vinden tussen werken met losstaande user stories (zonder naar het grotere geheel te kijken) en werken vanuit gedetailleerd ontwerp van de hele Epic/Idea.
Maturity Agile gebied: matig: deels een aantal rituelen in gebruik zoals daily standup, maar ook nog steeds teams gegroepeerd naar rollen (“het testteam”)
Belangrijkste punt: de spagaat tussen “agile werken in de IT teams” en ” klassiek aansturen vanuit de business”, omdat de business niet is meegenomen in een agile manier van werken.
1. Nauwelijks
2. Er is een grote behoefte aan beheersbaarheid en planmatigheid en daarom wordt er vooral gestuurd op projectmatig werken waarbij zoveel mogelijk van tevoren wordt vastgelegd.
vraag 1: beginnend
vraag 2: mensen willen zich niet vastleggen
1) Binnen SW development is Agile geaccepteerd. Binnen hardware development wordt waterval development gebruikt.
2) Voor onze multidisciplinaire systemen wordt de basis van de waterval development gebruikt omdat de Hardware mensen niet in Agile getraind zijn.
1) Beginnen nu met meer teams om te zetten naar agile.
2) De juiste manier van specificeren, m.n. als de scope meerdere teams kan betreffen.
Hoe volwassen m.b.t. agile is de omgeving waarin je werkt?
– In deze nieuwe baan gaat men binnenkort van start met agile werken: niet volwassen dus.
Wat is nu het belangrijkste punt waar je m.b.t. agile requirements tegenaan loopt?
– De onzekerheid over hoe dit op te pakken.
1.Niet zo volwassen. Onderdelen worden toegepast waar het past.
2. De business betrekken en over hun requirements laten nadenken.
Vraag 1: Nog in de kinderschoenen en nog niet overall op dezelfde manier
Vraag 2: Waar moet ik beginnen en hoe lever ik bruikbare requirements op voor een Agile Sprint.
Vraag 1: er groeien naar een redelijke volwassenheid toe.
Vraag 2: we zien dat een PO en/of Business Consultant te snel naar een oplossing gaan, zonder dat het geheel overzien wordt, bijvoorbeeld de impact in andere straten.
1. medium: we zijn één jaar bezig met vallen en opstaan
2. overzicht behouden over diverse projecten heen en zo de juiste prioriteiten binnen de afdeling en alle resources.
Hoe volwassen m.b.t. agile is de omgeving waarin je werkt?
De business is volop aan het scrummen, elke afdeling voor zich!
Binnen IT, slechts een afdeling.
Nog niet volwassen.
Wat is nu het belangrijkste punt waar je m.b.t. agile requirements tegenaan loopt?
De business komt met allerlei ’technische’ requirements waarvan ze eigenlijk niet weten wat het precies is.
Kost veel tijd om te achterhalen wat ze nu bedoelen.
Hoe volwassen m.b.t. agile is de omgeving waarin je werkt?
-> Volwassen
Wat is nu het belangrijkste punt waar je m.b.t. agile requirements tegenaan loopt?
-> Moment waarop requirements voldoende gedetailleerd zijn (just in time)
1. Goed op gang, maar we zijn er nog niet
2. Management wil agile, maar doet waterval
1. Het team is best volwassen, de organisatie heeft net scrum geímplementeerd.
2. Meer input krijgen van stakeholders om requirements goed boven water te krijgen.
1. Dit per project/programma verschillend. Zijn beginnende teams maar ook teams die al 2 jaar meedraaien.
2. Het mee krijgen van de managementlaag. En hoe diep werk je een “Userstory” uit en op welke moment?
1. Hangt een beetje van het project af en wie de uitvoering doet. Grote projecten worden zeker niet agile aangemaakt. Oorzaak is dat uitvoering door externe partijen en veelal tegen fixed price worden gedaan. ‘Alle’ requirements moeten daarom vooraf duidelijk zijn…
Het eerste dat vaak wordt vastgesteld is de live-datum.
2. De opsplitsing en mate van detail.
Vraag 1: Organisatie is nu 1 jaar bezig met Agile
Vraag 2: Hoeveel detail moet er in een analyse en wanneer moet er hoeveel detail in
1. In de opstartfase
2. Mate van detaillering
Hoe volwassen m.b.t. agile is de omgeving waarin je werkt?
In opbouwfase.
Wat is nu het belangrijkste punt waar je m.b.t. agile requirements tegenaan loopt?
Onduidelijkheid over de gewenste mate van detail van uitwerken requirements.
1. De organisatie is zich aan het experimenteren wat Agile en DevOps kan betekenen voor de organisatie en wat het oplevert. Nadrukkelijk wordt ook gekeken naar de verbetering van onderlinge communicatie tussen traditionele rollen en snelheid van oplevering nieuwe functionaliteit.
2. Organisatie heeft nauwelijks aandacht voor het opstellen van requirements. Er is nauwelijks dialoog met de stakeholders.
vrij onvolwassen
ICT denk nog steeds in hokjes en eigen releases; ipv multidisciplinair team
1. Begint meer volwassen te worden
2. Het blijft moeilijk om te bepalen wat er wordt vastgelegd voor de systeemdocumentatie. Het verschilt van uitgebreide functionele ontwerpen tot alleen de User stories met de acceptatiecriteria
Vraag 1: is per onderdeel verschillend. Als er intern ontwikkeld wordt, is de volwassenheid al op een behoorlijk niveau.
Vraag 2: he tidee dat requirements binnen agile minder belangrijk zijn dan binnen waterval.
Vraag 1: Overheid, dus veel wettelijke wijzigingen met duidelijke scope maar zonder veel flexibiliteit. Binnen team goede samenwerking/vloeiend verloop in taken
Vraag 2: Mate van detaillering en de juiste mensen aan tafel krijgen. Wie vraag ik er op welk punt bij.
Vraag 1: 2017 gestart en op weg naar volgend niveau
Vraag 2: JIT requirements en acc criteria
1. Er worden volop cursussen gegeven rond agile aan programmeurs, analisten, en we implementeren IREB en ISTQB.
2. We werken met vele personen samen, dus de uitdaging is om iedereen op dezelfde golflengte te krijgen en duidelijke werkwijzen af te spreken.
1. Net begonnen, passen het deels toe (er wordt nog waterval gedacht door velen)
2. Inschatten of features wel passen binnen een sprint
1. We zijn in transformatie sinds ongeveer een jaar. Daarvoor veel losse Agile trajecten gedaan. Scaling en portfoliomanagement begint een aandachtspunt te worden.
2. Waardedenken en daarbinnen het toekennen van waarde aan individuele user stories is vaak een uitdaging.
1. Redelijk volwassen. Ons team loopt goed.
2. De taakverdeling tussen Product Owner en analist. Wie doet het uitzoekwerk voor de stories, wie beschrijft ze.
En, hoe gedetailleerd beschrijf je de stories.
1. Onvolwassen, we gaan er nu mee starten
2. Er wordt nog onvoldoende naar de businesswaarde gekeken
Een waardevol artikel dat essentiële richtlijnen biedt voor Agile-analisten. Het benadrukt de belangrijke rol van analisten in een Agile-team en geeft praktisch advies om effectief bij te dragen.
1) MKB maakindustrie selfmade hardnekkig om uit ‘comfort zone’ te komen
2) Prioriteren & juiste mens (vaardigheden) koppelen en daarmee op tijd te leveren.