Van multitasking naar high performance – effectiever werken in projecten 3

Posted on 6 mei 2013 by Anko Tijman
Het effectief plannen van projecten is een fikse uitdaging: Hoe plan je projecten zo dat de beschikbare capaciteit niet wordt overbelast en de aandacht wordt gericht daar waar het nodig is? In deze blog, het  vervolg op deel  2 van onze reeks over effectiever werken in projecten , kijken we naar de relatie tussen de wet van Murphy, Buffer management, het cumulatief flow diagram en hoe je dat in Agile projecten toepast. Dit is een gast blog door Pepijn van de Vorst.

Kees en Johan weten inmiddels dat multitasking, zéker in een multi project omgeving, tot problemen leidt. Dat het nodig is om de hoeveelheid onderhanden werk beperkt te houden. Zodat er een continue flow van  werk door de organisatie heen gaat. Door bínnen een team met “limited WIP” technieken te werken en team overstijgend niet teveel projecten tegelijkertijd op te pakken, houd je de voorraden klein en dus resources beschikbaar om werk direct op te pakken. Daarbij kwamen ze uit op Buffer Management.

Murphy

“Iederéén heeft het wel eens over ‘de wet van Murphy’, maar wat bedoelen we daar nu eigenlijk mee?’”. Johan heeft te maken een grote tegenslag in de testomgeving, waardoor het project bijna zeker minimaal één tot twee weken gaat uitlopen. Tot overmaat van ramp is ook één van zijn beste ontwikkelaars ziek.

“Volgens mij zegt de wet van Murhpy dat alles wat mis kán gaan ook mis zál gaan.” Kees heeft zich vanuit zijn opleiding verdiept in project management en heeft ook het nodige met statistiek gedaan.” Wat projecten onderscheidt van regulier werk, is dat er altijd een relatief grote mate van onvoorspelbaarheid is. Omdát je met een project iets nieuws gaat doen. Dat onvoorspelbare, wat inhoudt dat dingen mis kunnen gaan, is waar de wet van Murphy over gaat. En hé: statistiek gaat óók over onvoorspelbaarheid!”

Bewust of onbewust passen we zelf ook vaak de wet van Murphy toe. Als we op een bepaalde tijd een afspraak hebben, houden we er rekening mee dat het druk kan zijn onderweg, of zelfs dat we in de file terecht kunnen komen. Een ritje dat normaalgesproken ongeveer 20 minuten duurt, kan bij drukte soms wel 30 minuten of zelfs 40 minuten duren.

Scheve verdeling & lange staart

Zo doen we dat ook als we in moeten schatten hoe lang het duurt om een bepaalde taak af te hebben. We houden er – bewust of onbewust – rekening mee dat het soms tegenzit. Dus bouwen we per taak vaak een veiligheidsmarge in: een buffer, uitgedrukt in tijd. Hoe grotere de onzekerheid, hoe groter de buffer. In onderstaande diagram wordt dat visueel weergegeven: we geven een tijd op waarbinnen we met 90% zekerheid de taak kunnen afronden.


Deze ingebouwde veiligheidsmarge per taak heeft ongewenste effecten:

  • We starten later met de taak dan zou kunnen (uitstellen: Student Syndrome)

  • We werken door aan de taak om het mooier/beter  te maken (goldplating: wet van Parkinson)

  • We stoppen met werken aan een taak en gaan aan een andere taak werken (multi-tasking)


Het nieuwe plannen: de Project Buffer

We willen bij het vaststellen van de planning van een project rekening houden met onvoorspelbare gebeurtenissen. Om dit te bereiken en tegelijkertijd de nadelen van het inbouwen van veiligheidsmarges op taakniveau te voorkomen, wordt bij Buffer Management de veiligheidsmarge (buffer) op projectniveau ingebouwd, de zogenoemde project buffer:

(bron afbeelding: http://chronologist.com/blog/2012-09-25/critical-chain-project-management-in-TOC)


Hiermee is de kans groter dat taken op tijd worden afgerond (deadline halen) en dat nieuwe taken op tijd worden gestart. Omdat de nadelige effecten van buffers op taakniveau worden uitgebannen, is er voor het project als geheel minder buffer nodig om de impact van onvoorspelbare gebeurtenissen op te vangen. De algemene vuistregel is dat de helft van de som van de buffers op taakniveau wordt gebruikt als project buffer.  (NB er zijn ook “feeding buffers” en “resource buffers”, daarover later in deze blogserie meer)

Buffer Management

“Ik heb geleerd dat de aandacht altijd naar de projectleider gaat die het hardst schreeuwt dat zíjn project het diepst in de problemen zit en het hardst hulp nodig heeft om de deadline te halen”. Kees knikt: “Tja…. het valt ook niet mee om in een complexe organisatie met tientallen projecten te bepalen hoe de vlag er voor staat. Dan moét het management wel afgaan op de signalen die ze krijgen van de projectleiders.”

Het gevolg van dit herkenbare gedrag is dat de resources niet gaan naar het project met de hoogste prioriteit, maar naar het project van de best gebekte projectleider. Dat moet dus anders!

Buffer management maakt gebruik van de verhouding tussen de voortgang van de project activiteiten en de mate waarin de buffer is “opgesnoept”. Of – nog eenvoudiger – uitsluitend van de mate waarin de buffer is “opgesnoept”. Daarbij wordt de buffer-tijd in drieën gedeeld:

  • Groen: als het opsnoepen van de buffer tot dit stuk beperkt blijft, is er niets aan de hand

  • Geel: als de buffer tot hier is opgesnoept, is extra aandacht nodig

  • Rood: als de buffer tot hier is opgesnoept, alle hens aan dek om de problemen op te lossen!



Door alle projecten te laten rapporteren over de voortgang en mate waarin de buffer is opgesnoept, kan heel eenvoudig worden vastgesteld welke projecten prima op schema lopen, welke projecten in de problemen dreigen te komen en welke projecten direct hulp nodig hebben. Een geweldig management instrument, waarvan in onderstaande afbeelding een voorbeeld te zien is:


Buffer management en Scrum

Hoe zit het nou met deze methode van plannen en managen ten opzichte van Kanban en Scrum? Scrum maakt gebruik van time-boxing en een variabele scope. De buffer zit daar niet in de tijd, maar in de hoeveelheid functionaliteit die wordt gebouwd. Vaak wordt daarbij een MoSCoW prioritering gebruikt. Voor projecten waar de scope daadwerkelijk flexibel is, is dat een goed bruikbaar mechanisme. Waarbij de hoeveelheid gerealiseerde functionaliteit ten opzichte van de backlog (eventueel weergegeven in een cumulatief flow diagram) kan worden gebruikt om vast te stellen of een project op schema ligt, of in de gevarenzone terecht dreigt te komen. Maar….. eigenlijk doe je dan afbreuk aan het uitgangspunt van Scrum dat in elke sprint de functionaliteit met de hoogst mogelijke business value wordt gerealiseerd door het team. En dat het team door de effectieve manier van werken en de sustainable pace ook over meerdere sprints heen de hoogst mogelijke business value biedt. Als Scrum zo ver wordt doorgevoerd als het ooit bedacht is, zit de buffer niét in tijd of in op te leveren functionaliteit door het project, maar in de geleverde toegevoegde waarde aan de business. En wordt hier dus niét expliciet op gestuurd.

Water-Scrum-Fall

Veel organisaties hebben Scrum nog niet zo ver doorgevoerd en werken met een mengvorm tussen de oude watervalmethode en Scrum (ook wel Water-Scrum-fall genoemd).  Met de informatie uit deze en de twee voorgaande blogs kan eens kritisch worden stilgestaan bij de vraag waar de buffer uit bestaat (tijd, scope of business value) en hoe deze gemanaged wordt.

Buffer management en Kanban

Ook bij Kanban kan gebruik gemaakt worden van een cumulatief flow diagram. Uitgangspunt bij Kanban is het meten van de gemiddelde doorlooptijden van het ontwikkelen van functionaliteit.  Omdat je bij Kanban niet werkt met sprints, is er geen buffer in de vorm van scope. Buffer Management op basis van tijd kan prima gecombineerd worden met Kanban. De som van de afwijkingen van de toegekende doorlooptijden kan dan worden beschouwd als de mate waarin de buffer is opgesnoept.

 “Nou nou, een hoop om over na te denken”, verzucht Johan. “Project management is al behoorlijk pittig zonder al die nieuwe ontwikkelingen!”. Kees lacht. “Aan nieuwe ideeën moeten we altijd wennen. Omdat de manier die we gewend zijn zo vertrouwd voelt.” “Toch is er nog iets dat ik mis”, zegt Johan peinzend. “Hoe ga je nou om met resource die niet fulltime voor een project werken en schommelingen in capaciteit?”

Meer over hoe je organiseert dat resources die in beperkte mate wat voor een project doen, géén bottleneck worden voor dat project en over hoe je omgaat met schommelingen in benodigde capaciteit van bepaalde resources in de volgende blog, met o.a. de resource buffer en aggregatie.

Eerdere blogs over dit onderwerp:

http://www.agileopmaat.nl/van-multitasking-naar-high-performance-effectiever-werken-in-projecten-1/

http://www.agileopmaat.nl/van-multitasking-naar-high-performance-effectiever-werken-in-projecten-deel-2/
    Posted in Agile methodieken, Agile Projectmanagement, Bedrijfsvoering, Projectvoering, Theory of Constraints | 6 Comments

    Van multitasking naar high performance – effectiever werken in projecten, deel 2

    Posted on 16 april 2013 by Anko Tijman
    Hoe creëer je een (project)omgeving waarin projectleiders niet over elkaar heen struikelen in de jacht op beschikbare resources en waar teamleden zich steeds kunnen focussen op het afronden van één taak? Daarmee eindigde onze vorige blog.   Kees en Johan zijn er nog niet uit: hoe maken ze hun organisaties effectiever in het uitvoeren van kritische projecten? Hoe organiseer je onderhanden werk effectief en kunnen we daarin leren uit andere domeinen? (gastblog door Pepijn van de Vorst)


    In deze blog aandacht voor:

    • De wet van Little (beter bekend als Little’s Law)

    • Gelimiteerde werkvoorraad (limited work in progress, ook wel limited WIP genoemd)

    • Doseren van projecten (ook bekend als “pipelining” of “staggering projects”)


    De wet van Little

    “Ik was zaterdag bij Ikea en daar stónd me toch een rij!”. Kees en Johan hebben lunchpauze en staan in de rij voor de kassa bij de kantine. “Wát een tijdverspilling, zo’n rij”, vult Kees aan.” Hoe langer de rij, hoe meer tijd het kost voordat we kunnen lunchen”. “Ja, héhé, wat een dooddoener zeg, dat is toch logisch!” reageert Johan wat geïrriteerd. Zijn project loopt weer eens uit en eigenlijk hééft hij niet eens tijd om te lunchen. “Nou…. het lijkt misschien een open deur, maar de consequenties van de wet van Little worden vaak over het hoofd gezien”. Kees en Johan kijken achterom. Tina, stagiaire op de afdeling van Kees, gaat verder: “als je de hoeveelheid mensen in een rij vertaalt naar de hoeveelheid werk voor een bepaald team, betekent het dat hoe meer werk je een team te doen geeft, hoe langer het duurt voor het werk af is.”

    “Hmmm……” Johan en Kees knikken instemmend. “Dat betekent dat als je werk sneller afgerond wilt hebben, je een team minder werk moet geven. In een methode als Kanban wordt dat het limited WIP principe genoemd. Wat betekent dat je de hoeveelheid onderhanden werk beperkt houdt.”

    “Kanban?” De nieuwsgierigheid van Kees is gewekt. “Is dat net zoiets als Scrum?” . Tina lacht: “Nou…. ze komen beide voort uit agile software ontwikkeling. Er zijn overeenkomsten en verschillen”. Johan onderbreekt Tina. “Laten we het daar een andere keer over hebben. Ik wil eerst wat meer weten over het beperkt houden van onderhanden werk. Dat lijkt me een goede manier om multitasking tegen te gaan.”

    Gelimiteerd Onderhanden Werk

    Voor het beperkt houden van de hoeveelheid onderhanden werk binnen één team, kun je prima uit de voeten met Scrum of Kanban. De meest praktische manier is een maximum vaststellen voor het aantal werkbriefjes per swimming lane van het kanban bord / scrum bord waarmee je werkt. Gaat het om de organisatie als geheel, dan is het essentieel om niet teveel projecten die gebruik maken van dezelfde resources, tegelijkertijd op te pakken. Hoe meer projecten tegelijkertijd door de organisatie worden uitgevoerd, hoe langer de doorlooptijd voor elk project. Er is nog een schadelijker effect. Ga maar na wat er gebeurt als teveel auto’s tegelijkertijd gebruik willen maken van de snelweg: er ontstaat file. In een fabriekshal uit zich dat in de vorm van veel materiaal dat staat opgesteld voor een bepaalde machine. In de virtuele wereld van software ontwikkeling, is het niet goed zichtbaar. Een verzameling requirements die nog in ontwerpen omgezet moeten worden. Of een verzameling testgevallen die nog uitgevoerd moeten worden. Niet voor niets worden Kanban en Scrum boards gebruikt om het onderhanden werk te visualiseren en opstoppingen en knelpunten vroegtijdig te signaleren en te verhelpen. Om op organisatieniveau “files” te voorkomen, is er maar één oplossing: minder projecten tegelijkertijd! Maar hoe doe je dat?

    Doseren van projecten

    Organisaties voeren projecten niet uit om hun werknemers bezig te houden. Projecten hebben doelen en resultaten en de organisatie heeft die resultaten nodig.  Hoe bepaal je welke projecten “in de wacht” gezet kunnen worden en welke projecten je als eerste gaat afronden?  Géén gemakkelijke opgave, omdat alle opdrachtgevers nu eenmaal hún project onmisbaar en belangrijk vinden!

    Essentieel is – hoezeer dat ook tegen de intuïtie ingaat – voor ogen te houden dat uitvoeren van meerdere projecten tegelijkertijd er niet toe leidt dat in kortere tijd meer werk gedaan wordt. Integendeel!

    Om vast te stellen welke projecten het belangrijkst zijn, kunnen de business cases van de projecten worden gebruikt. In organisaties waar deze niet worden opgesteld  en waar geen programma of portfolio management voorhanden is, is een bijeenkomst nodig om de prioriteiten van de projecten vast te stellen.

    Denk daarbij aan criteria als:

    • Hoeveelheid nog te verrichten werk (hoe sneller af te ronden, des te aantrekkelijker om op te pakken)

    • Kosten / investering / ROI (meest gunstige verhouding opbrengsten / kosten is aantrekkelijk)

    • Wettelijke verplichtingen (bijv. de eis vanaf een bepaalde datum compliant te zijn)

    • Time to market (introductie van een nieuw product eerder dan de concurrentie)


    De resultaten van organisaties die projecten doseren en multitasking weten te beperken, zijn spectaculair:

    • Leverbetrouwbaarheid (halen van de afgesproken einddatum) die toeneemt van 60-70% naar 95-99%

    • Doorlooptijden van projecten die 30-50% korter worden (met dezelfde scope!)

    • Met dezelfde mensen meer projecten per jaar uitvoeren


    Is dat niet too good to be true? De resultaten zijn er wel degelijk. Bij o.a. Boeing, de Amerikaanse marine, de Israelische luchtmacht, het Nederlandese IT bedrijf Garansys en vele andere organisaties. In Japan heeft het ministerie dat verantwoordelijk is voor de infrastructuur Critical Chain Project Management (de methode die met deze uitgangspunten werkt) als standaard gesteld voor alle projecten die worden uitgevoerd.

    Buffer Management

    Als de prioriteit eenmaal is vastgesteld, hoe voorkom je dan dat je teveel projecten tegelijkertijd uitvoert? Hoe voorkom je dat resources die voor meerdere projecten werk moeten doen gaan multitasken? Buffer Management is hierbij een belangrijk hulpmiddel.  Omdat in software ontwikkeling door de wisselende capaciteit die nodig is vanuit ontwerpen, bouwen en testen geen gebruik gemaakt kan worden van het Drum-Buffer-Rope concept, kan Buffer Management helpen de capaciteit optimaal te benutten.

    Over hoe je Buffer Management kunt toepassen in een traditionele project omgeving of in combinatie met Scrum of Kanban de volgende keer meer….
      Posted in Agile methodieken, Agile Projectmanagement, Bedrijfsvoering, Projectvoering, Theory of Constraints | 2 Comments

      Van multitasking naar high performance – effectiever werken in projecten (1)

      Posted on 29 maart 2013 by Anko Tijman
      Veel organisaties worstelen met projecten. Er komt simpelweg te weinig uit. Projecten lopen uit. Mensen worden op meerdere projecten gezet  - die vervolgens nog meer uitlopen. Projectleiders moeten vechten om resources en werken met halve projectteams. Er is een paradigma verandering voor nodig om dit probleem op te lossen: we moeten stoppen met het multitasken van onze mensen. Het gedachtegoed van de Theory of Constraints1 helpt ons daarbij. Lees hier de ervaringen van Kees en Jan… (gastblog door Pepijn van de Vorst)

      “Dat kunnen ze niet maken, wéér een project erbij!”. Kees briest verontwaardigd. “Maar joh, zo gaat het altijd bij projecten, waar maak je je druk om?” Johan is een ervaren projectmanager en kent het klappen van de zweep. “Nou, als ze me een burnout in willen jagen, moeten ze vooral zo doorgaan! Ik wou dat ik mezelf kon klonen. Ze kunnen toch niet van me verwachten dat ik drie projecten mijn volle aandacht kan geven. Dit is vrágen om problemen”

      Voor veel werknemers is dit herkenbaar. Software ontwikkeling vindt vrijwel altijd plaats in projecten. En er zijn maar weinig organisaties die slechts één project tegelijkertijd uitvoeren. Veel projecten tegelijkertijd is eerder regel dan uitzondering. En omdat ICT’ers dure arbeidskrachten zijn, zou het zonde zijn als ze even niets te doen hebben. Toch? Dus zetten we veel mensen in op meerdere projecten zodat iedere resource optimaal benut wordt. Logisch toch?!

      “Kijk, ik zal eens even laten zien dat het geen enkele zin heeft om meerdere projecten tegelijkertijd met dezelfde mensen te doen”, zegt Kees vastberaden. Hij pakt een servet en een pen en maakt een tekening.



      “Als je afwisselend aan taak A en taak B werkt, is taak A veel later klaar, en taak B niét eerder. En als je rekening houdt met het effect dat je steeds als je van taak wisselt er weer even ‘in’ moet komen, wordt het nog veel erger.”



      “Hmmmm…..” Johan heeft een diepe frons in zijn voorhoofd. Zijn goedlachse gezicht is opeens één en al concentratie. “Ik begrijp dat dat heen en weer gejojo irritant is voor de mensen die het uitvoerende werk doen. Voor mij als projectmanager is het ook lastig. Ik ga continu met andere projecten  de strijd om de resources aan, omdat ik anders mijn deadline niet haal. Dat is frustrerend.”

      “En wat dacht je van de kans op fouten die toeneemt doordat je met meerdere dingen tegelijkertijd bezig bent?” vult Kees aan. “Wat ook nog eens een heleboel energie kost en stress oplevert. Ik ben er van overtuigd dat het werken aan meerdere projecten tegelijkertijd alle projecten schade toebrengt”. “Maar ja”, zegt Johan uit het veld geslagen, “het gaat niet voor niets op de manier zoals het nu gaat. Er zullen de nodige pogingen zijn gedaan om het anders aan te pakken, maar dat is  allemaal op niets uitgelopen”.

      Multitasking is gebruikelijk bij software ontwikkeling. Maar het leidt tot ongewenste effecten:

      • Projecten worden later afgerond dan wanneer ze één voor één worden uitgevoerd omdat task switching veel tijd kost en niet bijdraagt aan eerder afronden van de  projecten2

      • Het vergt extra energie en levert stress op

      • Projectleiders moeten continu vechten om resources, wat leidt tot onderlinge spanningen

      • Met meerdere dingen tegelijkertijd bezig zijn, betekent een groter risico op fouten

      • Als je even niet verder kunt met taak A, is de verleiding groot verder te gaan met taak B. waardoor het probleem waardoor je niet verder kunt met taak A blijft liggen.

      • Als werk voor project A moeizaam verloopt, is de verleiding groot te gaan werken aan project B. We hebben als mens nu eenmaal de neiging dingen af te willen maken.


      De enige oplossing om de ongewenste effecten van multitasken tegen te gaan, is niét te multitasken.

      • Pak één taak op en rond deze af voordat je aan een volgende taak begint
        Als je niet verder kunt, zorg je dat datgene dat je blokkeert, wordt opgelost

      • Maak met een bepaalde groep resources één project af, voordat je een volgende project start


      Maar dat is gemakkelijker gezegd dan gedaan!

       “Ik weet het niet”, zegt Johan. “We werken al jaren zo, waarom zouden we dat nu ineens gaan veranderen? Waarom zou dat nu ineens werken? Het klinkt te mooi om waar te zijn. Als het zo eenvoudig was, zou iedereen al lang op die manier werken.”

       “Ik ken ze wel, hoor”. Bij Kees is opeens een lichtje gaan branden. “Het zijn vaak de niet zo populaire medewerkers, die door anderen en vooral door projectmanagers als lastig worden gezien. Ze staan erop de taak waaraan ze werken af te maken en gaan daarná pas met een volgende taak aan de slag. En warempel, die lui zijn vaak akelig productief.”

       “Nou je het zegt!” Johan bedenkt zich dat hij twee projectmanagers kent, die alleen een klus aannemen als ze van tevoren de garantie krijgen dat de mensen dedicated op hún project worden ingezet. Ze bewegen hemel en aarde om dat voor elkaar te krijgen en gaan door het vuur voor hun mensen. En ze boeken vaak spectaculaire resultaten.”

      Maar hoe creëer je een (project)omgeving waarin “bad multitasking” wordt uitgebannen? Daarover meer in de volgende blog…

      1  voor meer uitleg over TOC en CCPM, zie o.a.  http://nl.wikipedia.org/wiki/Theory_of_constraints en http://www.ikdoeprojecten.nl/group/criticalchainprojectmanagement

      2 zie voor meer informatie over de effecten van multitasken en task switching, zie o.a. http://psyweb.psy.ox.ac.uk/acc/papers/YeungMonsell_2003b.pdf en http://www.apa.org/research/action/multitask.aspx

      Pepijn van de Vorst is testconsultant bij Ordina en enthousiast aanhanger van het concept Theory of Constraints, waarmee hij veel voorkomende testproblemen analyseert en oplost.

       
        Posted in Agile methodieken, Agile Projectmanagement, Bedrijfsvoering, Theory of Constraints | 6 Comments

        Laat DevOps uw organisatie rebooten

        Posted on 18 februari 2013 by Anko Tijman
        Op haar cd “Live in Amsterdam” (2000) legt Candy Dulfer op enig moment de band compleet stil en zegt: “We can do better than that!”. Vervolgens bouwt ze het arrangement opnieuw op, beginnend bij de drummer, gitarist, toetsenist etcetera. Stiekem droom ik –als ervaren muzikant– er van dit ook eens met onze IT-ondersteuning te doen: de boel stil leggen en van scratch af aan opnieuw beginnen. Een reboot van de manier waarop we werken. DevOps biedt ons die kans om op basis van nieuwe fundamenten IT-ondersteuning te herdefiniëren. Maar waarom zouden we dat moeten doen?

        IT is een lappendeken

        Vanuit het principe van flow en throughput hebben we er in de IT wel een beetje een rommeltje van gemaakt. Er is een loket voor nieuwe projecten, een voor regievoerders voor grip en sturing, en drie loketten voor respectievelijk functioneel, applicatief en technisch beheer. Ieder loket heeft zijn eigen processen en procedures die meestal niet onderling op elkaar zijn afgestemd. Het is net een lappendeken. Ongetwijfeld ingericht met de beste bedoelingen om een helder, eenduidig en eerlijk proces te laten verlopen. Maar vaak puur en alleen bekeken vanuit de eigen dimensie en niet vanuit het klantperspectief. Met als gevolg dat de klant zich aan zes verschillende processen moet houden. En dat kan in deze tijd niet langer meer. Vanuit bedrijfsmatig perspectief  is er het nodige te verbeteren. Het uitlijnen van de IT-activiteiten in het kader van DevOps kan daarbij enorm helpen.

        Waarbij helpt DevOps?

        Wij zien DevOps als het vervolg op Agile: niet alleen werken we binnen IT-ontwikkeling nauw samen met de business, maar we doen dit nu ook met en door Beheer. Zodat er maar één IT-loket is waar de business haar ondersteuning hoeft te halen. Die processen moet je dan wel bekijken vanuit Lean perspectief: end-to-end en met zo min mogelijk waste. DevOps als trend bestaat nu vooral uit technische integratie tussen Ontwikkeling en Beheer. Maar dan benut je volgens ons niet alle beschikbare middelen. Als je het gedachtegoed van DevOps serieus neemt dan ben je ambitieuzer en pak je ook het organisatorische deel aan. Dan helpt DevOps bij uitlijning van de IT-processen, bekeken vanuit bedrijfsmatig perspectief.

        Moeten we opnieuw beginnen?

        Nou, niet helemaal. Maar met name op het gebied van de aansturing van de IT zal er wel het nodige moeten veranderen. Nu staan vaak de interne processen centraal waar de aanvrager aan moet voldoen. Dat kan niet langer, omdat er op die manier geen waarde wordt gecreëerd. De fundamentele verandering waar we voor staan is dat alle activiteiten geprioriteerd moeten worden op basis van business value: welke activiteit levert vanuit bedrijfsmatig perspectief het meeste op? Dat doen we veelal al in Agile projecten, maar dat zal nu dus ook binnen Beheer het nieuwe paradigma moeten zijn. Dus incidents en changes worden dan niet langer meer op basis van matrices  gepland en uitgevoerd. Sterker nog, het hele onderscheid tussen incidents en changes valt weg op het moment dat je het gaat hebben over business value! Ook Regievoering zal business value als leitmotiv moeten gaan hanteren. En het klassieke onderscheid tussen functioneel, applicatief en technisch beheer is niet iets waar de business zich heel erg druk om maakt, dus ook daar zullen de tussenmuren moeten verdwijnen.

        Waar beginnen we?

        Het staat al geruime tijd boven deze blog: Anders denken is anders werken. Voor ons begint state-of-the-art IT met het denken in integraliteit, onderlinge afstemming, doelgerichtheid en waardecreatie. Vanuit dat anders denken kom je vanzelf tot andere oplossingen. Denk aan Einstein die zei: “We can't solve problems by using the same kind of thinking we used when we created them.” Dus om tot nieuwe oplossingen te komen moeten we onze bestaande processen en afdelingen een flinke reboot geven. Agile, Lean en DevOps helpen ons om hier praktisch handen en voeten aan te geven. Denkt u met ons mee?

        Voor wie nog niet exact weet wat DevOps is, zie onze vorige blog.

         
          Posted in Agile like, Agile ontwikkelen, Bedrijfsvoering, DevOps, Implementatie van agile | 1 Comment

          Is DevOps het nieuwe Agile?

          Posted on 18 december 2012 by Anko Tijman
          Bent u nog druk met Agile implementeren? Wees u er dan van bewust dat de volgende trend  er al weer aan komt. DevOps maakt af wat Agile begonnen is: technologische en procesmatige integratie tussen ontwikkeling en beheer. Waar Agile zich focust op klant en IT-vernieuwing, wordt nu ook de laatste muur naar het  snel kunnen leveren van waardevolle software, definitief geslecht: die voor de beheerafdeling. Ik zal een tipje van de sluier rondom DevOps oplichten.

          Wat is DevOps precies?

          Bij DevOps draait het dus om samenwerking tussen ontwikkeling en beheer. Daar komt de naam ook vandaan: Dev staat voor Development en Ops voor Operations. In DevOps zitten een tweetal kernprincipes in: Continuous Integration en Continuous Delivery. Onder Continuous Integration verstaan we snelle, geautomatiseerde deployments van de ene omgeving naar de andere. Dat kan de traditionele OTAP-straat zijn, maar ook het kortcyclisch verbinden van ‘zij-straten’ valt hier onder. Dit geeft de mogelijkheid om snel de kwaliteit van de nieuwe software te testen en te toetsen. Op zich wordt dit binnen Agile projecten ook vaak al gedaan om de afstand tussen ontwikkelaars en testers te verkleinen.

          Continuous Delivery (CD) hanteert min of meer hetzelfde principe, alleen is er sprake van nog meer automatisering en nog minder afbakening van een release. Feitelijk is er een volledig geautomatiseerde gang naar productie, zonder menselijk ingrijpen. Alle stappen worden namelijk geautomatiseerd getest in een framework. CD stelt u in staat om zeer frequent in zeer kleine batches software op productie te releasen. Soms zelfs meerdere keren per dag. Die updates zijn zo klein dat de impact van een fout vaak nihil is. Dit wordt ‘geharnast’ door een uitgebreide set aan geautomatiseerde tests die de belangrijkste risico’s afvangen. Inmiddels hebben wij een team draaien bij een klant waarbij er in 20 minuten geïntegreerd, getest en gedeployed kan worden naar productie. En dat dus zonder grote risico’s!

          Wat moet mijn organisatie met DevOps?

          Het belangrijkste nieuws van DevOps is dat er geen belemmeringen meer zijn voor een snelle respons van IT op business wensen. Maak uw mensen, zowel vanuit de business, ontwikkeling als beheer, hierop attent. In een tijd waarin effectiviteit wordt gewaardeerd boven efficiency, worden paarse krokodillentranen niet getolereerd. Concreet betekent het dus investeren in verregaande automatisering, dus kritische toolselectie. Geen eilandjescultuur meer waarin teamperformance wordt geoptimaliseerd (een vervelend bij-effect van Agile werken!), maar een gezamenlijk doel en het operationaliseren van organisatieperformance. Er komt één keten van business wens naar deployment, waarin alle activiteiten in het teken staan van beheersbaar live gaan. Zoals een collega van mij gisteren zei: “Alles is beheer!”

          Betekent dit ook anders werken?

          Uw beheerafdeling werkt waarschijnlijk aan de hand van ITIL, ASL en BiSL. Uw ontwikkelteams werken volgens Agile-Scrum. Dat gaat dus botsen. Wie van de 2 gaat de methodenclash winnen? Wat mij betreft wint de derde hond: uw bedrijfsvoering. Laten zij maar aangeven wat waarde heeft: een nieuw stukje software of een incident, een nieuw project of een stel bugs, technisch onderhoud of een nieuwe tool. Vergeet het onderscheid tussen incidents en changes en laat de business beginnen met het prioriteren naar business waarde. Zet nu eindelijk de business aan het roer van uw IT-organisatie en zorg dat u dit zo goed, snel, en beheerst mogelijk faciliteert. Ik ben er van overtuigd dat het serieus implementeren van DevOps dit mogelijk maakt.

           
            Posted in Agile like, Agile methodieken, Agile ontwikkelen, DevOps, Implementatie van agile | 12 Comments

            Scrum avant la lettre

            Posted on 6 november 2012 by admin
            Onlangs was ik op een bijeenkomst met vakbroeders (tja er waren geen dames) waarbij een aantal mensen iets presenteerden over de wijze waarop hun organisatie Agile geïmplementeerd heeft. Een van de presentatoren meldde een teamsamenstelling zonder Scrummaster en Product Owner en wel een Team Lead en noemde de systeemtest een aparte story op de Backlog. Nadat de puristen weer terug op hun stoel zaten kwamen de vragen en ja, daar deed ik ook mee. Gelukkig stelde ook iemand de zinvolle vraag: Werkt dit voor jullie? Het antwoord was hierop een volmondig ja en er werd ook aangegeven dat het een hele vooruitgang was.

            Natuurlijk moet men na blijven denken over eventuele afwijkingen met de scrumguide, maar zolang de voor- en nadelen van de huidige werkwijze en van het volgen van de scrumguide goed zijn meegenomen mag het geen probleem zijn om er van af te wijken. Het is wel zinvol om dit regelmatig te evalueren want het zou zomaar een logische volgende stap kunnen zijn om toch te conformeren aan de guide. Niet omdat het zo opgeschreven maar omdat de meerwaarde van die aanpak uitgenut kan worden.

            Gert van de Krol is Agile Projecmanager, Scrummaster, Trainer en Coach.
              Posted in Agile like, Agile methodieken | Tagged , , | Leave a comment