Een Agile team en meerdere opdrachtgevers?

Met de introductie van Agile werken is er veel aandacht voor vaste teams. In Agile termen zelforganiserende of zelfsturende teams. De vaste Agile teams zijn doorgaans verantwoordelijk voor de ontwikkeling van ėėn bepaald product. Echter, wat als jouw Agile team voor meerdere opdrachtgevers en aan verschillende projecten werkt? Kun je ook in die situatie de voordelen van een vast Agile team benutten? En zo ja, hoe kun  je dat inrichten?

In de Agile gids staat dat Agile “voorschrijft” om met een vast multidisciplinair team te werken met als onderdeel van het team een vaste Product Owner of opdrachtgever. Dat maakt nieuwsgierig: wat betekent een vast, multidisciplinair team? Wat zijn daar de voordelen van? En wat is dan een goede samenstelling van een vast multidisciplinair team? En, een Agile team en meerdere opdrachtgevers, kan dat werken?

Voordelen van een vast team

In een team met een vaste samenstelling kennen de teamleden elkaar en elkaars kwaliteiten. Dat betekent dat de fasen van kennismaken, normen stellen en werkafspraken maken, niet voor elke opdracht opnieuw hoeven te worden doorlopen. Als je meer wilt weten van deze fasen, lees dan bijvoorbeeld eens de theorie van Tuckman. Een vast team dat die fasen al heeft doorlopen, is dus sneller slagvaardig.

Bovendien kent het team haar mogelijkheden en beperkingen. Onder andere door het doorlopen van retrospectives krijgt het team hier goed zicht op. De teamleden weten wat ze als team voor elkaar kunnen krijgen, hoelang ze daar doorgaans over doen en wat ze nodig hebben om goede resultaten op te leveren.

Al deze voordelen opgeteld, zorgen ervoor dat het team “voorspelbaar” werk oplevert. Voorspelbaar in termen van de kwaliteit van het product dat het team levert, de doorlooptijd die ervoor nodig is en de kosten die worden gemaakt.

Een goede samenstelling van een vast team

In Agile werk je in multidisciplinaire teams met bijvoorbeeld I-, T- of M-shaped teamleden. Hierbij zegt de vorm van de letter iets over hoe gespecialiseerd een medewerker is:

• I-shaped betreft een medewerker die sterk is gespecialiseerd in één onderwerp.
• T-shaped wil zeggen dat een teamlid naast diepgaande specialistische kennis op één bepaald vlak ook andere kennis en vaardigheden heeft. Dit maakt dat T-shaped teamleden begrip hebben van elkaars werk en elkaar kunnen helpen. Dit kan handig zijn bij een piek in het werk of gewoon als iemand een dagje vrij is.
• M-shaped betekent dat een medewerker specialistische kennis op meerdere vlakken combineert met andere kennis en vaardigheden.

Wanneer je wilt voorkomen dat het werk stil komt te liggen, omdat een specialistische medewerker nog even aan een andere opdracht werkt, is het handig om T- of M-shaped teamleden te hebben.

Om het wat praktisch te maken, hierbij twee voorbeelden:

Een timmerman die in een klusteam ook een beetje kan schilderen en dus een muurtje witten. Of ook een stopcontact kan aanleggen. Of een software-ontwikkelteam waarbij een tester ook eenvoudig programmeerwerk kan doen. 

Niet iedereen is fulltime beschikbaar

Nog één kanttekening bij de teamsamentelling: een vast team wil niet zeggen dat alle leden van het team fulltime beschikbaar zijn. Eén of twee leden van het team kunnen ook een deel van de week beschikbaar zijn, zolang maar vast staat welke deel dat is.

Stel in het klusvoorbeeld dat de stukadoors zeer schaars zijn. Dan kun je een stukadoor voor twee teams laten werken: twee dagen voor het ene team en drie dagen voor het andere team. Zo weet elk team op hoeveel stukadoorscapaciteit zij wekelijks kan rekenen, is de teamsamenstelling vast en blijft hun werk voorspelbaar.

Nu de voordelen en de samenstelling van vast team helder zijn, terug naar de hoofdvraag: kan een vast team voor meerdere opdrachtgevers werken? en zo ja, hoe dan?

Een vast Agile team voor meerdere opdrachtgevers?

Stel je hebt een vast team met de juiste samenstelling en goed ingewerkt. En er zijn meerdere klanten of opdrachtgevers voor wie dat team producten of diensten levert. In het klus-voorbeeld:

het team renoveert panden en de te renoveren panden zijn niet op alle dagen van de week toegankelijk. Het team werkt daarom aan meerdere panden tegelijk. Of in de softwareontwikkeling is er een team dat de aanpassingen in standaardsoftware pakket voor verschillende klanten realiseert.

In theorie zijn er minstens twee mogelijkheden: om één team voor meerdere opdrachtgevers te laten werken met een interne opdrachtgever óf een vaste tijdsverdeling over klanten.

Eén interne opdrachtgever

In deze eerste optie, worden meerdere externe opdrachtgevers vertegenwoordigd door één interne opdrachtgever: de Product Owner. De interne Product Owner rol kan bijvoorbeeld worden ingevuld door de accountmanager die namens de leverancier afspraken maakt met deze klanten. Of door een productmanager die verantwoordelijk is voor de applicatie waar de werkzaamheden voor de verschillende klanten betrekking op hebben.

Deze Product Owner is dan de beheerder van de lijst met op te leveren (deel-)producten. Dit is de Product Backlog. Hierop staan de wensen van de verschillende klanten. Op basis van dit overzicht, stelt de Product Owner deze dan de prioriteiten vast. En daarmee bepaalt de Product Owner welke klanten de komende sprint welke (deel)producten zullen ontvangen.

Daarbij zorgt de Product Owner dan ook zelf voor de communicatie met de klanten, bespreekt met hen de (on)mogelijkheden en prioriteiten in de planning. Ook nodigt de Product Owner de klanten uit voor reviewsessies.

Vaste tijdsverdeling over klanten

Een tweede mogelijkheid is om de tijd die één team ter beschikking heeft op te delen. Zo kan het team twee dagen per week werken aan de producten voor opdrachtgever X en drie dagen per week voor die van opdrachtgever Y. Binnen de tijd die voor een klant beschikbaar is, kan het team rechtstreeks met de opdrachtgever communiceren. De opdrachtgever bepaalt dan in overleg met het team waaraan de beschikbare dagen in de komende sprint worden besteed en wat er zal worden opgeleverd. Komt het team er niet uit met een opdrachtgever dan kan ook hier een interne Product Owner een rol spelen. Deze interne Product Owner is dan het escalatieniveau en weegt de belangen van de verschillende klanten tegen elkaar af. Het team maakt deze afweging niet.

Een oplossing specifiek voor jouw organisatie?

In deze blog hebben we twee mogelijkheden benoemd voor vaste teams met meerdere opdrachtgevers. Hierbij biedt de eerste optie meer flexibiliteit dan de tweede. We hopen dat deze ideeën je helpen bij het inrichten van een organisatie waarin een Agile team en meerdere opdrachtgevers samengaan. De praktijk is altijd weerbarstiger en complexer dan de theorie.

Wil je in gesprek over de specifieke situatie in jouw bedrijf? Neem contact met ons op en we helpen je graag verder. Tijdens kantooruren kun je ook terecht op onze chat.

Contact opnemen

Auteur: Kitty Clerc, geaccrediteerd trainer in EXIN Agile Scrum, APMG Scrum, APMG AgilePM®, APMG Change Management en PRINCE2®. Kitty heeft ervaring als (Agile) projectmanager en als begeleider van teams en projectmanagers bij de introductie van Agile werken. Zij werkte onder meer voor Philips, Raet, KPN, Getronics, KLM en bij diverse Nederlandse gemeenten.