Ik hoef u waarschijnlijk niet uit te leggen waarom organisaties transformeren naar de Agile manier van werken.

In vrijwel iedere organisatie is wendbaarheid (agility) geëvolueerd van optionele ambitie naar onvermijdelijke noodzaak. De verregaande adoptie van Scrum, de meest dominante Agile product development methode, heeft gezorgd voor de opkomst van Product Owners. De Product Owner, die als businessvertegenwoordiger de Voice of the Customer overbrengt, besluit voortdurend over fluctuerende prioriteiten om zo het team naar het gewenste product te leiden. Veel organisaties zien de aardverschuiving van project-denken naar product-denken als primaire uitdaging in de zoektocht naar agility. Maar dat is de verkeerde wedstrijd. De verschuiving moet zich richting op service-denken, niet product-denken.

De opkomst van DevOps

De DevOps beweging is enorm in opkomst. En daar is een reden voor. Organisaties die streven naar agility zijn op pijnlijke wijze geconfronteerd met de tekortkomingen van de beperkte toepassing van Agile denken op software ontwikkeling alleen. Potentially shippable products stapelden zich op voor de deur van beheer. Hetgeen resulteerde in lange doorlooptijden, ontevreden gebruikers en klanten en frustraties bij IT. Niet alleen start-ups en kleine bedrijven, maar recentelijk ook grote organisaties zijn gestart met de opbouw van DevOps competenties. Organisaties die deze nieuwe manier van werken hebben geadopteerd, vormen nu een magneet voor hoogopgeleide en innovatieve IT’ers. Een DevOps cultuur is een strategische asset geworden.

Van product naar service

Naast DevOps-specifieke technologie, gedrag en governance, brengt het omarmen van de DevOps-filosofie ook een andere kijk op eigenaarschap met zich mee. Een DevOps-mindset omvat het denken in non-functional requirements net zozeer als in functionele behoeften. Terwijl IT steeds meer business wordt, in plaats van slechts een technologieleverancier, bewegen organisaties zich van product-dominant logic naar service-dominant(externe link) logic. Deze transformatie is bijvoorbeeld zichtbaar in de banksector, waar de originele financiële producten zijn geëvolueerd naar mobiele betalingsdiensten of beleggingservices. Met service-dominant logic vertrouwen steeds meer organisaties op ontastbare middelen en relaties voor co-creatie van waarde. Een prachtig voorbeeld is KLM, die op actieve wijze social media inzet om waarde te co-creëren met en voor hun klanten.   

De Service Owner

Welnu, hoe logisch is het in een service-dominante wereld, om eigenaarschap op productniveau te blijven houden? Service Owners zijn hier veel effectiever. Service Owners hebben niet alleen aandacht voor klantbeleving, ofwel customer experience, en end-to-end effectiviteit, maar ook voor de volledige service lifecycle, onderhoudbaarheid en alle andere aspecten die de algehele waardelevering direct beïnvloeden.

Het leidt tot Definitions of Done die feitelijk Definitions of Use zijn, waar het eindresultaat daadwerkelijk bruikbaar is, in tegenstelling tot Definitions of Medium Rare. Te vaak zie ik dit laatste in Scrum implementaties, resulterend in Potentially Shippable Product Increments die geen enkele waarde leveren. Een Service Owner is niet alleen verantwoordelijk voor de realisatie van een eindresultaat (bijvoorbeeld een auto), maar ook het effectieve gebruik ervan (bijvoorbeeld autorijden). Dat vraagt om een veel bredere scope dan enkel het product.

DevOps in relatie tot gebruik [SlideShare]

ValOps(externe link) from Smalley_IT_Publications(externe link)

De eerste stap

De beweging van Product Owners naar Service Owners is niet puur semantisch. Natuurlijk ben ik me bewust van de werkelijke intentie van de rol van de Product Owner: om waardegedreven te zijn. En ik realiseer me dat slecht functionerende Service Owners net zo gebrekkig zijn als slechte Product Owners. Desalniettemin is, in het creëren van een collaboratieve, multidisciplinaire mindset in uw organisatie,  een fundamentele verschuiving nodig. Denken en handelen gebeurt in termen van services, in plaats van producten.

Als eerste stap om deze verandering in gang te zetten, is in mijn ervaring het introduceren van een beheer (ops) professional in alle Agile teams. Dit teamlid helpt de Product Owner te besluiten over functionele en non-functionele prioriteiten, voegt beheerkennis en –capaciteit toe aan het team (bijvoorbeeld monitoring, logging) en introduceert op die manier geleidelijk aan een service mindset in het team als geheel. Het is slechts een eerste stap in de adoptie van een DevOps filosofie en eigenaarschap op end-to-end services in uw organisatie. Als u hierin slaagt is de rest een fluitje van een cent. 

Wilt u een betere aansluiting van de beheerorganisatie op de ontwikkelorganisatie?

Laat het ons weten!