Virtuele productteams over functionele afdelingen heen
In mijn blog Ontwikkelingsfase 1: Iteratief werken binnen projecten in de matrix heb ik toegelicht wat de voor- en nadelen zijn van de toepassing van iteratief werken binnen projecten. Hierbij worden alle bestaande kaders zoals de matrixorganisatie en het projectdenken gehandhaafd. Het resultaat is weliswaar positief, maar toch suboptimaal.
In dit deel gaan we een stapje verder:
- Fase 1: Iteratief werken binnen projecten in de matrix
- Fase 2: Virtuele productteams over functionele afdelingen heen
- Fase 3: Fysieke productteams, al dan niet virtueel aangevuld met Ops
- Fase 4: DevOps binnen IT
- Fase 5: Bedrijfsbrede product- of domeinteams
Het fluency model van James Shore en Diana Larsen werpt een andere blik op het toewerken naar een complete agile organisatie. Je zou kunnen zeggen dat het iteratief werken in projecten vergelijkbaar is met de ‘Start: Building code’ van dit model, dat leidt tot een ’team culture shift’.
De 1e ontwikkelingsfase is goed voor kweken van een juiste teamcultuur. Waar we met ontwikkelingsfase 2 aan willen werken is dus de ‘focus on value’, door virtuele productteams samen te stellen. Dit zou moeten leiden tot een ‘skill shift’ voor die teams. Extra skills die permanente productteams opbouwen ten opzichte van projectteams van tijdelijke aard:
- Voorspelbaar worden op productreleaseniveau
- Opbouwen referentiekader en domeinkennis
- Continu verbeteren van de eigen processen en daarmee het verbeteren van de productiviteit
- Meer denken aan productkwaliteit dan aan projectresultaten
- Business (product)gericht denken
Ontwikkelingsfase 2: virtuele productteams over functionele afdelingen heen
Virtuele teams worden samengesteld over de functionele afdelingen heen. Deze (business) productteams zijn verantwoordelijk voor de totale innovatie en het onderhoud van een businessproduct. Deze teams kunnen worden aangevuld met mensen uit operations, de zogenaamde DevOps teams. Vanzelfsprekend neemt de business ook hieraan deel.
In de praktijk is het nog best moeilijk om de definitieve business producten te onderscheiden. Hoofdproducten lukt nog wel, bij een verzekeraar zijn die bijvoorbeeld Pensioenen, Schade en Leven. Maar zodra er verder onderverdeeld moet worden komen er discussies op gang.
Deze discussies worden nog eens verder bemoeilijkt doordat het vaak lastig is om teams in een keten van applicaties ‘dedicated’ op zo een sub-business-product te zetten. Teams in de ‘front’, ‘mid’ en ‘back-offices’ zijn vaak verantwoordelijk voor een hele instantie van een applicatie die alle business domeinen afdekt. Hier zie je weer configuratiemanagement en resourceproblematiek naar boven komen, die de problematiek van de projectsilo vervangt.
Toch is het de moeite waard om die problemen het hoofd te bieden. Het werken in productgerichte teams geeft medewerkers namelijk een voedingsbodem voor intrinsieke motivatie. Het productteam is zelf organiserend en sturend (Autonomy), werkt aan continue procesverbetering (Mastery) en het werkt aan de continue verbetering en innovatie van een specifiek business product (Purpose). Het filmpje van Daniel Pink op youtube legt dat mooi uit.
De beperking van de besproken ontwikkelingsfasen
De ontwikkelingsfasen die in deze serie blogs worden beschreven gaan uit van het veranderen (al dan niet virtueel) van de structuur van de organisatie. Het is niet gezegd dat je er daarmee bent. Men dient ook te werken aan de overige 6 S-en van Peters en Waterman. Met name leiderschapsstijl, training en coaching (skills) en de architectuur (systemen) zijn zaken waar actief aan gewerkt dient te worden. De cultuur (shared values) zal hiermee langzaam mee veranderen.
Voor en nadelen van ontwikkelingsfase 2
Voordelen:
- Permanente productteams vormen een voedingsbodem voor intrinsieke motivatie.
- Een permanent productteam kan domeinkennis opbouwen.
- Een permanent productteam kan een referentiekader opbouwen en daarmee voorspelbaar worden.
- Een permanent productteam kan continu (in plaats van tijdelijk gedurende een project) aan productiviteitsverbetering werken.
- Een permanent productteam denkt eerder aan de totale kwaliteit van een product, omdat het daarvoor verantwoordelijk is en niet slechts voor de scope van een tijdelijk project.
- Wielen hoeven niet telkens uitgevonden te worden als er weer een project voor innovatie op hetzelfde product wordt opgestart.
- Testomgevingen worden permanent in de lucht gehouden versus het af laten breken en op laten bouwen per project.
Nadelen:
- Iedereen in het team heeft meerdere bazen (lijn manager, product team manager, architect, Product Owner) en dus kan er sprake zijn van verstrengeling van belangen.
- Bij een pilot met een paar virtuele productteams zal resourcing een probleem vormen. Specialisten zijn soms schaars en management is niet geneigd om extra personeel aan te nemen om permanente teams te bemensen. Wat zij zich dan wel dienen te realiseren is dat bij opschaling veel indirect coördinatiepersoneel vrijkomt en vervangen kan worden door inzet van meer specialistisch direct personeel.
- Configuratiemanagement-issues zullen optreden wanneer meerdere productteams op dezelfde applicatielaag aanpassingen willen doen voor ‘hun’ business product.
- Bij grote IT-landschappen zullen issues ontstaan rondom inrichting van component of feature teams en de inhoudelijke coordinatie hierover die opgelost dienen te worden.
Enkele organisaties waar ik kom zitten in deze fase in hun agile maturity, waaronder een luchtvaartmaatschappij, een bank en een technisch productleverancier. Het kan een keuze zijn van management om niet verder te gaan dan deze fase 2 met hun agile ambitie. Dit levert al meer rendement op dan fase 1, maar er kan nog meer uitgehaald worden.
Deze fase kent typisch een rendementsstijging van 20%.
In deel 3 van deze serie ga ik het hebben over Ontwikkelingsfase 3: Fysieke productteams, al dan niet virtueel aangevuld met Operations.
Ook interessant
Bekijk hier ons uitgebreide opleidingenaanbod op het gebied van Agile en lees hier meer Agile gerelateerde blogs.