De dierentuin binnen uw organisatie
Loop door een middelgroot techbedrijf en tel op hoeveel verschillende manieren teams werken. U komt vingers tekort.
Werkt volgens het scrumboekje. Sprintplanning op maandag, om de week een retro op vrijdag. Schat in story points. Velocity wordt bijgehouden over de laatste zes sprints.
Geen sprints. Het werk stroomt over een bord met WIP-limieten. Er wordt meerdere keren per dag uitgerold. Meet doorlooptijd in plaats van velocity. "Sprintplanning" is een onbekend begrip.
Werkt naar een wettelijke deadline toe. Het eindpunt staat vast en de scope wordt bepaald door een auditor, niet door een product owner. Fasen, opleveringen, akkoorden. Klassiek projectmanagement.
De helft van de tijd is gepland werk, de andere helft is reactief. Onderhoudsvensters in het weekend, incidenten afhandelen zodra er iets stukgaat. Hun "sprint" is alles wat niet werd onderbroken.
Verkent een ML-model dat misschien wel en misschien niet werkt. De planning is "dat hangt ervan af". Schatten in story points is zinloos, want de scope wordt pas duidelijk als ze halverwege zijn.
Een ingehuurd bureau dat levert binnen een vaste scope en planning. Rapporteert maandelijks. Hun interne proces is voor u onzichtbaar en eerlijk gezegd niet relevant. De oplevering komt er of niet.
Zes teams. Zes totaal verschillende manieren van werken. Allemaal dragen ze bij aan dezelfde strategische doelen. Allemaal staan ze op dezelfde roadmap.
Dit is geen uitzondering. Dit is de norm. En precies hier lopen de meeste planningstools en frameworks stilletjes vast.
De valkuil van uniformiteit
De eerste reflex bij deze chaos is standaardiseren. Kies een framework. Rol het uit naar iedereen. Laat alle teams in dezelfde eenheden schatten, in hetzelfde ritme rapporteren en dezelfde ceremonies volgen.
Dat werkt nooit. Of preciezer: het werkt voor de teams waarvan het werk toevallig in het gekozen framework past, en het schuurt bij alle anderen.
Dwing het infrastructuurteam in sprints en het gaat het systeem omzeilen: de sprint vullen met gepland werk en incidenten "buiten de boeken" afhandelen. Dwing het data-scienceteam in story points en u krijgt verzonnen getallen waardoor het bord er compleet uitziet, maar die niets betekenen. Dwing een projectteam in agile ceremonies en u krijgt een scrummaster die eigenlijk gewoon een projectmanager met een andere pet op is.
Het probleem is niet dat standaardiseren in principe verkeerd is. Het probleem is dat het het verkeerde probleem oplost. Het doel was nooit om iedereen op dezelfde manier te laten werken. Het doel was een samenhangend beeld te krijgen terwijl iedereen anders werkt.
Teams die wezenlijk verschillend werk doen in uniformiteit dwingen, levert geen afstemming op. Het levert toneelspel op.
Waarom de verschillen bestaan
De variatie is niet willekeurig. Ze komt voort uit de aard van het werk zelf.
Werk met een bekend eindpunt neigt naar projectmatig plannen. Het compliance-initiatief heeft een vaste scope die door regelgeving wordt bepaald en een deadline die een auditor stelt. De route is planbaar. Fasen en mijlpalen zijn logisch, omdat u de finish vanaf het begin kunt zien.
Werk met een onbekend eindpunt neigt naar iteratief ontdekken. De nieuwe productfeature is een experiment. U hebt een hypothese, geen specificatie. Sprints zijn logisch, omdat u moet leren, bijsturen en opnieuw leren. Vooraf een gedetailleerd plan vastleggen zou verspilling zijn.
Werk dat vooral reactief is past in geen van beide modellen goed. Het infrastructuurteam kan zijn upgrades plannen, maar de helft van zijn capaciteit gaat op aan incidenten die zich niets aantrekken van sprintgrenzen.
Werk dat verkennend is laat zich helemaal niet schatten. De planning van het data-scienceteam hangt af van de vraag of hun aanpak werkt, en dat weten ze pas als ze het hebben geprobeerd.
Alle vier soorten werk komen in de meeste organisaties voor. Vaak binnen dezelfde afdeling. Soms in hetzelfde team. Dat is geen procesfout. Het is het natuurlijke gevolg van verschillende soorten werk doen.
De planningslaag moet al die variatie opvangen en toch één samenhangende roadmap opleveren. Niet door iedereen in hetzelfde proces te dwingen, maar door hun verschillende processen te verbinden tot één beeld waarmee de leiding richting kan geven en afwegingen kan maken.
Waar het in de praktijk misgaat
Als teams verschillend werken, gaan er op planningsniveau meestal drie dingen mis.
De feature van productteam A hangt af van een oplevering van de externe partner. Team A schat in story points, de partner levert in een maandcyclus. De afhankelijkheid bestaat, maar de planningstools kunnen haar niet weergeven, omdat ze ervan uitgaan dat iedereen op dezelfde manier werkt. Dus zit ze in iemands hoofd, tot ze een blokkade wordt.
De leiding vraagt: "Wanneer is het platforminitiatief klaar?" Het antwoord hangt af van bijdragen van een sprintteam, een kanbanteam en een projectteam. Hun voortgang wordt bijgehouden in verschillende eenheden, in verschillende ritmes, in verschillende tools. Niemand kan een eerlijk antwoord geven, omdat er geen gemeenschappelijke noemer is.
Als strategische prioriteiten verschuiven, moeten de gevolgen doorwerken naar elk team, hoe dat team ook werkt. Maar als de planningslaag alleen sprints begrijpt, kan ze het projectteam niet vertellen dat de volgorde van mijlpalen moet veranderen, of de externe partner dat de opdrachtomschrijving opnieuw moet worden besproken. Het doorwerken stopt bij de grens tussen methodieken.
Wat wel werkt
De oplossing is niet om te veranderen hoe teams werken. Het is om ze op het juiste abstractieniveau te verbinden.
Op strategisch niveau hoeft de leiding niet te weten dat team A sprints draait en team B kanban. Ze moet weten welke features op schema liggen, welke risico lopen en wat er gebeurt als ze een prioriteit verandert. De abstractie op dit niveau bestaat uit doelen, features en doorlooptijden. Hoe teams tot die doorlooptijden komen, is hun zaak.
Op tactisch niveau moet het plan werken met de eenheden die elk team gebruikt. Story points van het ene team, tijdschattingen van het andere, vaste mijlpalen van een derde. De planningsengine vertaalt dat allemaal naar één gemeenschappelijke tijdlijn. Niet door story points om te rekenen naar uren (dat werkt nooit), maar door de eigen schattingsmethode van elk team te gebruiken en het systeem te laten berekenen wanneer iets klaar is, gegeven de capaciteit en de volgorde.
Op operationeel niveau blijven teams werken zoals ze werken. Sprints, kanban, projectfasen, wat er ook past. De enige voorwaarde is dat de voortgang terugstroomt naar boven. Sluit een sprint af, dan weet het plan dat. Loopt een mijlpaal uit, dan past de roadmap zich aan. Levert de partner te laat, dan schuiven de afhankelijke features automatisch op.
De lagen blijven gescheiden. De verbindingen blijven live. En de leiding krijgt één samenhangend overzicht, ondanks de zes verschillende werkelijkheden eronder.
Dat is geen frameworkwijziging. Het is een andere bedrading. U vraagt niemand om anders te werken. U maakt hun verschillende manieren van werken zichtbaar en verbonden op het niveau waar het ertoe doet.
Eén roadmap. Elke manier van werken.
Taskstreamer verbindt sprints, projecten en alles daartussen tot één automatisch berekende roadmap. Zonder gedwongen standaardisatie.
Probeer 30 dagen gratis