Hoezeer ik het ook omarm, hier zijn 10 redenen om bedachtzaam te zijn met Scrum.
Aangezien ik er nu eenmaal groot voorstander van ben dat met gezond verstand wordt nagedacht over de  werkwijze die het beste past bij de uit te voeren taken, hoop ik door het schrijven van dit artikel met 10 redenen om bedachtzaam te zijn met Scrum een bijdrage te kunnen leveren aan het inzicht op dit gebied.

In een eerder artikel gaf ik 10 ToC-redenen om Scrum te omarmen. Deze keer heb ik ervoor gekozen niet vast te houden aan ToC-specifieke redenen. De lezer die ermee bekend is zal in de onderstaande 10 redenen om bedachtzaam te zijn met Scrum slechts hier en daar elementen uit ToC en ToC-projectmanagement herkennen.

1. Interactie met uiteenlopende stakeholders 

Een van de principes in het Agile Manifesto is dat de ontwikkelaars dagelijks nauw samenwerken met de mensen die de business kennen. Hoewel in Scrum de product owner verantwoordelijk is voor het prioriteren van de user stories op de product backlog, eventueel gevraagd kan worden een user story toe te lichten en een accepterende rol speelt in de sprint demo, is zijn rol voor het overige vrijwel niet uitgewerkt. Het kan om allerlei redenen uitermate belangrijk zijn om de steun van uiteenlopende stakeholders voor het project te borgen. Het verdient dan ook aanbeveling op dit punt aanvullende maatregelen te nemen.

2. Behoefte aan sturing op functionaliteit

De behoefte om agile te zijn neemt toe naarmate er meer onzekerheden zijn. Dat kan zijn vanuit het businessperspectief of vanuit de softwareontwikkeling bijvoorbeeld op het vlak van technologie en/of functionaliteit. Juist bij toenemende onzekerheid neemt ook het belang toe om de business te betrekken in de besluiten die gaandeweg genomen moeten worden om de scope afgestemd te houden op de business goals. Er zijn voorbeelden van functionele sprintteams en workshops die beogen de product backlog te vullen en te prioriteren. Een uitstekende aanpak die eigenlijk nooit zou mogen ontbreken.

3. Behoefte aan sturing op business goals

Er kan sprake zijn van een wettelijke maatregel als gevolg waarvan er een deadline geldt voor een project. Los daarvan is het voor elke organisatie noodzakelijk te kunnen sturen op het behalen van business goals. Dat geldt ook wanneer softwareontwikkeling een belangrijk onderdeel is van de activiteiten die daartoe worden ondernomen. Dan is het zaak om, hoe onzeker soms ook, te trachten een zo compleet mogelijk beeld te krijgen van de totale doorlooptijd die nodig is om de benodigde software te realiseren. Scrum biedt in dit verband voor het realiseren van de software een grafiek waarin met behulp van de velocity trendline en een work added-removed trendline een indicatie gegeven kan worden voor het afhandelen van de productbacklog. Daarvoor moet wel eerst een min of meer volledig beeld wordt verkregen van de productbacklog die moet worden afgehandeld om in het kader van een een gegeven business goal de software te realiseren. Veelal zullen er daarnaast nog andere activiteiten moeten worden uitgevoerd. Voor de complete set aan activiteiten die nodig zijn om de business goal te behalen biedt Scrum geen voorzieningen. Hoe daarmee om te gaan wordt in het artikel over Reliable Scrum uitgelegd.

4. Weining onzekerheid.

Hierboven is al aangegeven dat de behoefte om Agile te zijn toeneemt naarmate er meer onzekerheden zijn op bijvoorbeeld het vlak van technologie en/of functionaliteit. Maar wat nu te doen als er nauwelijks onzekerheid is en heel goed kan worden aangegeven wat er gemaakt moet worden en hoe dat moet. Er zijn talloze redenen aan te voeren om ook in een dergelijke situatie Scrum toe te passen. (Zie ook: 10 ToC-redenen om Scrum te omarmen) Het verdient echter wel aanbeveling eerst na te gaan of de verbeteringen die u wilt bereiken wellicht beter of gemakkelijker met andere werkvormen bereikt kunnen worden. Scrum is één van vele agile benaderingen en ook uit bijvoorbeeld het Lean gedachtegoed zijn talloze instrumenten toe te passen om de processen te verbeteren.

5. Deployment op de productieomgeving is niet na elke sprint mogelijk

Een van de principes uit het Agile Manifesto stelt als enige maatstaf van vooruitgang de hoeveelheid werkende software ingezet in een productieomgeving. Scrum meet de voortgang van sprints met behulp van Sprint Backlog grafiek waarop de voortgang zichtbaar is aan de hand van de taken die door de ontwikkelaars zijn afgewerkt. Dat zijn niet door de klant geaccepteerde features zoals het algemeen aanvaarde agile principe bedoeld. Ok, tot zover is dit natuurlijk academisch; het is al heel mooi als de business aan het einde van de sprint over de nieuwe features kan beschikken! Dat is in de praktijk echter vaak niet mogelijk. Bijvoorbeeld omdat er na een sprint een incomplete set features wordt opgeleverd of de inspanning voor de ketenintegratietest en de deployment op de productieomgeving erg groot zijn. Kennelijk zijn dit nu dus de bottleneck’s in het softwareontwikkelproces. In plaats van meerdere sprints uit te voeren voordat de oplevering kan plaatsvinden wordt aangeraden eerst na te gaan of deze bottlenecks kunnen worden weggenomen. Anders gebruiken we weliswaar een agile achtige werkvorm voor het realiseren van de software, maar het proces van softwareontwikkeling als geheel is pas agile wanneer het de business helpt dat te zijn.

6. Managen schaarse resources

Ere wie ere toekomt; ik kan dit punt niet beter uitleggen dan Albert Ponsteen doet op zijn blog over multiprojectmanagement: “Scrum is not a multi-project solution. It is a multiple-single project solution, using dedicated teams. By doing this, scrum kills the number 1 disturbance in a multi project environment: the non-availability of resources. This is why it so successful and beloved by engineers and project managers. Projects can be delivered in no time. But speed is not for free! The price for speed is efficiency. Dedicated project teams are extremely expensive! To get more out of your company, scarce resources must be shared! The scrum-of-scrum meeting should be supported with an excellent view of the resource status of the different skills. It should be obvious to the ambassadors, scrum masters and the resources themselves where to allocate their scarce capacity on the spot.”

7. Focus nodig

Als we tijdens het werken veelvuldig van taak moeten wisselen moet ons brein de context van de onder handen taken onthouden. Mensen zijn daar niet goed in; het menselijke brein is slechts zeer beperkt in staat om te multitasken. Als de taken eenvoudig van aard zijn is dat niet zo schadelijk, maar naarmate de complexiteit toeneemt hebben we meer en meer behoefte om ons te kunnen concentreren. Binnen een Scrum team helpen de teamleden elkaar en vindt veelvuldig interactie plaats. Het is met andere woorden een multitasking omgeving. Voor relatief eenvoudige softwareontwikkeling gaat dat prima, maar naarmate de complexiteit toeneemt zullen er afspraken binnen het team moeten worden gemaakt om erin te voorzien dat de teamleden zich kunnen concentreren en het is zelfs de vraag of bijvoorbeeld de bouw van complexe reken- en verwerkingsprogramma’s zich er überhaupt voor leent om binnen een scrum context te worden uitgevoerd.

8. Kwaliteitsborging / Testen

Scrum is voortgekomen vanuit het perspectief van de softwareontwikkelaar en besteed waarschijnlijk daardoor weinig aandacht aan specifieke activiteiten die nodig zijn om de kwaliteit van de software te waarborgen. Door de aard van het testwerk is dit (met uitzondering van de ketenintegratietest) prima te verenigen met activiteiten die in sprints worden uitgevoerd. Aandacht voor de kwaliteitsborging zal de succeskans voor de invoering van Scrum aanzienlijk vergroten. Een prima handreiking daartoe biedt bijvoorbeeld het boekje TMap NEXT in Scrum. Het geeft een mooie mapping van de TMap testactiviteiten in het Scrum framework. Waar het boekje helaas niet op ingaat is hoe het een en ander zich concreet vertaald in de testen die dan feitelijk uitgevoerd worden. Een professioneel tester weet daar in de praktijk naar verwachting wel raad mee en er zal hierover ongetwijfeld ook literatuur beschikbaar zijn en/of verschijnen.

9. Leverancier in het project

Hoe te handelen wanneer vanuit de gebruikersorganisatie het bouwen van de programmatuur is uitbesteed aan een softwareleverancier? Deze gebruikersorganisaties zijn waarschijnlijk gewend op basis van een goed doordacht pakket van functionele specificaties een workpackage aan de softwareleverancier uit te besteden en bij de oplevering uitgebreide acceptatietesten uit te voeren. Dit is een belangrijke barrière voor het invoeren van Scrum. Is de relatie met de leverancier zodanig om te vormen dat de organisatie werk kan uitgeven aan de hand van een veranderlijke productbacklog en dat de kwaliteitsborging zo geïntegreerd plaatsvindt als in het vorige punt bedoeld?

10. Cultuur

In het artikel met 10 ToC-redenen om Scrum te omarmen zijn er 5 waarin aan de hand van de Engines of Harmony de positieve impact van Scrum op de groepsmentaliteit wordt aangegeven. Daarentegen wordt in de literatuur her en der erop gewezen dat  de omvang van de cultuurverandering die nodig is om agile te implementeren een risico vormt voor het slagen ervan. Zo worden bijvoorbeeld als kritieke succesfactor voor het slagen van agile implementaties aangewezen: Het feit dat de cultuur van de organisatie open moet staan voor discussie en onderhandeling, dat mensen vertrouwd moeten worden, dat de organisatie de beslissingen moet accepteren die de business vertegenwoordiger neemt.. Het is dus wel degelijk zaak er goed over na te denken of uw organisatie wel toe is aan Scrum.

Hieronder kunt u desgewenst reageren op dit artikel. Mocht u naar aanleiding van een of meer artikelen in deze blog vragen hebben en/of rechtstreeks met mij contact willen opnemen, schroomt u dan niet een e-mail bericht te sturen naar info@reliableprojects.nl

Het bericht 10 redenen om bedachtzaam te zijn met Scrum verscheen eerst op Reliable Projects.

Het apenbrein en multitasking vormen een geweldige combinatie. Chimpansees blijken namelijk een ongelofelijk goed korte termijn geheugen te hebben. Het stelt hen in staat stelt complexe geheugentaken uit te voeren zèlfs wanneer ze multitasken en/of afgeleid worden..

In het artikel over ons brein en multitasking is beschreven hoe wij feitelijk taskswitchen en hoe beperkt ons menselijke brein in staat is hiermee om te gaan. Beperkt is het juiste woord, zeker wanneer je ons brein en multitasking gaat vergelijken met het apenbrein en multitasking. In het navolgende filmpje legt de mens het volledig af tegen de chimpansee.

..

Chimpansees mogen dan een geweldig korte termijn geheugen hebben, de mens heeft het vermogen te focussen en (mede) daardoor veel complexere taken aan te kunnen. De volgende keer dat je aan het multitasken bent bedenk dan: Je bent geen aap. FOCUS !

Hieronder kunt u desgewenst reageren op dit artikel. Mocht u naar aanleiding van een of meer artikelen in deze blog vragen hebben en/of rechtstreeks met mij contact willen opnemen, schroomt u dan niet een e-mail bericht te sturen naar info@reliableprojects.nl

Het bericht Het apenbrein en multitasking verscheen eerst op Reliable Projects.

Geconcentreerd werken betekend sneller, nauwkeuriger en met meer diepgang taken kunnen afronden dan wie zich laat afleiden. Maar de focus heeft een prijs..

In het artikel artikel over “Ons brein en multitasking” is uitgelegd dat er een forse nadelige effecten verbonden zijn aan multitasking. Het artikel is feitelijk een pleidooi voor het vermijden van multitasking en in plaats daarvan ervoor te zorgen dat je het tegenovergestelde doet; je concentreren op één ding. Focus! Dat biedt tegen de geringste inspanning het optimale resultaat voor de taak waar je je op richt. Maar er is een prijs.

Welk nadelig effect verbonden is  aan focus, kan (wederom) het beste worden uitgelegd aan de hand van een filmpje (minder dan 4 minuten) dat op Youtube te vinden is. Het is een stukje uit een aflevering van de serie “Test your Brain” die is uitgezonden op National Geographic Channel. Kijk het, verbaas jezelf en lach!…

Als u het filmpje bekeken heeft zal het u waarschijnlijk inmiddels duidelijk zijn wat bedoeld wordt met de prijs van focus. Omdat we ons best doen om te concentreren zal ons brein andere dingen wegfilteren. Enerzijds is dat een goede zaak omdat het ons helpt te vermijden dat we afgeleid worden van de uitvoering van onze taak. Maar anderzijds kunnen er daardoor zomaar verbazingwekkende dingen pal onder onze neus gebeuren zonder dat we het in de gaten hebben. Dat kunnen onbelangrijke pinguins zijn, maar evengoed dingen die wel degelijk belangrijk zijn. Dan kan het zomaar een hoge prijs blijken te zijn die betaald wordt voor onze focus.

Al met al is het goed om te focussen, mits je wel zeker weet dat je je concentreert op de juiste dingen. Dat geldt niet alleen voor ons als mensen, maar evenzeer voor bedrijven en organisaties.

Hieronder kunt u desgewenst reageren op dit artikel. Mocht u naar aanleiding van een of meer artikelen in deze blog vragen hebben en/of rechtstreeks met mij contact willen opnemen, schroomt u dan niet een e-mail bericht te sturen naar info@reliableprojects.nl

Het bericht De prijs van focus verscheen eerst op Reliable Projects.

Het lijkt enorm voordelig en efficiënt wanneer je door multitasking meerdere taken tegelijkertijd kan uitvoeren. Maar is dat ook echt altijd zo? Naast het feit dat het soms voordelig kan zijn heeft multitasking flink wat nádelige effecten. Dat komt door de manier waarop ons brein omgaat met multitasking.

Dit artikel gaat over de manier waarop het menselijke brein omgaat met multitasking en wat daarvan de effecten zijn. Het tegenovergestelde van multitasking is focus. Er valt ook het nodige te vertellen over hoe het brein omgaat met focussen en wat op zijn beurt dáár weer de effecten van zijn, maar daar kom ik later in een andere blog op terug. Zowel focussing als multitasking kunnen vóór- èn nádelige effecten hebben. Als we daar goed begrip van hebben en er op de juiste manier mee omgaan kan dat ons helpen onze prestaties enorm te verbeteren!

Onze steeds dynamischer wordende maatschappij lijkt een alsmaar groter beroep te doen op ons vermogen om te multitasken. Het lijkt enorm voordelig en efficiënt wanneer je door te multitasking meerdere taken tegelijkertijd kan uitvoeren. Soms is dat ook zo. Bijvoorbeeld wanneer bepaalde taken niet permanent onze volledige aandacht nodig hebben. Maar voor multitasking wordt een forse prijs betaald.

Over multitasking is heel veel te vinden op internet. Ik vind de uitleg die Professor Daniel Willingham geeft in een filmpje (< 4 minuten) dat ik op Youtube tegenkwam erg verhelderend..

Een samenvatting van de punten die ik zelf opgepikt heb uit het filmpje:

• Multitasking lost ons brein feitelijk op door taskswitching.
• Om taskswitching te kunnen ons brein de details en de context van de verschillende taken zien vast te houden.
• Dat kan het brein slechts van een héél beperkt aantal éénvoudige taken. (Zoiets als achtergrondmuziek is voor het brein al een taak… )
• Doorgaans gaat er bij taskswitching een deel van de details en de context van de taak verloren.
• Dit gaat ten koste van de kwaliteit en de diepgang waarmee taken kunnen worden uitgevoerd. Om dát te voorkomen is het advies dan ook bij complexe en/of belangrijke taken vooral niet aan multitasking te doen. Zorg dat je niet afgeleid wordt.
• Wie veel aan multitasking doet word er niet beter in. Je kan multitasking dus niet oefenen.
• Je wordt minder goed in multitasking naarmate je ouder wordt (maar dat geldt volgens mij voor meerdere hersenfuncties..)

Hieronder kunt u desgewenst reageren op dit artikel. Mocht u naar aanleiding van een of meer artikelen in deze blog vragen hebben en/of rechtstreeks met mij contact willen opnemen, schroomt u dan niet een e-mail bericht te sturen naar info@reliableprojects.nl

Het bericht Ons brein en multitasking verscheen eerst op Reliable Projects.