Ontwikkelingsfase 4: DevOps binnen IT
In mijn blog over 'Agile Ontwikkelingsfase 3: Fysieke product teams' heb ik toegelicht dat het efficiënter werkt als men de IT reorganiseert naar business domeinen of 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 ontwikkelmedewerkers. 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.
Dit is de 4e blog in een serie van 5, over de 4e ontwikkelingsfase.
- Iteratief werken binnen projecten in de matrix
- Virtuele product teams over functie afdelingen heen
- Fysieke product teams, al dan niet virtueel aangevuld met Ops
- DevOps binnen IT
- Bedrijfsbrede product of domein teams
Structuur- en cultuurverandering
4e ontwikkelingsfase is weer een organisatieverandering, maar leidt ook naar een 'Organizational Culture Shift'.
Het fluency model van James Shore en Diana Larsen (rechts) 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.
Bij ontwikkelingsfase 3 gaan we naar 'Deliver Value'. Dit resulteert in een organizational structure shift. We gaan namelijk product- of domeinafdelingen creëren binnen de IT-organisatie. Binnen deze afdelingen kunnen één of meerdere agile delivery teams, of vaste product teams aan (sub) producten werken.
Bij ontwikkelingsfase 4 gaan we naar 'Optimize Value'. Vaste DevOps teams meten hun productiviteit en worden steeds voorspelbaarder. Het toebehoren aan een vast team geeft ook een betere intrinsieke motivatie voor leveren van software van hoge kwaliteit. Voorspelbaarheid op releaseniveau wordt hier behaald, inclusief deployment door Ops. Met als resultaat een nog beter zicht op portfolioniveau van wanneer bepaalde zaken in de markt kunnen worden gezet. Maar ook, een beter inzicht op portfolioniveau hoe de resources in de vaste teams uit te nutten, en dus, om aan efficiënter portfoliomanagement 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').
DevOps binnen IT (samenvoegen van de gespiegelde organisatie)
De IT bestaat uit domeinafdelingen 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 productteams. 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.
Het figuur van Matt Watson, stackify.com, laat zien dat de hand-offs tussen development en operations wegvallen bij vaste devOps teams.
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 loketfuncties die een organisatie stroperig maken, en doorlooptijden voor deployment kunnen oprekken. Dat alles vergt veel indirecte coördinatiecapaciteit, die wellicht ingeruild zou kunnen worden voor directe ontwikkelcapaciteit.
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 formatiestop 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 schuingedrukt.
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 DevOpsteams 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 overDevOps 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: 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!
Ook interessant
Bekijk hier ons uitgebreide opleidingenaanbod op het gebied van Agile en lees hier meer Agile gerelateerde blogs.