Scrum, Kanban en Agile zijn in de wereld van softwareontwikkeling inmiddels breed ingevoerde technieken. Ze hebben tot doel de efficiëntie en de productiviteit van ontwikkelafdelingen te vergroten en op die manier de tevredenheid van klanten en gebruikers te verhogen. Ondanks vele goede resultaten, blijkt in de dagelijkse praktijk niet elk probleem daarmee opgelost te zijn. Nog steeds vertragen projecten of opleveringen van storypoints, nog steeds is de doorlooptijd soms te lang en zijn klanten ontevreden, nog steeds is er sprake van spanning tussen kwaliteit en leverdatum, nog steeds leeft bijna iedereen met wisselende prioriteiten en multitasking (of noemen we dat nu ineens Agile?) en bovenal: nog steeds is de werkdruk bij ontwikkelaars in veel gevallen hoog of zelfs te hoog.

Software ontwikkelaar Ortec in Zoetermeer kampte ook met bovenstaande problemen. Ondanks de invoering van nieuwe inzichten zoals Agile en Scrum, bleef de backlog hoog, was de doorlooptijd vaak te lang, waren klanten ontevreden over de leverdata, liet de kwaliteit nog wel eens te wensen over en was de werkdruk hoog en soms te hoog.

Variatie en afhankelijkheid

Tijdens een kennismaking met de Theory of Constraints ontstond het inzicht dat deze problemen een logische samenhang hebben en dat het oplossen van één ervan eigenlijk symptoombestrijding is.

In elk productieproces en elk systeem is namelijk van nature sprake van variatie: elke stap in een productieproces kost bewerkingstijd én doorlooptijd en het is vrijwel uitgesloten dat dezelfde stappen altijd dezelfde hoeveelheid tijd kosten. Daarmee wordt de uitkomst (lees: de leverdatum van het product) van het productieproces onzeker. Als er bovendien sprake is van onderlinge afhankelijkheid van stappen en mensen, dan is het onvermijdelijke gevolg dat projecten en taken soms vertragen en dat medewerkers aan meer dan één taak of project tegelijk moeten werken. En dat heeft tot gevolg dat er meer onderhanden werk in het ‘systeem’ aanwezig blijft, met nog langere doorlooptijden en het nog meer verdelen van de aandacht (multitasken). Variatie in combinatie met afhankelijkheid leiden vrijwel altijd tot langere doorlooptijden én tot hogere bewerkingstijden en daarmee een verlies van capaciteit.

Binnen de Theory of Constraints wordt onderkend dat de output van elk productieproces of systeem bepaald wordt door slechts één factor, namelijk de constraint of bottleneck. Om die reden heeft het geen zin een systeem ‘vol’ te stoppen, maar er zoveel in toe te laten als de constraint aankan én zoveel dat de constraint niet stil zal vallen. Het eerste vindt plaats door WIP-control, het tweede door buffermanagement, bij elkaar Drum Buffer Rope genoemd.

De Drie Lagen in het productieproces

Voor de implementatie van WIP control én Buffer Management (Drum Buffer Rope) is het noodzakelijk het productieproces van software te beschouwen op drie lagen van voortbrenging: portfoliomanagement, projectmanagement en taskmanagement. Het toepassen van de TOC principes daarop betekent in grote lijnen: alle beslissingen, genomen op alle niveaus, zijn gericht op het behalen van een gezamenlijk operationeel doel. Medewerkers en managers weten op elk moment wat hij of zij moet doen om dat doel te bereiken, omdat hij/zij inzicht heeft in status, prioriteit en levermoment van alle taken en alle projecten ten opzichte van het doel. Hierdoor ontstaat op elk gewenst moment focus op wat nu gedaan moet worden om het doel maximaal te bereiken. Maandelijkse analyse van de afwijkingen van dat doel leidt tot focus op wat nu veranderd moet worden om de prestatie van het systeem structureel nog verder te verbeteren.

Noodzakelijke randvoorwaarden

Deze manier van werken stelt de nodige eisen aan het gedrag van medewerkers en management én aan de manier van samenwerken. De volgende voorwaarden dienen hiervoor ingevuld te zijn:

• Medewerkers en management vertrouwen elkaar volledig en gaan er van uit dat iedereen altijd goede intenties heeft: Community of Trust. Als er dingen mis gaan, is dat of het gevolg van een incident (special cause variation) of van een systeemfout (normal cause variation). De eerste wordt bestreden in de uitvoering, de tweede is onderwerp van onderzoek en mogelijk verbetering van het systeem.
• Medewerkers en management streven hetzelfde (SMARTI) doel na: Unity of Purpose. Dit doel dient zowel operationeel gedefinieerd te worden, als tactisch overeengekomen. Bij een software ontwikkelaar zoals Ortec is dat gedaan door de volgende afspraken te maken:
  • Per jaar is een overeengekomen budget (en dus capaciteit) beschikbaar om ontwikkelpunten te produceren.
  • Per jaar wordt een x aantal ontwikkelpunten per persoon, team en afdeling geleverd. Hieruit volgt de gemiddelde productie per week.
  • Elk te ontwikkelen software product wordt ingedeeld in een categorie Small, Medium of Large en krijgt daarmee een bewerkingstijd (aantal te besteden ontwikkelpunten) en een (korte) doorlooptijd.
  • Elk team dient 90% van de te ontwikkelen producten binnen de gestelde doorlooptijd af te ronden.
• Professionals in het team besluiten zelf wat ze wanneer op welke manier doen en wanneer ze hulp nodig hebben; de manager ondersteunt het team bij een hulpvraag maximaal om het doel te halen en grijpt in als dat bedreigd wordt: Zelfsturing in teams met Professionals
• Er is overeenstemming over het prioriteren van taken en projecten op afgesproken leverdatum: Buffer Management
• Er is overeenstemming over de hoogte van de limiet van het Onder Handen Werk in het systeem als geheel: WIP-limits

Noodzakelijk hulpmiddel

Naast deze organisatorische afspraken is software noodzakelijk die op de juiste manier de juiste TOC principes ondersteunt. Bij ORTEC is dat gevonden in de LYNX TameFlow applicatie, waarbinnen de zogenaamde TameFlow aanpak voor Kanban is geïmplementeerd (zie The TameFlow approach and its application to Scrum and Kanban by Steve Tendon and Wolfram Müller).

Kanban is een methode die zeer goed past bij het managen en uitvoeren van kenniswerk of in het algemeen van immateriële processen en workflows. Kanban richt zich op “Contineous Delivery” van output, waarbij het werk en beschikbare capaciteit telkens met elkaar in balans zijn. In een Kanban proces worden alle werk items gevisualiseerd met behulp van een Kanban board, zodat iedereen direct zicht heeft op voortgang van het proces, van definitie tot en met afronding van elke werk item. Starten van nieuwe taken geschiedt op basis van het “pull” principe en op het moment dat capaciteit beschikbaar is.

De Kanban methode, gebaseerd op het “Toyota Production System”, werd als eerste toegepast voor Software development processen, maar wordt tegenwoordig ook veelvuldig toegepast Systems Engineering, Product Ontwikkeling en R&D, Marketing en Services Management.

De TameFlow aanpak voor Kanban omvat diverse innovaties voor het verdere optimaliseren van de van de flow en output van een Kanban proces. In TameFlow wordt het “pull” proces en hoeveelheid onderhanden werk gereguleerd op basis van vrijgekomen capaciteit in het gehele proces en niet per proces stap (kolom).Daarnaast is er een “Drum Buffer Rope” mechanisme beschikbaar, die ervoor zorgt dat de meest kritisch proces stap verzekerd is van continue aanvoer. Dit wordt geregeld met behulp van tokens. Verder wordt “buffer management” toegevoegd, waardoor het mogelijk is knelpunten in de voortgang, gegeven een beperkt beschikbare tijd, vroegtijdig te signaleren.

Het software bedrijf A-dato heeft de TameFlow aanpak volledig geïmplementeerd in de LYNX TameFlow software oplossing, welke tevens is geïntegreerd met project en multi-project management op basis van TOC en Critical Chain Project Management.

Portfoliomanagement

De beschikbare capaciteit van ontwikkelteams is per definitie beperkt: hij is zo groot als het aantal medewerkers dat deze functie binnen een organisatie of binnen een afdeling vervult. Deze capaciteit is uit te drukken in ontwikkeldagen of punten en daarmee wordt het mogelijk om het productieproces als een fabriek te beschouwen waar per week of per maand een gemiddeld aantal dagen of punten mee wordt geproduceerd. Projecten worden voorzien van een inschatting van benodigde dagen bewerkingstijd én van de benodigde dagen doorlooptijd. Het toepassen van het TOC-mechanisme Drum Buffer Rope zorgt ervoor dat het Onder Handen Werk (of Work in Progress, WIP) laag genoeg blijft om een goede doorstroom te garanderen (en dus leverbetrouwbaar te zijn) en hoog genoeg om de capaciteit niet stil te laten vallen (en dus voldoende te produceren).

Het al dan niet toelaten van nieuwe projecten wordt besloten in overleg tussen klant en ontwikkelteam, waarbij de doelwaarde per project de prioriteit bepaalt (zie De Projectenfabriek). Bij dilemma’s in de besluitvorming wordt gebruik gemaakt van de TOC Thinking Processes om tot gedragen oplossingen te komen. De verwachtte doorlooptijd kan worden afgegeven op basis van de historische performance van het team (aantal punten per week).

Tijdens het bouwen van de software geeft de zogenaamde Feverchart inzicht in de status per project: het Buffermanagement principe van Critical Chain Project Management (CCPM, zie hierna) geeft focus op wat goed gaat (groen) en waar bijsturing noodzakelijk is (rood). Zie hieronder een voorbeeld uit Lynx, de software die dit proces ondersteunt.

Projectmanagement

Omgaan met onzekerheid binnen Projectmanagement is een belangrijk element en vaak een bron van onnodige vertraging óf van onnodige werkdruk. Deze onzekerheid is terug te vinden in de veiligheidsbuffers die (onbewust) worden ingebouwd in planningen en de ruimte die wordt gehouden in de scope-afbakening. Dit laatste betekent veelal dat er in de praktijk teveel of te weinig wordt afgebakend. De Thinking Processes helpen om de scope zowel voor als tijdens het project goed in de hand te houden.

Door op de juiste manier taken te plannen en te prioriteren krijgt de scope op het juiste moment aandacht. Dit gebeurt met behulp van TOC Prioritering: Buffer Management en CCPM.

In CCPM krijgt elk project een tijdsbuffer, dat wil zeggen dat veiligheid in de planning is geborgd op projectniveau en niet op taakniveau. De projectleider beheert de projectbuffer en geeft ruimte aan taken die meer tijd nodig hebben dan gepland. Omdat er ook taken zijn die minder tijd nodig hebben dan gepland, is de kans groot dat per saldo een project binnen de afgesproken tijd kan worden afgehandeld. Er is continu inzicht in de consumptie van de projectbuffer: groen is in orde, rood betekent bijsturen. Zie onderstaand overzicht van de bufferstatus van een project.

Taskmanagement

Elk team heeft zijn eigen kanban-bord, zodat inzicht en betrokkenheid maximaal zijn. De WIP limits zijn van toepassing op het team als geheel (via zogenaamde kanban-tokens) en eventueel op de aangewezen constraint (via replenishment tokens). Er zijn geen WIP limits op individuele kolommen, hetgeen een betere flow tot gevolg heeft, in vergelijking met een normale uitvoering van kanban. Een kaartje op het kanban bord beslaat een product, bestaande uit een aantal taken: bijvoorbeeld analyse, development, review en test. Iedere taak heeft twee kolommen: ‘Wachten op uitvoering’ en ‘Actief’. Hiermee wordt de werkdruk in één oogopslag duidelijk.

De te ontwikkelen kaartjes worden ingedeeld naar standaard productgroottes (small, medium, large) om inzicht te krijgen in geschatte benodigde bewerkingstijd en om de burn-rate van het team te bepalen – en daarna te bewaken. De burn-rate geeft weer hoeveel developerdays of ontwikkelpunten per week geleverd zijn/kunnen worden. Als de burn-rate van een team bekend is, is een capaciteitsplanning niet meer nodig. Het team is zelf verantwoordelijk voor het afronden van het juiste aantal producten.

Ieder kaartje krijgt een eigen buffer die bedoeld is om de doorlooptijd te managen. De buffer gaat van 0 naar 100% in de per kaartje geschatte (standaard) doorlooptijd. Hierdoor is op elk moment duidelijk welk kaartje welke prioriteit heeft ten opzichte van de geplande leverdatum.

Doordat elk kaartje over het kanban bord stroomt, is er vroegtijdig inzicht in verstoringen van de flow. Het team heeft dagelijks overleg (standup) om deze verstoringen te bespreken in termen van ‘wat te doen’, niet in termen van ‘waarom is het zo gekomen’. Ieder kaartje heeft zoals aangegeven een bufferstatus, weergegeven door middel van een kleur en een percentage. De combinatie van de plaats op het bord en de bufferstatus bepaalt de prioriteit. In de praktijk betekent dit werken van rechts naar links en van boven naar beneden. Teamleden zijn gezamenlijk verantwoordelijk voor het afronden van de kaartjes, daar waar nodig helpen ze elkaar. Een team werkt in principe aan één batch tegelijk, als de backlog leeg raakt worden de kaartjes van een nieuwe batch vrijgegeven.

De maintenance issues (kaartjes) worden op dezelfde manier behandeld als de kaartjes hierboven, dus één issue is één kaartje. Het verschil is dat de buffer van de maintenance taken is gebaseerd op de leverdatum vastgesteld in de SLA met de klant.

Managementrapportages

Gedrag van medewerkers wordt in belangrijke mate beïnvloed door de wijze waarop ze gemeten worden. En dus is het van belang de juiste metrieken te hanteren, waarbij de samenhang van KPI’s essentieel is voor het leveren van de juiste prestatie. Niet alleen het lage Onder Handen Werk is van belang, ook de productie, de doorlooptijd en de leverbetrouwbaarheid. Hiervoor is aandacht nodig tijdens de uitvoering én op managementniveau. De (management) rapportages zijn dienovereenkomstig ingericht, alsmede de wijze waarop hier periodiek (dagelijks, wekelijks en maandelijks) met wie over wordt overlegd en zo nodig corrigerende matregelen worden afgesproken en uitgevoerd. In de praktijk zal dit plaatsvinden in bilateralen, standups, weekoverleg en het maandoverleg.

Uit de management rapportage blijkt of de organisatie dichter in de buurt van haar doel komt. Indien dat niet zo is, dient geanalyseerd te worden wat de organisatie het meest van haar doel weerhoudt. De verzamelde gegevens vanuit buffer management geven daarvoor een indicatie, waarmee gericht processen verbeterd kunnen worden.

Resultaten

In onderstaande grafieken zijn de resultaten van de implementatie bij Ortec weergegeven. In en periode van 6 maanden is de leverbetrouwbaarheid van zowel het ontwikkelteam (development) als het onderhoudsteam (Maintenance) van rond de 30% gestegen naar 90% bij een 6-weeks rollend gemiddelde. Daarnaast is de gemiddelde doorlooptijd van alle producten afgenomen van ruim 40 dagen naar minder dan 25. Tenslotte is het Onder Handen Werk afgenomen van ruim 120 naar ongeveer 20 ontwikkeldagen, ongeveer de hoeveelheid die in 1 week afgerond kan worden.

Naast deze significante verbetering van de prestaties van de afdeling zat de voelbare verbetering voor de medewerkers erin dat de samenwerking binnen de teams aanmerkelijk soepeler verloopt. Er is veel minder werkdruk, er is een zekere trots op het op tijd, snel én voorspelbaar kunnen leveren van de gevraagde modules en fixes. De meeste voldoening bij medewerkers bestaat echter uit het kunnen leveren van nog niet eerder behaalde kwaliteit.