Als je met meerdere teams aan één product werkt, is het een uitdaging om dit zo te organiseren zodat de snelheid en effectiviteit van Agile werken niet in gevaar komt. In dit artikel kijken we naar de voor- en nadelen van twee populaire manieren om product teams te organiseren.
Er zijn grofweg twee opties om product teams te organiseren, met ieder hun eigen voor- en nadelen: ‘component teams’ en ‘feature teams’. In dit artikel bespreken we het thema in hoofdlijnen, wil je de diepte in? Kijk dan naar onze Agile Advanced Masterclass.
Component teams zijn verantwoordelijk voor één of meerdere componenten van het product. Misschien voor de database, de business logica of de front-end.
Het voordeel is dat deze teams veel kennis opbouwen over de components, en dat er relatief smalle technologiekennis nodig is. Een team hoeft bijvoorbeeld alleen maar kennis van front-end technologieën te hebben en niet van back-end of database.
Het nadeel is dat je met deze werkwijze meerdere teams nodig hebt. Dit leidt vaak tot afstemmingsproblemen tussen de teams en in de regel tot vertraging. Het laatste team in de keten dat de feature oplevert bepaalt immers het tempo. De afstemmingsproblemen leiden in de regel tot het aanstellen van coördinators, wat de zelforganisatie van teams juist verhindert.
Feature teams zijn end-to-end verantwoordelijk voor één of meerdere klant-features. Het voordeel van deze werkwijze is dat een team zich helemaal in de klant kan verplaatsen en alles kan doen om waarde voor die klant op te leveren.
Nadeel van deze opzet is dat teams een zeer brede kennis nodig hebben. Ze moeten kunnen werken aan front-end, back-end, database, etc. Hierdoor kost het meer tijd om een feature team goed te laten draaien.