Executive summary + kernaanbeveling
Het kernprobleem is niet snelheid maar stuurbaarheid en voorspelbaarheid. Alle vier de onderzoekslijnen komen op dezelfde diagnose: geen te lage output, maar onbeheerste flow. Werk komt via meerdere ongefilterde kanalen binnen, krijgt geen serviceklasse, concurreert om dezelfde twee kernpersonen, en stroomt door een workflow zonder WIP-begrenzing of release-eigenaarschap. De ~105 open taken zijn een symptoom, geen diagnose.
Kernaanbeveling
Service-Scrumban: Kanban-flow als ruggengraat met een licht wekelijks ritme, plus Classes of Service, capacity buckets, ITSM-light en Shape Up-light als bouwstenen.
Kanban is de enige kandidaat die tegelijk softwareonafhankelijk is, "correct en stabiel boven efficiënt" respecteert (WIP beperken zodat werk afgemaakt wordt), gemengd werk expliciet ondersteunt, en evolutionair (zonder big bang) invoerbaar is. De wekelijkse cadans haakt op de al herstelde maandag-weekbespreking.
Twee harde voorwaarden
- Fase 0 begint met meten, niet herinrichten. De verdeling onderhoud/project/ad-hoc is niet gemeten en kantelt de aanbeveling. Zonder die meting is elke bucket- en WIP-uitspraak een aanname.
- WIP-reductie is eerste-orde-doel vanwege het reële vertrekrisico van de kern-developer. Onderbroken taken kosten aantoonbaar meer tijd en fouten; instabiele prioriteiten drijven burn-out.
Waar de aanbeveling kantelt: >60% voorspelbaar projectwerk → Shape Up zwaarder; >40% incident/support met harde responstijden → ITSM-light leidender; bottleneck bij release/review → release-governance eerst.
Diagnose van de huidige staat
Vermoedelijke waardestroom: intake (meerdere kanalen) → onbeoordeelde backlog → impliciete prioritering ("wie het hardst roept") → development → review/merge → release/tag → acceptatie. Wachttijden en blokkades vooral op vier punten: intake (geen poortwachter), prioriteringsbesluit (geen regel), development (context-switching door te veel gelijktijdig werk), release (grijze rechten).
Werksoort-taxonomie · de eerste te meten grootheid
| Werksoort | Bron | Urgentie | Voorspelbaarheid |
|---|---|---|---|
| Incident (onderhoud, harde SLA) | contractklant | hoog, tijdgebonden | laag (emergent) |
| Service request (serverbeheer, DevOps, key-rotatie) | contractklant | middel, planbaar | hoog (repeterend) |
| Change / feature op onderhoud | contractklant | middel | middel |
| Projectwerk (druppelende scope) | projectklant | deadline-gedreven | laag-middel |
| Ad-hoc verzoek | diverse kanalen | wisselend | zeer laag |
| Intern werk / tech debt | intern | laag | hoog |
Blinde vlek die het rapport toetst
"De werkwijze is het probleem" is deels waar, maar de diagnose wijst even sterk op een intake-/commercieel probleem: geen serviceklassen, informele klantafspraken, geen "nee/nu-niet"-proces. Meer capaciteit (de externe partij 50→150u) kan de bottleneck tijdelijk verplaatsen en throughput verlagen door onboarding-overhead (Brooks's Law). Een variabele in de fasering, geen quick win.
Methodiekvergelijking
Alle kandidaten zijn als gelijkwaardig beoordeeld. A · kern-kandidaat B · bouwsteen C · afgevallen
| Methodiek | Waarvoor | De pijn (trade-off) |
|---|---|---|
| A Kanban Method | Continu, gemengd, onvoorspelbaar werk; WIP beperken; softwareonafhankelijk | Weinig ingebouwde cadans; vereist WIP-discipline; geen project-shaping |
| A Scrumban | Kanban + licht wekelijks ritme; aanbevolen voor support/maintenance | Iets meer ceremonie; risico op "mini-Scrum" met impliciete commitments |
| A Shape Up | Projecten met druppelende scope; fixed time / variable scope | Ontworpen voor eigen product, niet klantwerk; dekt onderhoud/SLA/ad-hoc niet |
| A ITIL 4 / ITSM-light | Onderhoud/support scheiden van projecten; incident, change, SLA | Overproces-risico in klein team; geen planningssysteem voor projecten |
| A Capacity buckets | Terugkerend + ad-hoc + project door elkaar; vaste % per werksoort | Voelt inefficiënt; percentages zijn giswerk zonder fase-0-meting |
| B Classes of Service | Expedite / Fixed Date / Standard / Intangible uit elkaar houden | — |
| B ToC · Cynefin · DORA · RACI · SLE | Taal, sensemaking, release-governance, roldefinitie, voorspelling | — |
| C Alleen Scrum / tool / mensen / SAFe / PRINCE2 | — | Botst met reactief werk, of overproces voor <15 personen |
Sterkste tegenhypothese
"Commercieel/scope-eerst" i.p.v. "proces-eerst". Als de kern-oorzaak het ongecontroleerd ja-zeggen is, dan is een operating model bouwen bovenop ongecontroleerde instroom het optimaliseren van de verkeerde constraint. Het rapport verwerkt dit deels (intake-poort met mandaat, scope-control), maar het blijft een expliciete keuze voor de tekentafel: besluit proces-eerst, commercieel-eerst, of parallel.
Aanbevolen operating model
Service-Scrumban: Kanban-flow met wekelijkse cadans, ITSM-light-taxonomie, Shape Up-light voor projecten en vaste capacity buckets. Het enige model dat de gemengde werkmix, softwareonafhankelijkheid en "correct-en-stabiel-boven-efficiënt" tegelijk dient, en evolutionair invoerbaar is.
Capaciteitsmodel in twee stappen
Eerst overhead (management, review, release, klantcontact) van de brutotijd aftrekken → netto uitvoerbare uren. Review/release is geen bucket maar overhead, want dev+review+release zitten in één persoon. Dán de netto uren verdelen:
Verdeling van de netto uitvoerbare uren
Start-hypothese · % nettoGestapelde balk van de netto uren: Standard, dat wil zeggen projecten en changes, ongeveer 55 procent; onderhoudsreservering voor service requests, DevOps en key-rotatie ongeveer 25 procent; ad-hoc-buffer ongeveer 20 procent. Expedite voor harde-SLA-incidenten komt hier bovenop met WIP=1 en verdringt Standard.
Harde-SLA-incidenten komen bovenop deze verdeling en verdringen Standard. Geen eigen bucket, wel een eigen swimlane.
Load-budget · harde toets
Het procesoverhead mag in de startfase niet meer dan ~1,5-2 uur per persoon per week kosten. Meer? Dan terugsnijden, niet uitbreiden. Default-cadans = maandag ~45 min (replenishment + triage in één) + een vast release-window. Dagelijkse checks, aparte triage en maandelijkse review zijn opt-in, alleen na bewijs dat het nodig is. De vier rollen zijn twee mensen met elk 2-3 petten; het gaat om helder eigenaarschap van beslissingen, niet om personele scheiding die er niet is.
Release- en change-policy
Grijze deploy-rechten zijn een stabiliteits- en overdrachtsrisico. DORA-data (correlationeel, geen causaal experiment) laat zien dat zware, externe goedkeuring samengaat met slechter presteren en de change failure rate niet verlaagt. De les voor een klein team: lichte peer-review + duidelijke ownership, geen bureaucratie.
- Merge-review: elke merge naar master vereist één peer-review (niet de auteur).
- Release-owner: precies één Accountable per product (RACI), met backup. Niet "beiden alles".
- Change-typen: standard (vooraf goedgekeurd) → geen extra stap; normal → peer-review; emergency → fast-track met achteraf-review.
- Rollback vóór deploy beschreven, vast change-window, uitwijk-/afwezigheidsprocedure (bus factor).
- Definition of Done per werksoort; post-incident review blameless.
Gefaseerde padstelling
Nabij concreet, ver globaal (bewust, tegen scope creep).
Stabiliseren en zichtbaar maken (in ClickUp)
Fase 0 · ~1-2 wekenMeet de werksoort-mix en intakekanalen; meet netto uren (bruto − overhead); classificeer de 105 taken en verouder agressief; maak waardestroom + work item age zichtbaar; wijs release authority + backup aan; zet één intakepunt aan.
Falsificatietest: de work-item-age-meting toetst de hele framing. Stroomt werk gelijkmatig door en is de constraint puur capaciteit, dan kantelt het richting een capaciteits-/commercieel vraagstuk en wordt dit model secundair. Fase 0 moet kunnen aantonen dat de aanbeveling fout is.
Stop-meetpunt: 95% van de taken heeft werksoort/commitment/owner; mix en leeftijdsverdeling gemeten; nieuwe taken via triage.
Intake, WIP, serviceklassen
Fase 1 · ~2-4 wekenEén intake-poort; WIP-limiet per kolom (start: 2/3-3/4 van het aantal developers; Ladas noemt WIP=5 voor een 3-persoonsteam); Classes of Service (Expedite WIP=1, Fixed Date ≤30%, Standard ≥50%, Intangible laatst); SLE uit de fase-0-data; backlog splitsen in committed vs. options. WIP-reductie ís de directste ontlasting van de constraint.
Stop-meetpunt: geen werk start zonder serviceklasse; WIP daalt; oudste taken beginnen te stromen.
Onderhouds- en projectcadans
Fase 2 · maand 2-3Capacity buckets vastzetten op de gemeten mix; wekelijkse replenishment op de maandag; release/change-policy vastleggen incl. RACI en DoD; grote projecten met druppelende scope: appetite + shaping vooraf.
Stop-meetpunt: SLA-naleving en SLE-hit-rate meetbaar verbeterd; release-owner eenduidig.
Externe capaciteit inbedden
Fase 3 · maand 3-6 · globaalExterne partij krijgt afgebakende werkpakketten met DoR/DoD, eigen WIP-limiet, zichtbare review-afhankelijkheid. Reken op tijdelijke throughput-dip. Uren 50→150 → review-capaciteit groeit mee of werk wordt begrensd.
Stop-meetpunt: externe throughput stijgt zonder stijging in review-aging, rework of change failure.
Optimaliseren met metrics en automatisering
Fase 4 · bewust globaalDORA-metrics gaan sturen; automatiseer standaard-changes; herijk buckets en WIP op data; eventueel tool-evaluatie. Geen detail nu, alleen richting.
Scope-grens (nu niet): geen ClickUp-migratie, geen teamsplitsing, geen zware ITIL-uitrol, geen fixed-cyclus-projectmodel.
Kill switch: als na fase 1 (~6 weken) de work item age niet daalt, de governance het load-budget overschrijdt én Agus het als extra last ervaart, stop je met uitrollen en heroverweeg je de framing.
Adoptie mét Agus, niet aan Agus: co-ownership vanaf de tekentafel; verkoop het als lastenverlichting (minder onderbrekingen), niet als governance; begin met het minimum. Dit is voor deze situatie een groter risico dan de methodiekkeuze zelf.
Meetplan
Flow-metrics: WIP, cycle time, throughput, work item age, wachttijd per status, blocked time, % ongepland werk, % expedite, SLA/SLE-naleving, review-/release-wachttijd. DORA-light: change lead time, deployment frequency, change fail rate, recovery time. Bus-factor en werkdruk (interrupts/dag, after-hours incidenten).
Succescriteria: minder aging work · minder ongepland gestart werk · hogere SLA-naleving · lagere change failure · betere voorspelbaarheid (SLE-hit-rate) · hogere bus factor · merkbaar lagere werkdruk.
Vertaling naar ClickUp· voorbeeld, geen tool-besluit
Dit is een voorbeeld-vertaling als start-hypothese, uitdrukkelijk geen tool-besluit of migratie-advies. De methodiek moet eerst binnen ClickUp werken.
- Statussen: Inbox → Triage → Ready → Active → Blocked → Review → Ready to Release → Released/Verify → Done → Parked.
- WIP-limieten per kolom: Expedite 1, Active 1 per developer, Review ≤2, Ready to Release ≤2.
- Serviceklasse als gekleurde tag; Expedite als aparte swimlane.
- Swimlanes = capacity buckets (Standard / Onderhoud / Ad-hoc / Expedite). Hier is een lichte board-inrichting wél nodig, niet dogmatisch tool-agnostisch blijven.
- Custom fields, klein beginnen: werksoort, serviceklasse, klanttype, commitment-status. Rest pas als aantoonbaar nodig (load-budget geldt ook hier).
- Intakeformulier als enige poort; maandag-weekbespreking = replenishment/triage.
Fase 1 beantwoordt empirisch of ClickUp de oorzaak of een spiegel is. Stroomt de methodiek binnen deze inrichting, dan is migratie onnodig.
Zelfkritiek· uit adversariële toets
- Convergentie ≠ bevestiging. Vier LLM-lijnen die hetzelfde zeggen = ongeveer één stem. Gewicht zit in primaire bronnen + empirisch flow-onderzoek.
- Sterkste tegenhypothese = commercieel/scope-eerst. Expliciete keuze voor de tekentafel, geen uitgemaakte zaak.
- Risico op overproces bij twee kernpersonen. Daarom load-budget, afgeslankte cadans, klein beginnen, kill switch.
- DORA-data is correlationeel, niet causaal; als associatie geformuleerd.
- Kern-diagnose is toetsbaar gemaakt (falsificatietest in fase 0).
- Adoptie is het grootste niet-methodische risico; co-ownership met de developer.
Twee prioriteiten voor de tekentafel: (a) besluit proces-eerst vs. commercieel-eerst (of parallel), en (b) bewaak dat het model licht blijft.
Bronnen
Primaire framework-bronnen: Kanban Guide (kanban.university), Anderson Classes of Service (djaa.com), Vacanti Actionable Agile Metrics, ProKanban (SLE), Basecamp Shape Up, DeGrandis Making Work Visible, DORA/Google Cloud, Cynefin (Snowden), Theory of Constraints (Goldratt), Team Topologies, PeopleCert/ITIL 4, Brooks's Law.
Empirisch/peer-reviewed: WIP-in-kanban-studie (ACM/IEEE ESEM), Bus Factor In Practice (arXiv/ICSE), Gloria Mark-onderzoek naar interruptiekosten, Paul Graham Maker's Schedule (ouder, gezaghebbend).
Praktijkcases (< ~7 jaar tenzij gemarkeerd): Aktia Solutions (Kanban, 5-persoons team), TopLeft (MSP-Kanban), Kniberg Lean from the Trenches (met vóór/na-metrics, ouder), Octopus (DORA-benchmarks). Vendor/expert-content (Atlassian, Businessmap, Nave, itsm.tools, ITGov Docs, Morefield, Agile Alliance) gemarkeerd. X/Twitter-posts = anekdotisch praktijkperspectief, geen bewijs.
Methodologische kanttekening
Publieke praktijkcases van kleine agencies/MSP's met harde vóór/na-metrics bleken beperkt vindbaar; vier van de vijf lijnen benoemen dit onafhankelijk, wat het als een echte lacune bevestigt, geen zoekfout. De aanbeveling steunt daarom sterker op primaire framework-bronnen en empirisch flow-onderzoek dan op agency-specifieke before/after-cases. Alle vijf de lijnen zijn benut: copilot leverde met vertraging een geverifieerde bronnenlijst die de andere lijnen bevestigde en drie bronnen toevoegde. De kernaanbeveling stond al vóór die late bijdrage en is erdoor bevestigd, niet gewijzigd.