Veel organisaties die Agile werken, komen ermee in aanraking: het starten van nieuwe Agile teams. In een eerdere blog hebben we al stilgestaan bij enkele aspecten, die van belang zijn bij het samenstellen van Agile teams. Maar wat wordt precies het aandachtsgebied van het nieuwe team? Welk probleem gaan zij oplossen en wat worden daarmee hun product en hun scope?
Valkuilen
Wat we in de praktijk regelmatig zien, is dat een nieuw Agile team start met de mensen op een afdeling, ‘die er al van zijn’. In feite gaan de mensen dan in teamverband de werkzaamheden, die ze al deden, meer Agile uitvoeren. Mogelijk krijgt het team een Product Owner en/of een Scrum Master of er wordt gestart met stand-ups, een Kanban bord en evaluaties / retrospectives. In deze aanpak liggen diverse valkuilen verborgen.
In feite krijg je zo geen multidisciplinair, maar een monodisciplinair team. De mensen die met elkaar op een afdeling werken, doen vaak grotendeels hetzelfde werk. Het toevoegen van één of twee andere disciplines (een informatie analist of een Agile coach) maakt het team niet echt multidisciplinair.
Daarnaast leidt het introduceren en gebruiken van Agile artefacts en evenementen niet automatisch tot een team met een Agile mindset.
De valkuil waar we hier echter dieper op in willen gaan is nog een andere. Het nieuwe team heeft meestal nog steeds te maken met een onduidelijk product (of juist: producten) en vaak veel interne klanten, binnen verschillende onderdelen van de eigen organisatie.
Van klant-leverancier ketens naar Agile teamsamenwerking
Traditioneel zijn er vaak verschillende afdelingen betrokken bij de levering van een product of dienst aan een eindklant van de organisatie. Met een eindklant bedoelen we hier de klant aan het eind van de keten. Het is de gebruiker van het product of de dienst. Dit kan een interne of externe klant zijn. Bijvoorbeeld een medewerker is de eindklant voor een ‘self-service’ portaal. Of een student is de eindklant voor een inschrijfproces bij een onderwijsinstelling. De afdelingen leveren achtereenvolgens, in een keten, hun bijdrage en werken met elkaar in een soort ‘klant-leverancier’ relatie. Communicatie en coördinatie van het werk verloopt via e-mails en workflows.
De kracht van Agile werken is juist, dat de benodigde afdelingen allemaal vertegenwoordigd zijn in het Agile team. Het team is verantwoordelijk voor de levering van het product of de dienst aan de eindklant en met elkaar dekken de teamleden de volledige voortbrengingsketen af.
Product gebaseerde teams
Agile teams moeten dus product gebaseerd zijn. Dat wil zeggen dat er een product gekozen is, dat waarde heeft voor de eindklant. ‘Product’ kan hier zowel een fysiek product als een dienst zijn, zoals het hiervoor genoemde inschrijfproces bij een onderwijsinstelling of een vergunningaanvraagproces bij een gemeente. Op basis van de keuze voor het product, kan vanuit de eindklant nagedacht worden over de waarde en de complete beleving van het product, en de beste manier van leveren. (Tip: Gebruik hiervoor Customer Journeys!). Deze complete beleving is een mooi uitgangspunt voor het bepalen van de scope van het te leveren product.
Starten met de Product Owner
In praktijk zien we vaak dat het Agile team al is samengesteld en dat er alleen nog gezocht wordt naar een Product Owner. Veel beter is om het Agile team juist te starten met het identificeren van de Product Owner. Een goede Product Owner start als een soort ondernemer met een heldere visie op het te realiseren product. Op basis daarvan wordt duidelijk wat nodig is om het product te realiseren. Deze visie moet leidend zijn bij het bepalen van de scope en daarmee de gewenste samenstelling van het team.
Van product naar scope
Vóórdat een Agile team daadwerkelijk begint, moeten de Product Owner en de rest van het team zichzelf een paar belangrijke checkvragen stellen. Hebben we als team wel de juiste zaken in scope om de eindklant te bedienen? En kunnen we als team continu, iteratie na iteratie, verbeteringen aan het product realiseren? Of missen we stappen in de keten die door anderen moeten worden uitgevoerd? In het laatste geval is het team mogelijk té afhankelijk van anderen en is de scope niet goed bepaald. De kans is dan groot dat er nog steeds veel afstemming nodig is vanuit het team in de traditionele ‘klant-leverancier’ relatie met anderen.
Rol van architectuur
Een slimme manier om met de scope en teamsamenstelling om te gaan, is het betrekken van architecten. Niet voor niets introduceren de verschillende methoden om Agile op te schalen architectuur en portfolio management. Hiermee wordt coördinatie en prioritering over Agile teams helder gemaakt. Zo kunnen onnodige overlap en conflicten in scope tussen verschillende teams worden voorkomen. Door een doordachte afbakening op het proces- en IT-landschap van de organisatie kunnen teams samengesteld worden met minimale afhankelijkheid van andere teams. Door overblijvende ‘interfaces’ tussen teams goed te organiseren, kunnen teams maximaal onafhankelijk van elkaar aan deelproducten werken. Deelproducten, die nog steeds in het totaalproduct blijven passen.
Ook als de voortbrenging van het product een te lange keten nodig heeft om in een team van circa 7 teamleden te passen, kan architectuur de Product Owner helpen met het aanbrengen van de meest logische ‘knip’ in de keten en tussen teams.
Dus teamsamenstelling en scope van Agile teams … op basis van product visie en architectuur!
Wil je weten wat fit4agile kan betekenen voor jullie, klik dan hier voor meer informatie of neem contact op.