Van Scrum team naar agile organisatie (Deel 2)

(Ontwikkelingsfase 2: virtuele product teams over functie afdelingen heen)

Inleiding

In mijn blog over ‘Ontwikkelingsfase 1: Iteratief werken binnen projecten in de matrix’ heb ik toegelicht wat de voor en nadelen zijn van de beperkte toepassing van iteratief werken binnen projecten. Hierbij worden alle bestaande kaders, zoals de matrix organisatie en het project denken, gehandhaafd en zal men slechts een sub optimaal resultaat behalen bij het implementeren van agile, als men ervoor kiest om niet verder te gaan dan dat.

In dit deel gaan we een stapje verder, en creëren we virtuele product teams over de bestaande functionele afdelingen heen. Dit brengt weer een eigen set aan voor en nadelen met zich mee.

In deze blog ga ik ook even in op de relatie met het fluency model van Shore en Larsen, en licht ik de beperktheid van de fasen die ik behandel toe aan de hand van het 7S model van Peters en Waterman.

Hierna ter referentie de ontwikkelingsfasen nog een keer op een rij:

1. Iteratief werken binnen projecten in de matrix
2. Virtuele product teams over functie afdelingen heen
3. Fysieke product teams, al dan niet virtueel aangevuld met Ops
4. DevOps binnen IT
5. Bedrijfsbrede product of domein teams

Dit is de 2^e blog in een serie van 5, over de 2^e ontwikkelingsfase.

1^e ontwikkelingsfase is goed voor kweken van een juiste team cultuur

Het fluency model van James Shore en Diana Larsen (Zie figuur 1.) laat een andere view zien op het werken 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’.

Waar we met ontwikkelingsfase 2 aan willen werken is dus de ‘focus on value *’, door virtuele product teams samen te stellen. Dit zou moeten leiden tot een ‘skill shift’ voor die teams.

Skills die permanente product teams kunnen opbouwen boven project teams van tijdelijke aard zijn:

• Voorspelbaar worden op product release niveau
• Opbouwen referentiekader en domein kennis
• Continu verbeteren van de eigen processen en daarmee het verbeteren van de productiviteit
• Meer denken aan product kwaliteit dan aan project resultaten
• Business (product) gericht denken

Ontwikkelingsfase 2: virtuele product teams over functie afdelingen heen

Virtuele teams worden samengesteld over de functionele afdelingen heen. Deze teams zijn (business) product teams, verantwoordelijk voor de innovatie en het onderhoud van een business product van ‘front to back’. Deze teams kunnen worden aangevuld al met mensen uit operations, de zgn. DevOps teams. Vanzelfsprekend neemt de business ook deel aan dit team.

In de praktijk is het nog best moeilijk om de definitieve business producten te onderscheiden. Hoofd producten lukt nog wel, zoals bij een verzekeraar; 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 configuratie management en resource problematiek naar boven komen, die de problematiek van de project silo vervangt.

Toch is het de moeite waard om die problemen de kop te bieden. Het werken in product gerichte teams geeft medewerkers namelijk een voedingsbodem voor intrinsieke motivatie. Het product team 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). Zie hiertoe het volgende filmpje van Daniel Pink op youtube:

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 essen van Peters en Waterman. Met name leiderschapsstijl, training en coaching (skills) en de architectuur (systemen) zijn o.a. 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 product teams vormen een voedingsbodem voor intrinsieke motivatie
• Een permanent  product team kan domein kennis opbouwen.
• Een permanent product team kan een referentiekader opbouwen en daarmee voorspelbaar worden.
• Een permanent product team kan continu (in plaats van tijdelijk gedurende een project) aan productiviteitsverbetering werken.
• Een permanent product team denkt eerder aan de totaal 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 product teams 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ördinatie personeel vrijkomt, en vervangen kan worden door inzet van meer specialistisch direct personeel.
• Configuratie management issues zullen optreden wanneer meerdere product teams 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 of stap in hun agile maturity, waaronder een luchtvaart maatschappij, bank en technisch product leverancier. 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.

Qua rendements percentage krijgt deze stap een 20%.

In deel 3 van deze serie ga ik het hebben over Ontwikkelingsfase 3: Fysieke product teams, al dan niet virtueel aangevuld met Operations.