Alle modellen Teammodel

Productteams

Build en Run: het team beheert operationeel wat het zelf bouwt.

Het model vertrekt van één overtuiging: een complex product bouwt u op voortschrijdend inzicht, en niet door alles vooraf te analyseren, uit te schrijven en te plannen. Daarom zitten business, bouw en werking in hetzelfde team: van de eerste vraag tot de werking in productie blijft het werk bij dezelfde mensen.

Wanneer werkt het

Een productteam werkt wanneer het eigenaarschap van een product past binnen een team van vijf tot twaalf mensen, die het samen kunnen bouwen en beheren.

Het werkt ook wanneer nog niet vastligt wat er precies gebouwd moet worden. Er is een richting, en het is duidelijk wat het product moet doen, maar hoe het er precies uitziet en wat het team daarvoor te bouwen heeft, is nog open. In een productteam brengt u experts samen die elk vanuit hun eigen expertise tot één oplossing komen.

De grenzen van vijf en twaalf hebben een reden. Onder de vijf loopt de wachttijd op zodra iemand er niet is. Boven de twaalf worden de onderlinge communicatielijnen te talrijk om nog efficiënt te werken.

Wanneer werkt het niet

Wanneer het eigenaarschap niet in één team past. Is het product te groot voor twaalf mensen, dan knipt u het alsnog in stukken en komt de overdracht terug. Is de vraag te klein om vijf mensen te vullen, dan wordt het team een naam zonder werk en vallen mensen terug op hun oude rol.

Wanneer al vastligt wat er gebouwd moet worden en hoe. Dan is er geen afweging tussen experts nodig, en een team dat samen naar een oplossing zoekt levert daar niets extra op.

En wanneer u het productteam wilt laten passen in hoe uw organisatie vandaag werkt. Dan krijgt u een team met een nieuwe naam binnen oude afspraken. De beweging gaat de andere kant op: u past uw organisatie aan zodat ze de werking van een productteam ten volle kan dragen.

Wat het oplost en wat het schept

Het lost de overdracht op. Het werk wacht niet op een ander team om verder te kunnen, en niemand hoeft een half afgewerkte oplossing uit te leggen aan wie ze moet overnemen.

Het houdt de kwaliteit vast. Een keuze die tijdens de bouw tijd wint maar het beheer zwaarder maakt, komt bij het team zelf terug en niet bij een beheerteam dat ze niet heeft gemaakt. Een team dat draagt wat in productie draait, legt zichzelf een hogere kwaliteitseis op.

Het legt de afhankelijkheden naar de rest van de organisatie bloot. Teams die iets aan het productteam moeten aanleveren, blijven bestaan, en voor een startend productteam is dat vaak het grootste struikelblok. Het team werkt op scope binnen een horizon van enkele weken, terwijl de rest van de organisatie op planning werkt met een horizon van maanden tot jaren. Het team ervaart de organisatie dan als niet flexibel, en de organisatie ervaart het team als cowboys.

Het schept afhankelijkheid van wat de teams delen. Elk productteam kiest eigen oplossingen, en zonder afspraken daarover lopen standaarden uiteen en wordt hetzelfde werk meermaals gedaan.

Wat het voor uw organisatie betekent

Omdat het team er al staat, hoeft u minder projecten in te richten. Werk dat vroeger een project nodig had om mensen bij elkaar te zetten, komt nu bij een team dat er al is.

Het werk dat over het plannen van mensen gaat, neemt sterk af. Demand die per aanvraag naar capaciteit zoekt en overleg dat mensen aan projecten toewijst, vallen grotendeels weg. Ook applicatiebeheer komt in de teams terecht, bij wie het gebouwd heeft.

Daardoor verschuiven de profielen. Teamlead, applicatiemanager en projectmanager zijn rollen in de governance. Product owner, product manager en scrum master zijn rollen binnen een team. Voor de mensen in die functies is dat een andere opdracht, en die verschuiving is vaak de grootste verandering die dit model vraagt.

Wat het van uw governance vraagt

Een portfolio dat budget vrijmaakt op basis van de doelen die gehaald moeten worden, en niet op basis van een uitgewerkte oplossing. Wat er gebouwd wordt en hoe, bepaalt het team zelf. De vraag komt daardoor bij het team toe en niet bij een tussenlaag die ze eerst uitwerkt.

Afspraken met de teams die iets aan het productteam moeten aanleveren, en die afspraken horen in de portfoliobeslissing zelf. Wordt de aanlevering pas achteraf gevraagd, dan botst een horizon van enkele weken op een planning van maanden.

Gedeelde afspraken over wat teams zelf kiezen en wat gemeenschappelijk blijft. Een community of practice houdt die bij elkaar, want daar zitten de mensen die de keuze maken.

Zonder projecten verdwijnt ook de projectrapportering. Wat er te zien valt, gaat over het product en niet over de voortgang van een plan, en dat vraagt andere cijfers dan u vandaag krijgt.

Wat het voor uw mensen betekent

Wie vroeger één stap in de keten deed, draagt nu mee aan het geheel. Dat vraagt breder werk, en het vraagt dat iemand opneemt wanneer het midden in de nacht stilvalt, voor wat hij zelf gebouwd heeft.

Leidinggevenden sturen minder op taken en meer op het resultaat van het product. Dat is een ander vak, en het groeit niet vanzelf uit de oude functie.

Welke keuze uit uw strategie maakt dit model mogelijk, en welke maakt het moeilijker?

Leg die vraag aan ons voor Een gesprek van 30 minuten.

Andere teammodellen

Wat lukt er in uw organisatie vandaag niet optimaal?

In een gesprek van 30 minuten kiezen we samen de eerste stap en een kleine test.