Betrouwbaarheid en snelheid zijn bepalend voor de concurrentiepositie van multi-projectorganisaties. Projecten betrouwbaarder en sneller opleveren begint met het beperken van het onderhanden werk. Maar waarom is dit toch zo lastig? Dat komt door de efficiencyparadox. Gelukkig zijn daar goede oplossingen voor.

In mijn artikel ‘Overwin de projectenchaos’ leg ik uit hoe multi-projectorganisaties op een verrassend eenvoudige manier stappen kunnen zetten om de projecten betrouwbaarder en sneller te kunnen uitvoeren: Bestrijd de excessieve Work in Process (WiP)!

Wanneer u de Work in Process van uw multi-projectorganisatie reduceert zijn de effecten navenant:

• De doorlooptijden worden korter;
• De doorlooptijden worden betrouwbaarder;
• De leverbetrouwbaarheid neemt toe;
• De kwaliteit wordt beter;
• De cash flow verbetert.

Waarom is het voor veel multi-projectorganisaties dan toch zo lastig om de WiP terug te dringen? In het artikel ‘overwin de projectenchaos’ wijs ik er al op: “Wanneer de WiP wordt gereduceerd zullen allerlei medewerkers momenten hebben waarop ze niets te doen hebben. De aanpak lijkt daardoor erg inefficiënt.” Lijkt. Want gezien de effecten van het reduceren van de WiP mag wel gesteld worden dat de aanpak juist heel efficiënt is

Het ‘even niets te doen hebben’ ervaren de medewerkers die het overkomt en hun directe leidinggevenden echter als een groot probleem. Om te moeten accepteren dat je niets te doen hebt gaat heel erg tegen het gevoel in; we voelen een enorme drang om onze tijd efficiënt te benutten. Dit betekent dat we de neiging hebben iets nieuws op te pakken. Met andere woorden: De uitvoerende organisatie heeft zèlf de neiging om de WiP te vergroten. En dus gebeurt dit ook. Met alle gevolgen van dien. En die zijn zeker niet efficiënt.

Wat nu ?

Stop efficiency te benadrukken!…

Jawel u leest het goed: U moet ermee stoppen efficiency als primaire maatstaf te hanteren. Daarmee wordt niet bedoeld dat u een vrijbrief afgeeft voor verspilling. Natuurlijk is efficiënt werken belangrijk. Echter, overal en altijd efficiëntie benadrukken, leidt tot gedrag dat contraproductief is voor de multi-projectorganisatie als geheel.

Wat dan wel ?

De nadruk moet ergens anders op gelegd worden. Namelijk op het doel van de multi-projectorganisatie als geheel; projecten snel en betrouwbaar opleveren. Om dit te bewerkstelligen moet binnen de uitvoerende projectorganisatie de nadruk gelegd worden op het zo snel mogelijk opleveren van de onderhanden projecten. Alleen wanneer onderhanden projecten worden opgeleverd, ontstaat er ruimte om iets nieuws op te pakken.

Wat dan met medewerkers die ‘even niets te doen hebben’?

Het is helemaal niet erg als er medewerkers zijn die ‘even niets te doen hebben’. Hieronder doe ik een suggestie voor  2 verschillende manieren waarop de capaciteit van medewerkers die éven niets te doen hebben’ uitermate nuttig ingezet kan worden. Beide manieren zijn uitermate nuttig omdat ze beide bijdragen aan het doel van de multi-projectorganisatie; projecten betrouwbaarder en sneller opleveren.

De eerste manier om de capaciteit van medewerkers die ‘even niets te doen hebben’ nuttig in te zetten is het ondersteunen van de resources die op dat moment het meest beperkt zijn in capaciteit. Als dat mogelijk is leidt het direct tot versnelling in de uitvoering van het onder handen werk. Zodoende draagt deze mogelijkheid direct bij aan het doel van de multi-projectorganisatie.

Hoewel de eerste manier een directe en zichtbare bijdrage levert aan het doel van de multi-projectorganisatie, is de tweede manier om de capaciteit van medewerkers die ‘even niets te doen hebben’ nuttig in te zetten eigenlijk veel belangrijker en nuttiger dan de eerste manier.
Medewerkers die ‘even niets te doen hebben’ kunnen werken aan verbeterinitiatieven om de projecten sneller en betrouwbaarder op te leveren. Het is van belang dat alleen gewerkt wordt aan initiatieven die daadwerkelijk bijdragen aan het vermogen van de multi-project organisatie om projecten betrouwbaarder en sneller op te leveren. De verbeterinspanning moet dus wel de juiste focus hebben. Zonder de juiste focus is er sprake van verspilling en raken de betrokken medewerkers gedemotiveerd.
Wanneer het werken aan verbeterinitiatieven met de juiste focus gebeurt, levert het een bijdrage aan het doel van de multi-projectorganisatie die blijvend is. Dat maakt deze manier zo waardevol; het vermogen van de multi-projectroganisatie om projecten betrouwbaarder en sneller op te leveren is structureel verbeterd.

Het is raadzaam het werken aan verbeterinitiatieven op een gestructureerde manier te laten plaatsvinden. Zo kunnen onder meer de juiste focus, draagvlak en het zichtbaar maken van de resultaten gewaarborgd worden. Elke multi-projectorganisatie zou een Continuous Focused Improvement proces moeten hanteren.

Het bericht De efficiencyparadox verscheen eerst op Reliable Projects.

Als je teveel ballen tegelijk in de lucht probeert te houden, gaan er onvermijdelijk een of meer op de grond vallen. Dat weten we allemaal! Toch? Waarom blijven zoveel projectmatig werkende organisaties dan alsmaar teveel projecten tegelijkertijd uitvoeren? Ze roepen daardoor enorme problemen over zich af. Hoe weet je of je teveel projecten tegelijk doet? Wat kan je eraan doen? De oplossing is verrassend eenvoudig.

Chaos

Projectmatig werkende organisaties die teveel projecten tegelijkertijd proberen uit te voeren roepen enorme problemen over zich af.
Herkent u het volgende:

• projecten hebben erg lange doorlooptijd;
• er zijn telkens weer vertragingen als gevolg van tegenvallers, kwaliteitsproblemen, besluitvormingsprocessen, veranderende eisen en te doorlopen procedures;
• vertragingen in het ene project veroorzaken vertragingen in andere projecten, waardoor een domino-effect optreedt;
• omdat er wachttijd is wordt alvast maar een nieuwe opdracht opgepakt;
• de prioriteiten zijn niet duidelijk;
• er zijn voortdurend veranderende prioriteiten;
• er is getouwtrek om de beschikbaarheid van essentiële resources;
• er is veel stress en frustratie.

Dit zijn kenmerken van een chaotische projectmatig werkende organisatie. De projecten chaos wordt veroorzaakt doordat er teveel projecten tegelijkertijd worden uitgevoerd. Met andere woorden: De Work in Process (WiP) is te hoog.

Push!

Er is sprake van een push-systeem wanneer niet de organisatie zèlf, maar het aanbod bepalend is voor de hoeveelheid werk die wordt opgestart. Dit kan gemakkelijk leiden tot een te groot aantal onder handen projecten.
Er is natuurlijk altijd druk om projecten zo snel mogelijk uit te voeren en wellicht zijn we in aanvang optimistisch over de capaciteit. De verleiding is dan groot om aan de druk toe te geven. We willen immers de opdrachtgever graag een plezier doen. Maar dan komen er onvermijdelijk tegenvallers en neemt de druk toe. Voor je het weet is de organisatie overspoeld met werk en komt er bijna niets meer echt af.

Little’s Law

Volgens de wet van Little zijn bij een gegeven capaciteit de wachttijd en de WiP aan elkaar gekoppeld; hoe groter de WiP hoe langer de wachttijd. (Zie Wikipedia voor nadere uitleg over de wet van Little.)
Als er veel projecten tegelijkertijd worden uitgevoerd (als de WiP erg hoog is), moeten opdrachtgevers erg lang wachten op de resultaten van de projecten. Niemand vind het fijn om lang te moeten wachten, en dus neemt de druk toe om met het volgende project alvast maar te beginnen. Dit is een vicieuze cirkel; nog verdere toename van de WiP geeft alleen maar meer problemen!

Bestrijd de excessieve WiP

Om het tij te keren moet het aantal onder handen projecten drastisch worden teruggebracht tot een niveau dat de organisatie voldoende armslag geeft om tegenvallers te kunnen opvangen.
Allerlei medewerkers zullen nu momenten hebben waarop ze niets te doen hebben. De aanpak lijkt daardoor erg inefficiënt. Het tegendeel is echter waar.
De negatieve spiraal wordt omgebogen in een positieve spiraal; in plaats van vertragingen en elkaar in de weg zittende projecten worden projecten in veel kortere tijd daadwerkelijk opgeleverd. Het moreel van de medewerkers en de productiviteit stijgen. Afnemers krijgen weer vertrouwen in de organisatie.

Pull

Om het aantal onder handen projecten (de WiP) op het juiste nivo te handhaven is er een regulerend mechanisme nodig. Een dergelijke mechanisme is een pull-systeem.
Verreweg het eenvoudigste is het om gewoon een limiet te stellen op het aantal projecten dat tegelijkertijd onder handen mag zijn. Dit is een effectieve zij het niet erg verfijnde methode. Kanban en Critical Chain zijn aanzienlijk meer verfijnd.
Welk pull-systeem u ook kiest, het mooie is: U kunt vandaag al beginnen het tij te keren en het kost u vrijwel niets!

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 Overwin de projecten chaos verscheen eerst op Reliable Projects.

Reliable Scrum als combinatie van ToC en Scrum is zeker geen eindstation. Het is van belang zicht te houden op wat na ToC en Scrum komt.  Welke mogelijkheden zijn er om nog verder te verbeteren?

ToC-projectmanagement en Scrum gaan prima samen. Dat heb ik uitgelegd in mijn artikel over Reliable Scrum. Daarnaast heb ik tijdens de bijeenkomst van de IPMA Critical Chain Interessegroep op 6 juni 2013 uitgelegd hoe dat in zijn werk gaat. Mijn presentatie van 6 juni alsmede een zeer lezenswaardig verslag van de bijeenkomst zijn te vinden op de webpagina van de IPMA Critical Chain Interessegroep. Uit de vele gesprekken die ik tijdens en na de bijeenkomst gevoerd heb maak ik op dat velen mijn zienswijze over de combinatie van ToC-projectmanagement en Scrum delen en waar toepasselijk in de praktijk brengen.

Reliable Scrum als combinatie van ToC en Scrum is zeker geen eindstation. Het invoeren van Scrum helpt veel organisaties af te rekenen met de waterval benadering van softwareontwikkeling en daarvoor in de plaats een teamgeoriënteerde werkvorm toe te passen. Dat is op zich een geweldige doorbraak! Toch is het van belang zicht te houden op de vervolgstappen naar nog verdere verbetering. Met andere woorden op wat na ToC en Scrum komt. Welke mogelijkheden zijn er om nog verder te verbeteren?

Zoals naar ik aanneem wel bekend is Scrum voor een groot deel geïnspireerd op Lean principes. En aangezien continue verbeteren een van de principes is van Lean leek dit mij geen verkeerde inspiratiebron om te zoeken naar mogelijkheden voor verdere verbetering. Centraal in Lean staat het streven de Work in Process terug te dringen door middel van single piece flow en een zo laag mogelijke takt time. Het kan zijn dat u als lezer van dit artikel na de voorgaande zin dreigt af te haken door de terminologie die ik hier hanteer. In dat geval raad ik u echt aan te zorgen dat u zich wat meer op Lean oriënteert. (Dat kan bijvoorbeeld door het lezen van het boek “The Toyota Way” wat in mijn ogen verplichte literatuur zou moeten zijn op alle middelbare scholen.. )

Welk beeld roept het bij u op wanneer u vanuit de Lean principes een Scrum omgeving in ogenschouw neemt? Kan er wellicht een parallel getrokken worden tussen sprintteams en productiecellen in een Lean productieomgeving? Kan de sprintduur  wellicht worden vergeleken met de Takt Time? Is een user story de beschrijving van een eindproduct dat geproduceerd dient te worden? Als we dit alles eens aannemen, dan is het niet zo moeilijk te bedenken welke richting het streven naar uit zou moeten gaan: Het ritme wordt bij Scrum bepaald door de sprintduur. Het streven zou moeten zijn deze steeds verder te verkorten of zelfs geheel te elimineren. Dat laatste wil overigens niet zeggen dat het team niet periodiek een retrospective en vooruitblik kan hebben; het moment waarop dat gebeurt is echter ontkoppeld van de productie. Het elimineren van een vaste sprintduur brengt de aandacht weer terug op meer traditionele belemmeringen die in softwareontwikkeling een single piece flow en een zo laag mogelijke work in process in de weg staan:

• Een user story op zichzelf naar de productieomgeving brengen heeft vaak geen toegevoegde waarde. Wat is dan wel de kleinste zinvolle functionele uitbreiding?
• De kwaliteitsborging vereist vaak een uitgebreide integratietest waardoor het kostbaar is kleine functionele uitbreidingen te testen
• Er zijn belemmeringen in de OTAP-omgeving (bijvoorbeeld een complexe productiegang) die single piece flow in de weg staan
• De aard van softwareontwikkeling brengt veel variabiliteit met zich mee

Verbeteringen op deze punten kunnen èchte doorbraken betekenen voor verdere verbetering van de ict-projectorganisatie. Aangezien de omstandigheden tussen specifieke ICT-organisaties aanzienlijk kunnen verschillen zal het van de organisatie afhangen wat precies de bottleneck is. Pas wanneer geen van de voornoemde punten (meer) de bottleneck is, komt verbetering van de productiesnelheid (en de kwaliteit) van het softwareontwikkelteam zèlf weer in beeld. Net als over de overige punten is ook over dit laatste al veel geschreven.

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 Wat na ToC en Scrum komt verscheen eerst op Reliable Projects.

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.

Waar het gepast kan worden ingezet elimineert Scrum grotendeels de behoefte aan de sturingsmethodiek zoals die in ToC-projectmanagement worden gehanteert. Toch wordt Scrum door ToC-consultants omarmd..

In mijn artikel over Reliable Scrum heb ik al aangegeven zeer positief te staan tegenover de scrumaanpak en heb ik beloofd in een ander artikel op de redenen daarvan terug te komen. Het is tijd deze belofte in te lossen. Ik zou geen ToC-adept zijn wanneer mijn redenen niet afkomstig zijn uit de ToC body of knowledge. Ik geef u 10 ToC-redenen om Scrum te omarmen!

1. Elimineren van lokale optima

Vanuit de behoefte om het softwareontwikkelproces beter te kunnen beheersen werd het op een kunstmatige manier in een aantal opeenvolgende stappen verdeeld. Denk in dit verband bijvoorbeeld aan globaal ontwerp, detailontwerp, coderen, testen, accepteren, implementeren. Er ontstonden daardoor verschillende specialismen die elk hun eigen lokale optimum gingen nastreven. De ontwerper streefde naar een zo goed mogelijk ontwerp, de ontwikkelaar wilde foutloos coderen en de tester een zo volledig mogelijke test uitvoeren. Het nastreven van het eigen (lokale) optimum veroorzaakte onder meer navolgende problemen:

• Noodzaak tot inhoudelijke afstemming tussen de stappen onderling
• Pieken en dalen in de vraag naar capaciteit
• Belemmert inspelen op voortschrijdend inzicht
• Veel management aandacht nodig om de problemen op te lossen

Scrum is een drastische vereenvoudiging van het software ontwikkelproces. Door het proces te reduceren tot één stap ligt de focus zoals ToC het nastreeft op het globale doel; het leveren van software die voldoet aan de definition of done.

2. De throughput wordt verhoogd

De waterval benadering van het software ontwikkelproces leidde tot lange doorlooptijden en veel onderhanden werk. Vanuit de ToC is bekend dat het terugbrengen van het onderhanden werk direct leidt tot verhoging van de throughput. Dat komt doordat er meer focus is op het afronden van het resterende onder handen werk.

Scrum verdeelt het werk in veel kleinere brokjes en reduceert de vrijgave van werk tot het aantal user stories dat binnen één sprint kan worden gerealiseerd. Het onderhanden werk wordt hierdoor geminimaliseerd en na iedere sprint wordt de toegevoegde waarde opgeleverd om in gebruik genomen te worden. De organisatie heeft hierdoor eerder de mogelijkheid om de gerealiseerde software in gebruik te nemen en zodoende waarde te genereren.

3. Altijd focus op hoogste prioriteit

Uit ToC projectmanagement is bekend dat het van belang is de projecten op volgorde van prioriteit te plannen. Ook binnen Scrum wordt dit onderkend. Al is het mechanisme anders en gaat het zoals in het vorige punt vermeld om veel kleinere brokjes werk in de vorm van user stories. De Scrum-productowner is ervoor verantwoordelijk eenduidig de prioriteiten van de user stories op de productbacklog aan te geven. Dit is de volgorde waarop de user stories in de sprintbacklog worden opgenomen en zelfs binnen de sprint worden de user stories in beginsel op volgorde van prioriteit compleet afgewerkt. Hierdoor is er altijd focus op de prioriteit zoals de productowner die heeft aangegeven.

4. De constraint lost zichzelf op

Binnen het sprintteam worden de leden geacht zoveel mogelijk elkaars taken te kunnen overnemen. Indien zich in de kennis en kunde onder de sprintteamleden in aanvang een bottleneck aanwezig is, dan zal deze bottleneck zichzelf in de loop der tijd oplossen doordat de andere teamleden leren dezelfde taak over te nemen. Hierdoor ontstaat een harmonieus team waarbinnen de capaciteit geoptimaliseerd is.

5. Elimineren van gedagseffecten die leiden tot verspilling

Door de sprintpoker en doordat ervaringscijfers worden opgebouwd ten aanzien van de velocity van het sprintteam wordt de inschatting van de hoeveelheid storypoints die in een sprint kunnen worden gerealiseerd gaandeweg steeds betrouwbaarder. Daarenboven zijn er als gevolg van een heldere definition of done en de hoge transparantie (visibility) van het proces geen verleidingen om tijd te verspillen aan de gedragseffecten zoals Goldratt die identificeert (Student Syndrome, Parkinson, Goldplating). In plaats daarvan is er afhankelijk van de geboekte voortgang tegen het einde van de sprint altijd de mogelijkheid een story terug te plaatsen op de productbacklog of een extra story op te pakken. In alle gevallen wordt tot het einde van de sprint doorgewerkt.

Voordat ik verder ga met de punten 6 t/m 10 uit de lijst met 10 ToC-redenen om Scrum te omarmen is een korte inleidende toelichting op zijn plaats. Knelpunten (bottleneck’s) die door hun tastbare aard gekenmerkt worden zijn relatief eenvoudig te herkennen. Maar wat nu wanneer het knelpunt niet tastbaar is? Voor situaties waarin het knelpunt niet een tastbare bottleneck is heeft Eli Goldratt de ToC Thinking Processes geïntroduceerd. Deze methodiek is gebaseerd op het feit dat wanneer doelen niet gehaald worden er aannames of overtuigingen zijn die contra-productief gedrag in de hand werken. In de loop der jaren ontdekte Goldratt (Gepubliceerd door Alan Barnard, Goldratt Research) dat er een 5-tal generieke oorzaken voor knelpunten in gedragssystemen te onderscheiden zijn. Hij noemde dit de Engines of Disharmony en hun tegenhangers de Engines of Harmony. Aan dit laatste zijn de navolgende punten 6 t/m 10 uit de lijst met 10 ToC-redenen om Scrum te omarmen gerelateerd..

6. Engine of Harmony 1: Precies weten hoe je moet bijdragen en weten dat deze bijdrage erkend zal worden

Scrum biedt een zeer heldere set aan regels en werkafspraken. Bovendien wordt in de daily standup meeting dagelijks aandacht besteed aan hetgeen ieder teamlid de afgelopen dag gedaan heeft en wat hij de komende dag gaat oppakken. Hierdoor is voor ieder teamlid steeds zeer duidelijk hoe hij moet bijdragen en dat deze bijdrage erkend zal worden.

7. Engine of Harmony 2: Precies weten hoe anderen moeten bijdragen en weten dat hun bijdrage erkend zal worden

In Scrum wordt zoveel mogelijk gewerkt met visuele hulpmiddelen die het werkproces en wat iedereen doet zeer transparant maken. In de daily standup meeting wordt het een en ander bovendien met elkaar besproken. Hierdoor weten de teamleden ook van elkaar precies weten hoe zij moeten bijdragen en dat hun bijdrage erkend zal worden.

8. Engine of Harmony 3: Alle regels zijn in overeenstemming met de doelstellingen van de organisatie

 De heldere set aan regels en afspraken waaronder de prioritering van de produktbacklog en het streven te voldoen aan de expliciet gemaakte afspraken die gemaakt zijn over de Definition of Done maken dat het realiseren van de doelstellingen optimaal worden nagestreefd

 9. Engine of Harmony 4: Discrepanties tussen bevoegdheid en verantwoordelijkheid worden systematisch onderkend en geëlimineerd

Het Scrumteam is als geheel verantwoordelijk voor het eigen proces. De daily standup meeting waarborgt dat ieder zijn taken naar behoren kan uitvoeren. Om discrepanties tussen bevoegdheid en verantwoordelijkheid met de omgeving te elimineren wordt de scrummaster ingeschakeld. Daarnaast is er de mogelijkheid van tussentijds overleg met de productowner.

10. Engine of Harmony 5: Er is een op knelpunten gericht proces van continue proces- en cultuurverbetering

In de vorm van de Sprint-retrospective voorziet Scrum erin om na iedere sprint tijd te nemen om de gang van zaken in de afgelopen sprint te evalueren en mogelijkheden na te gaan om het proces verder te verbeteren.

Hoe positief dit artikel ook getuigt over Scrum, het zal de lezer die mij enigzins kent niet verbazen dat een artikel met 10 redenen om bedachtzaam te zijn over Scrum reeds in voorbereiding is. Ik ben er nu eenmaal groot voorstander van dat met gezond verstand wordt nagedacht over de werkwijze die het beste past bij de uit te voeren taken. Ik hoop door het schrijven van deze artikelen daaraan een bijdrage te kunnen leveren.

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 ToC-redenen om Scrum te omarmen 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.

De gecombineerde voordelen van ToC èn van Scrum krijg je als je de principes uit ToC-projectmanagement  en Scrum op de juiste manier met elkaar combineert. Hoe je dat het beste doet is afhankelijk van de situatie..

Agile benaderingen en met name Scrum hebben in de afgelopen paar jaar in sneltreinvaart vaste voet aan de grond gekregen bij de aanpak van ICT-projecten. Wat mij wel zorgen baart is dat de toepassing ervan nogal eens lijkt door te slaan. Mede onder invloed van zogeheten agile-implementers en agile-coaches, die Agile schijnbaar als de enige geschikte benadering uitdragen, worden oude benaderingen zonder meer aan de kant geschoven en worden alléén nog maar Agile technieken gebruikt. Wee degene die de euvele moed heeft zich daarover kritisch uit te laten. Hij/zij wordt maar al te gemakkelijk weggezet als “ouderwets” en/of als iemand die Agile niet begrijpt. Welnu, als dat kennelijk ervoor nodig is om op basis van gezond verstand je punt te kunnen maken zal ik het ruiterlijk toegeven: Ik ben ouderwets!! Ik ben er groot voorstander van om eerst met gezond verstand naar de klus te kijken die geklaard moet worden alvorens we de gereedschappen kiezen om het uit te voeren.

Hoezeer ik de toepassing van Scrum ook van harte toejuich, (Echt waar!! Om redenen die ik in een ander artikel op deze blog graag nog eens toe zal lichten..) de realiteit in ICT projecten is vaak aanzienlijk complexer dan de door Agile benaderingen geboden sturingsmogelijkheden aankunnen. In mijn ogen verzuimd Scrum dan ook invulling te geven aan een aantal behoeften rond deze (complexe) projecten. Dat zijn bijvoorbeeld:

• Borging van en heldere (project-) communicatie over realiseren business goals
• Input voor resourcemanagement en ketenbesturing in multi-project omgeving

Verschillende organisaties die op het gebied van ToC-projectmanagement in de ICT actief zijn pogen in deze behoeften te voorzien door de ToC-principes te combineren met Scrum. Zij noemen dit Reliable Scrum. Dat zijn bijvoorbeeld het Duitse Speed4projects en in Nederland Garansys en Reliable Projects. (Reliable Projects is overigens niet de bedenker van de term Reliable Scrum. Hooguit onderstreept het dat de bedrijfsnaam van Reliable Projects goed gekozen is.)

Zinvolle toepassing van Reliable Scrum is afhankelijk van de context waarbinnen Scrum gebruikt wordt. Ik denk dat je daarbij onderscheid kunt maken in 4 categorieën die ik hieronder uitwerk.

1. Software onderhoud

Bij onderhoud van bestaande in gebruik zijnde software kan in principe na elke sprint een nieuwe release in gebruik genomen worden. Software onderhoud leent zich daarom uitstekend voor toepassing van Scrum as is.

2. Multiple sprint softwareontwikkeling

Als er meerdere sprints van een sprintteam nodig zijn voordat de aangepaste/nieuwe software in gebruik genomen kan worden, dan is er sprake van multiple sprint softwareontwikkeling.

Scrum ondersteunt de sturing bij multiple sprint softwareontwikkeling doordat je met behulp van een velocity trendline en een work added/removed trendline uitspraken kunt doen over de periode waarin de aangepaste/nieuwe software in gebruik genomen kan worden. Voorwaarde voor het kunnen gebruiken van deze trendlines is dat de stories op de product backlog de beoogde aanpassingen min of meer volledig afdekken en dat de storypoints voor alle stories geschat zijn. Deze randvoorwaarde staat enigszins op gespannen voet met de Agile gedachte dat je vooral niet te ver (meer dan 1 of 2 sprints) vooruit moet willen kijken omdat er naar verwachting toch nog veel voortschrijdend inzicht zal zijn waardoor zowel de productbacklog als de schattingen drastisch aangepast zullen moeten worden.

Bij toepassing van Reliable Scrum worden buffering principes gebruikt om aan de hand van voortgang en bufferverbruik de projecteinddatum te bewaken. Een eenvoudige spreadsheet volstaat al om dat mogelijk te maken.

3. Multiple sprintteam softwareontwikkeling

Als er meerdere sprints van meerdere sprintteams nodig zijn voordat de aangepaste/nieuwe software in gebruik genomen kan worden dan is er sprake van Multiple sprintteam softwareontwikkeling.

In Scrum projecten wordt ten behoeve van de sturing naast de trendlines zoals besproken bij Multiple sprint softwareontwikkeling nu doorgaans ook gebruik gemaakt van een coördinatieoverleg in de vorm van een zogeheten Scrum of Scrums. Een goed praktijkgebruik is om de uiteenlopende sprintteams zo mogelijk parallel te schakelen en tegelijkertijd aan dezelfde stories te laten werken. Op deze wijze wordt zoveel mogelijk vermeden dat teams last hebben van onderlinge afhankelijkheden.

Toegegeven: Met goede coördinatie en het parallel schakelen van de sprintteams kan je een eind komen. Mits de onderlinge afhankelijkheden overzichtelijk blijven en de doorlooptijden de sprintduur niet overschrijden.. Dreigt dat wel het geval te zijn, dan is het advies vanuit Reliable Scrum om de taakafhankelijkheden in een Gantt-planning uit te werken. Dit wil niet zeggen dat de werkaansturing nu gaat plaatsvinden vanuit de Gantt. Dit is slechts een hulpmiddel om de grote complexiteit aan afhankelijkheden in kaart te brengen en mede zodoende te bepalen welke activiteiten in welke sprints moeten worden ondergebracht.

4. Complex project met gedeelte softwareontwikkeling

Vinden er in het project naast softwareontwikkeling een veelheid aan activiteiten plaats die zich er niet voor lenen om in sprints uitgevoerd te worden, dan is er sprake van een complex project met een gedeelte softwareontwikkeling.

Scrum biedt voor dergelijke situaties geen specifieke voorzieningen. Reliable Scrum hanteert voor complexe projecten met een gedeelte softwareontwikkeling een hybride aansturing van de activiteiten. Sprints (eventueel van meerdere sprintteams) en alle overige projectactiviteiten worden naast elkaar ondergebracht in een gebufferde Gantt-planning. De aansturing van de softwareontwikkeling vindt plaats volgens de Scrum principes waarbij met behulp van de trendlines wordt gerapporteerd over de voorgang en over de remaining work. Zodoende heeft de voortgang in de softwareontwikkeling zijn weerslag in het bufferverbuik van het totale project. De aansturing van de overige activiteiten vindt plaats rechtsreeks vanuit de gebufferde Gantt-planning. Zodoende kan op elk moment betrouwbare informatie worden verstrekt over de haalbaarheid van de projecteinddatum.

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 Reliable Scrum 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.