Van Scrum team naar agile organisatie (Deel 4)

(Ontwikkelingsfase 4: DevOps binnen IT

Inleiding

In mijn blog over ‘Agile Ontwikkelingsfase 3: Fysieke product teams’ heb ik toegelicht dat het efficiënter werkt als men de IT reorganiseert naar de business domeinen, dan wel business producten. Deze structuurwijziging ondersteunt implementatie van het Scaled Agile Framework optimaal, en rendementen van 50% zijn bij adequate implementatie makkelijk haalbaar. De volgende stap is een stap die volgens mij niet veel grote organisaties kunnen maken, en is weer een structuurwijziging. Namelijk: het fysiek toevoegen van operations medewerkers aan de afdeling met ontwikkel medewerkers. Dit levert in vele organisaties problemen op die in deze blog worden besproken. Vele organisaties zullen dan ook stoppen bij agile ontwikkelingsfase 3, en ik raad elke IT organisatie ook aan om daarnaar te streven. De meeste IT organisaties zijn het punt al voorbij waarbij ze nog de luxe hebben om te zeggen “we blijven op de bestaande voet doorwerken”. De technische schuld neemt almaar toe en kan onhoudbare proporties aannemen, terwijl de vraag naar snellere ‘Time to Market’ verder toeneemt.

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

4^e ontwikkelingsfase is weer een organisatie verandering, maar leidt ook naar een ‘Organizational Culture Shift’.

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, of vaste product teams aan (sub) producten werken.

Bij ontwikkelingsfase 4 gaan we naar ‘Optimize Value’. Vaste dev Ops teams meten hun productiviteit en worden steeds voorspelbaarder. Het toebehoren aan een vast team geeft ook een betere intrinsieke motivatie voor leveren van kwaliteit software. Voorspelbaarheid op release niveau wordt hier behaald, inclusief deployment door Ops.  Met als resultaat een nog beter zicht op portfolio niveau van wanneer bepaalde zaken in de markt kunnen worden gezet. Maar ook, een beter inzicht op portfolio niveau hoe de resources in de vaste teams uit te nutten, en dus, om aan efficiënter portfolio management te kunnen doen. Wat doen we wel, wat doen we niet, wat levert ons als bedrijf de meeste business waarde op.

Feitelijk spreken we hier over een kanteling van een complexe organisatie met eenvoudige taken naar een eenvoudige organisatie met complexe taken. Het zijn nu juist die complexe taken, gepaard met een toenemende verantwoordelijkheid op de werkvloer, die de kwaliteit van arbeid doen toenemen. Inderdaad een cultuuromslag! Dit vergt niet alleen iets van de medewerkers, maar zeker ook van de managers (Kuipers, van Amelsfoort & Kramer (2010): ‘Het nieuwe organiseren’).

Ontwikkelingsfase 4: DevOps binnen IT (samenvoegen van de gespiegelde organisatie)

Figuur 2. De IT bestaat uit domein afdelingen waarbinnen vaste DevOps teams verantwoordelijk zijn voor ontwikkeling, onderhoud én operatie van (sub) business producten.

Het is natuurlijk al mogelijk, en ook benoemd in agile ontwikkelingsfase 3, om virtueel mensen van operations toe te voegen aan, of aan te laten sluiten bij, vaste product teams. In fase 4 gaan we een stap verder en brengen we de operations mensen onder dezelfde management en HR verantwoordelijkheid als de development medewerkers. In beide gevallen kunnen hand-offs worden geëlimineerd, zoals ook onder ‘Optimize Value’ te lezen valt in het model van Shore en Larsen. Het elimineren van deze hand-offs wordt mooi geïllustreerd in de figuur hieronder van Matt Watson. Het extra voordeel dat samenbrengen onder  één management brengt is dat men slechts één baas heeft, die belang heeft bij een optimaal proces. Wat hierbij kan botsen is dat Development en Operations vaak verschillende belangen hebben. Maar uiteindelijk draait het allemaal om het snel en kwalitatief leveren van Business Waarde.

Figuur 3. Van Matt Watson, stackify.com, laat zien dat de hand-offs tussen development en operations wegvallen bij vaste devOps teams.

Figuur 4. Een voorbeeld operations afdeling van een groot bedrijf.

Operations kan gespiegeld zijn met development qua organisatie in eerste instantie, maar kan ook totaal anders zijn georganiseerd. Bovenstaand voorbeeld van een operations afdeling van een groot bedrijf geeft aan uit hoeveel subafdelingen het kan bestaan, met elk hun eigen specialisme en loket. En het zijn in het bijzonder die loket functies die een organisatie stroperig maken, en doorlooptijden voor deployment kunnen oprekken. Dat alles vergt veel indirecte coördinatie capaciteit, die wellicht ingeruild zou kunnen worden voor directe ontwikkel capaciteit.

Maar dit brengt veel uitdagingen met zich mee. Want je kunt je voorstellen dat als je een gespecialiseerde afdeling van 5 personen wil gaan verdelen over 30 product teams, dat dit niet gaat. Ook zullen producten vaak van veel meer platformen gebruikmaken dan slechts één. Hoe ga je dan om met het formeren van DevOps teams? Vaak is er formatie stop op het aannemen van nieuw personeel. En je kunt specialisten, die toch al moeilijk te vinden zijn voor sommige platformen, niet opsplitsen.

Kortom, er is niet één oplossing te geven voor deze stap in de ontwikkeling. Voor kleine organisaties zal het makkelijker zijn om vaste DevOps team te formeren, voor grotere organisaties levert dit vooralsnog veel uitdagingen op. Beginnen met continu betrekken van de Operations medewerkers bij de vaste product teams in agile ontwikkelingsfase 3, is een goede start. Van daaruit kan men gaan inventariseren hoe men de loketten kan verminderen (reductie indirect personeel), en in aansluiting op de Development afdelingen de Operations afdeling beter kan laten aansluiten op het (business) product gericht werken, in plaats van alleen maar denken in eigen specialisme. Hierbij dienen combinaties van belangen zoals snellere ‘Time to Market’, en ‘Operational Excellence’, maar ook wederom ‘intrinsieke motivatoren’, tegen elkaar afgewogen te worden.

Voor en nadelen van Agile ontwikkelingsfase 4:

Voor ontwikkelingsfase 4 gelden dezelfde voor- en nadelen als ontwikkelingsfase 3. De voor- en nadelen die specifiek voor fase 4 zijn te benoemen, bovenop die van fase 3, zijn in rood gemarkeerd.

Voordelen:

• Directe betrokkenheid van operations medewerkers bij het agile traject van requirement tot in-productiename.
• DevOps teams houden veel beter rekening met de eisen waaraan het product dient te voldoen voor deployment.
• 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 ontwerpdocumentatie 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 DevOps teams vormen een voedingsbodem voor intrinsieke motivatie.
• Een permanent  DevOps kan domein kennis opbouwen.
• Een permanent DevOps team kan een referentiekader opbouwen en daarmee voorspelbaar worden.
• Een permanent DevOps team kan continu (in plaats van tijdelijk gedurende een project) aan productiviteitsverbetering werken.
• Een permanent DevOps 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 DevOps 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 DevOps teams op lange termijn wel afstemmen op het opdrogen dan wel aanwassen van de portfolio backlog.

Nadelen:

• Bij grote IT afdelingen zal het moeilijk zijn de operations medewerkers te verdelen over fysieke DevOps teams, dit vergt verregaande reorganisatie, omscholing, acquisitie en herbeleggen van verantwoordelijkheden. Een kanteling van een verticaal georganiseerde organisatie naar een horizontaal georganiseerde organisatie.
• Er zal beter nagedacht dienen te worden over automated deployment, dit vergt vaak investering.
• Bij vaste DevOps 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 DevOps 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 DevOps teams, of zelfs product afdelingen, heen stijgen, zal intensief dienen te zijn. Deze discipline is zeer moeilijk op te brengen.

Qua rendements percentage krijgt deze stap een 100%

In deel 5 van deze serie ga ik het hebben over Agile ontwikkelingsfase 5: Bedrijfsbrede product of domein afdelingen: terug naar decentralisatie en de silo’s!.