Er zijn tegenwoordig genoeg voorbeelden van bedrijven die snel succesvolle producten maken of diensten leveren. We zien ook dat ze dat vaak op een heel innovatieve manier doen. Het gevolg is dat we steeds meer denken dat wij ook moeten veranderen en moeten opereren zoals deze bedrijven om relevant te blijven. Het kopiëren van andermans manier van werken heeft echter beperkt effect. In de meeste gevallen kost dit juist veel inspanning, tijd en geld en zorgt dit voor veel afleiding van het behalen van de businessdoelen. Hoe zorg je er dan wel voor dat je op een gecontroleerde manier accelereert en de juiste producten maakt?

We weten dat Spotify een voor hen goed werkende manier van werken heeft (die continu evolueert) en horen dat er bij Amazon elke tien seconden een deployment wordt gedaan. We moeten sneller, geavanceerder en innovatiever worden. Hoewel het merendeel van de ondernemingen geen streamingdienst voor muziek of cloudinfrastructuur als producten levert, is er wel de tendens om die voorbeelden als blauwdruk te nemen en ons precies zo te organiseren op het gebied van HR, architectuur en techniek.  

Het doel als afleiding

We zijn in ons leven allemaal weleens geïnspireerd door een gebeurtenis of door een persoon. Of door de weg die ergens naartoe is afgelegd of het resultaat dat is bereikt. Dat is in principe prima zolang we ons maar blijven realiseren dat dit alles voortkomt uit de acties die zijn ondernomen. En dat dit niet iets is wat je een-op-een kunt kopiëren. 

Wie dezelfde voetbalschoenen koopt als Messi zal morgen niet spelen op zijn niveau en wie zijn levensstijl aanpast aan die van Keith Richards hoeft niet te verwachten dat dit een succes wordt. 

Dit lijken open deuren. Maar waarom verwachten we dan wel dat als we de acties van een willekeurige bank, overheidsinstantie of mkb-bedrijf kopiëren, we hetzelfde resultaat behalen? Waarom denken we dat het wel een goed idee is om de manier van werken van Spotify te kopiëren en te combineren met SAFe, naar Netflix te kijken voor onze IT-infrastructuur en net zo vaak te willen ‘deployen’ als Uber? Het DNA van deze organisatie is net zo uniek als elke andere organisatie op de wereld, met elk haar eigen unieke levensloop.

We vergeten dat onze voorbeelden een heel proces hebben doorgemaakt en op deze manier zijn gaan werken, zelfs hebben uitgevonden, omdat dat voor hen het beste werkte. Omdat dit iets was wat ze op dat moment nodig hadden; voor hun klanten, hun medewerkers en voor hun producten. En die weg naar succes kostte waarschijnlijk veel energie en er werden ongetwijfeld harde lessen geleerd. Dit soort investeringen resulteren vaak in een sterke basis. 

Suboptimalisatie als afleiding

Het gevolg van het tot doel stellen van omvangrijke generieke oplossingen is dat we ons focussen op de verkeerde zaken of op een verkeerd moment. Zo zien we continuous delivery als doel, Agile, scaling, DevOps en/of zelfsturende teams. En vaak doen we dit ook nog eens heel groots in de vorm van bedrijfsbrede transitieprogramma’s: ‘We gaan het vanaf nu helemaal anders doen!’ In deze gevallen zijn de doelen stuk voor stuk zaken die ons niet alleen afleiden maar zelfs vertragen. 

Ik zie in de praktijk te vaak dat we één onderwerp nemen en dit groots proberen te optimaliseren. Dit leidt tot suboptimalisatie. Een aantal voorbeelden.

Continuous delivery als afleiding

Een voorbeeld is het primair focussen op continuous delivery omdat dit nou eenmaal de trend is terwijl dit misschien maar één procent van de hele flow is van idee tot productie. De winst die je behaalt bij het versnellen van de delivery leidt uiteindelijk tot minimale tijdwinst. Financieel gezien verlies je erop. 

DevOps als afleiding 

Na Agile is het een trend om vanuit IT te transformeren naar een DevOps-organisatie terwijl zaken als strategie, business-cases en productvisies niet bekend zijn maar ook niet worden opgezocht. Vaak wordt er gesproken over ‘de business’ en ‘businessvalue leveren’ terwijl men eigenlijk geen flauw idee heeft wie of wat dat is. In veel gevallen is er nog steeds geen integratie met de business. Teams kunnen razendsnel user-stories naar de acceptatieserver brengen. Wat de waarde en het gewenste effect hiervan is, is niet bekend. De kans dat hier de juiste zaken worden gedaan is niet te voorspellen. 

Scrum als afleiding 

Hoeveel tijd en geld kunnen en willen we nog steken in het leren van een simpel framework? Sommige bedrijven zitten al in hun derde poging om ‘agile’ te worden. We zeggen dan dat het aan de bedrijven ligt want iets als Scrum werkt gewoon: one size fits all. Het houdt elkaar prachtig in stand. Hoewel Scrum niet de eindstatus hoeft te zijn van welk team dan ook is er een florerende industrie waarbij er mensen zijn die op een heel dogmatisch manier Scrum-teams coachen. Doe je alles wel letterlijk volgens het boekje? Indien niet, dan ben je niet ‘mature’ en moet de organisatie opnieuw getraind en gecoacht worden.

Keer op keer vergeten we te kijken naar de essentie van waarom we doen wat we doen en ligt de focus op de – uiteindelijk toch niet zo flexibele – door onszelf opgelegde regels.

Productontwikkeling als geheel

Er is goed en er is slecht nieuws. Het slechte nieuws is dat er geen magische one-size-fits-all-oplossing is die na aanschaf resulteert in het sneller maken van betere producten. Het goede nieuws is dat er voldoende patronen, technieken en tools zijn die elk kunnen bijdragen aan het doel. Het enige wat er nodig is om deze zaken aan elkaar te verbinden is om met een holistische blik naar productdevelopment te kijken.

Een holistische blik

Een holistische blik betekent in dit geval dat het proces van productontwikkeling gezien moet worden als een geheel en niet de som van de verschillende onderdelen. We kijken naar de flow waarbinnen we van idee tot user-feedback komen. Strategie, businesscases, agile werken, continuous delivery, DevOps, enzovoort. Het zijn stuk voor stuk slechts onderdelen van het geheel en moeten ook zo behandeld worden. Het zijn tevens stuk voor stuk zaken die niet een einddoel kunnen zijn maar helpen om doelen te bereiken.

Businessdoelen bepalen de oplossing

In de praktijk betekent deze holistische blik dat we vanuit de strategie business-cases kunnen definiëren die we vervolgens naar producten kunnen vertalen. Zowel de strategie als de businesscases zijn hypotheses en moeten dus zo snel mogelijk worden gevalideerd. 

Pas als duidelijk is wat er moet gebeuren, waarom dit zo is en hoe gemeten kan worden of de doelen gehaald worden, moeten we ons organiseren. Zo zorgen we ervoor dat architectuur, organisatiestructuur en de manier waarop gewerkt wordt altijd de businessgoals dienen in plaats van andersom. 

Is een lage time-to-market cruciaal? Dan pas focussen we op snelheid, meten en valideren we het. Is een lage mean-time-to-repair cruciaal? Dan pas investeren we wat meer in automatische deployments. Wat voor teams hebben we nodig om ideeën naar productie te kunnen brengen? Willen we met vaste Scrum-teams werken of met een pool van goede mensen? Hoe vaak willen we eigenlijk kunnen deployen? 

De antwoorden op al deze vragen hangen van heel veel factoren af. Voor ieder specifiek geval zijn ze niet simpel op te lossen door een ander te kopiëren of door een model te implementeren. Wat voor type product en/of dienstverlening leveren we? Wie zijn onze klanten nu? Wie willen we eigenlijk als klant? Hoe werkt onze licensing? Hoe gaat de markt zich gedragen de komende tijd? De antwoorden op dit soort vragen geven de richting van de oplossing aan.
 
Er is echter één fundamentele regel die bepaalt hoe de uiteindelijke oplossing en (inrichting van de) organisatie moeten zijn, en dat is dat de strategie en business-doelen leidend zijn.

Van het doel als afleiding naar het doel als focus

We zijn binnen de ict al met al behoorlijk trendgevoelig. Er zijn dan ook best veel succesverhalen van bedrijven die met hun innovatieve manier van werken tot de verbeelding spreken. De realiteit is dat wat voor een ander werkt niet voor jou hoeft te werken. 

Om sneller betere producten te kunnen maken moeten wellicht zaken veranderd worden, maar moeten we ook blijven veranderen. Een DevOps-transitie bijvoorbeeld kan nooit een doel op zich zijn. Een DevOps-organisatie zou zo moeten worden ingericht omdat dit de beste manier is om businessdoelen te verwezenlijken. 

Wat we moeten aanpassen en hoe dat uiteindelijk gedaan moet worden, moet juist blijken uit de unieke strategie en meetbare businessdoelen van de organisatie. We moeten van elke beslissing kunnen aangeven of die bijdraagt aan het behalen van de doelen en we doen dat het beste door meetbare experimenten te doen. Pas als we het proces van productontwikkeling zien als één geheel (één systeem) zullen we in staat zijn om op het juiste moment de juiste keuzes te maken. Pas dan zijn we zelf in controle en kunnen we vertrouwen op onze eigen innovatieve ideeën.

REAGEREN

Plaats je reactie
Je naam