Intern onderzoeksrapport · niet klant-zichtbaar
Welke bewezen methodiek past bij een klein dev-bureau met de mix van onderhoud, projecten en ad-hoc werk, en wat moeten we aanpassen voor correct, stabiel en schaalbaar werken.
Sectie 01
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.
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.
Sectie 02
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 | 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.
Sectie 03
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.
Sectie 04
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.
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:
| Werk-bucket | Start-hypothese % netto |
|---|---|
| Standard (projecten + changes) | ~55% |
| Onderhoudsreservering (service requests, DevOps, key-rotatie) | ~25% |
| Ad-hoc-buffer | ~20% |
| Expedite (harde-SLA-incidenten) | bovenop, WIP=1, verdringt Standard |
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.
Sectie 05
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.
Sectie 06
Nabij concreet, ver globaal (bewust, tegen scope creep).
Meet 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.
Eé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.
Capacity 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.
Externe 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.
DORA-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.
Sectie 07
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.
Sectie 08
Dit is een voorbeeld-vertaling als start-hypothese, uitdrukkelijk geen tool-besluit of migratie-advies. De methodiek moet eerst binnen ClickUp werken.
Fase 1 beantwoordt empirisch of ClickUp de oorzaak of een spiegel is. Stroomt de methodiek binnen deze inrichting, dan is migratie onnodig.
Sectie 10
Twee prioriteiten voor de tekentafel: (a) besluit proces-eerst vs. commercieel-eerst (of parallel), en (b) bewaak dat het model licht blijft.
Sectie 11
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.