Van Scrum team naar agile organisatie (Deel 3)

(Ontwikkelingsfase 3: fysieke product of domein afdelingen, al dan niet aangevuld met Operations)

Inleiding

In mijn blog over ‘Ontwikkelingsfase 2: virtuele product teams over functie afdelingen heen’ heb ik toegelicht wat de voor en nadelen zijn van het samenstellen van vaste teams vanuit verschillende afdelingen. Hierbij wordt al grotendeels afscheid genomen van het project denken, en gaat men meer product gericht werken. Doordat medewerkers nog verschillende bazen hebben in deze situatie is er op het resourcing vlak nog veel ruis. Hierdoor is het rendement wel hoger dan bij fase 1, maar beter is het om te migreren naar vaste product teams. Dit vergt echter een organisatie verandering, en dat is sneller gezegd dan gedaan.

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 3^e blog in een serie van 5, over de 3^e ontwikkelingsfase.

3^e ontwikkelingsfase leidt tot een organisatie verandering

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’.

Ontwikkelingsfase 2 werkt aan de ‘focus on value *’, door virtuele product teams samen te stellen. Dit zou moeten leiden tot een ‘skill shift’ voor die teams.

Figuur 1: Het fluency model van James Shore en Diana Larsen

Bij ontwikkelingsfase 3 gaan we naar ‘ Deliver Value’. Dit resulteert in een organizational structure shift. We gaan namelijk product of domein afdelingen creëren binnen de IT organisatie. Binnen deze product of domein afdelingen kunnen 1 of meerdere agile delivery teams aan (sub) producten werken.

Omdat de teams in de vorige fase aan hun skills hebben gewerkt in de virtuele product team formatie, is het nu tijd om de vruchten daarvan te plukken. Met die opgebouwde skills (zie blog nummer 2) kan men voorspelbaar zijn, rust hebben, en aan continue procesverbetering doen. Binnen die rust kan men werken aan een snellere time to market (toename productiviteit) en een betere kwaliteit van het product (wegwerken technische schuld en verbeteren automatisering door continue procesverbetering). Dit resulteert in oplevering van meer value voor de organisatie.

Dus, vorm de virtuele teams om naar vaste teams / afdelingen, die verantwoordelijk worden gemaakt voor een voorspelbare delivery, samen met de kwaliteit van het product.

Ontwikkelingsfase 3: fysieke product of domein afdelingen, al dan niet aangevuld met Ops

Een model dat goed als referentiemodel gehanteerd kan worden om het werken in vaste product teams vorm te geven is het ‘Scaled Agile Framework®’ of ‘SAFe™’ van Dean Leffingwell.

Het ‘Scaled Agile Framework®’ of ‘SAFe™’ van Dean Leffingwell

Het Portfolio niveau van dit model vertegenwoordigt de business kant van de organisatie. Het programma niveau kan het niveau zijn van een fysieke product- of domein afdeling. Het team niveau vertegenwoordigt de agile delivery teams, opgedeeld in verantwoordelijkheid voor (sub) producten binnen de product- of domein afdeling.

Wat je ziet in dit model is dat de flow van requirements, van wens tot in productie name, wordt ondersteund door 3 niveaus met backlogs. Deze bevatten van grof naar fijn: Epics (overstijgen releases), Features (passen in releases) en User Stories (passen in iteraties).

Ook zie je hier de combinatie van de inzet van lean en agile principes. De teams werken iteratief, terwijl de flow van de requirements met behulp van lean principes wordt geoptimaliseerd.

Je zou dit model al kunnen implementeren gebruik makend van virtuele teams. Maar de kans dat die teams stabiel blijven, wat essentieel is voor dit model, is geringer dan dat de resourcing verantwoordelijkheid is van 1 afdelingsmanager, die verantwoording draagt voor de kwaliteit van een product.

Voor en nadelen van Agile ontwikkelingsfase 3:

Voordelen:

• Reductie van overhead aan management-, plannings- aansturings- en loket capaciteit.
• Reductie van inspanning voor project gerelateerde documentatie (Projectplannen, Requirements management plannen, testplannen etc. hoeven of niet gemaakt te worden, of slechts bijgehouden te worden, en niet per project vervaardigd van scratch).
• Reductie van inspanning voor domein gerelateerde documentatie (Vision Documents, Domain Models, Use Case Models, SAD’s, Supplementary Specs, Designs werden vaak per project opgetuigd, en aan het einde weer weggegooid, nu hoeven ze per product alleen maar onderhouden te worden).  Nu zullen sommige agilisten zeggen hoezo documentatie bij agile? Ik ben ervan overtuigd dat goede domein en ontwerp documentatie key is voor bedrijf kritische producten. Daarvoor vormen RUP artifacts een goede bodem. Wil je een tijdelijke campagne site bouwen?, dan kun je meeste documentatie achterwege laten idd.
• 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.
• Eén manager verantwoordelijk voor HR van de product teams geeft duidelijkheid en een gevoel van ergens bij horen .
• Er zal minder ‘getrokken worden’ aan, en ‘geschoven worden’ met resources, meer als een mammoet tanker dan per week je effort verdelen over meerdere projecten. Dus, bemensing product teams op lange termijn wel afstemmen op het opdrogen dan wel aanwassen van de portfolio backlog.

Nadelen:

• Bij vaste product teams of afdelingen 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.
• Synchroniseren van backlogs om de tijdigheid van markt releases vast te kunnen stellen die over product teams, of zelfs product afdelingen, heen stijgen, zal intensief dienen te zijn. Deze discipline is zeer moeilijk op te brengen.

Op dit moment ben ik mede verantwoordelijk binnen een klantorganisatie voor het inrichten van het programma en team niveau van dit referentiemodel. En ik zeg referentiemodel, want iedere klantsituatie is specifiek. Zo gebruik ik op teamniveau geen User Stories als eenheid voor de team backlog, maar omdat men al werkt met Use Case Modellen, zet ik Use Case Slices in, en implementeer ik daarmee ook Use Case 2.0, van Ivar Jacobson. En omdat deze organisatie kwaliteitsproducten maakt, in te zetten door partners, blijft men gebruik maken van de RUP documentatie standaarden voor met name vastlegging van eisen en ontwerpdocumentatie.

Deze IT organisatie is inderdaad gereorganiseerd vanuit functie afdelingen naar fysieke product- of domein afdelingen. Binnen deze productafdelingen is 1 manager zowel verantwoordelijk voor de HR van de medewerkers, de indeling in product teams, en last but not least, de kwaliteit van de producten zoals belegd binnen zijn afdeling!

Dit geeft een geheel andere dynamiek. Mensen horen ergens bij ineens (zie intrinsieke motivator ‘Purpose’ uit deel 2), krijgen als team ruimte om te werken aan kwaliteit (Autonomy) én ruimte voor procesverbetering (Mastery).

Het levert ook de nodige problemen op. Zo is de cultuur nog helemaal gericht op project denken, en ook de governance is navenant ingericht. Zo is er geen cultuur van verbeteren, omdat men gewend is dat projecten altijd onder tijdsdruk staan, en er nooit aan verbetering gewerkt kan worden. Zo ontstaan er resourcing problemen omdat de indeling in vaste teams die verantwoordelijk zijn voor onderhoud én innovatie van een product, een hele andere is dan meerdere project teams op innovatie, en één onderhoudsteam voor één product. En zo zijn er nog wel meer. Wat te denken van de volwassenheid van de organisatie, benodigde competentie van medewerkers, en de aansluiting op de processen aan de business kant.

Hieruit blijkt wel dat dit een enorme stap is voor een organisatie. Maar als ik naar de trend kijk dat technische schuld alleen maar oploopt bij IT organisaties door het hele project-denken, terwijl de vraag naar snellere ‘Time to market’ alleen maar toeneemt, wordt dit misschien voor vele IT organisaties een noodzakelijke stap!

Qua rendements percentage krijgt deze stap een 50% (zie ook de voordelen die klanten al ondervonden na implementatie van het Scaled Agile Framework, in de presentatie te downloaden op www.scaledagileframework.com).

In deel 4 van deze serie ga ik het hebben over Agile ontwikkelingsfase 4: DevOps binnen IT.