Bestaande organisatiestructuur en bedrijfscultuur bij softwareontwikkeling

15 jaar Agile Scrum

Je bent de afgelopen 15 jaar waarschijnlijk net zo als iedereen overspoeld door agile, scrum en zelfsturend teams. Wellicht is de veelgehoorde uitdrukkingen “Een brug slaan tussen IT en de business” je ook niet ontgaan. Eigenlijk is dat een beetje een vreemde uitdrukking. Ik gebruik hem met de komst van Scrum zelf nooit meer, omdat er in die werkwijze vaststaat dat alle betrokkenen in het team aanwezig zijn, er is dan dus geen brug te slaan. Immers “Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team” en “Ensuring that the Product Backlog is visible, transparent, and clear to all” om maar twee passages aan te stippen.

Dus als ik een bedrijf deze uitdrukking hoor noemen in bijvoorbeeld een vacaturetekst dan denk wel eens: het lijkt het erop dat er iets is overgeslagen bij de adoptie.

Veelgehoorde feedback

Maar goed aan de andere kant hoor je anno 2023 je nog steeds feedback als “ik weet niet goed wat de developers doen”, “mijn verzoek zit er nog steeds niet in”, “ik wacht al maanden”, “de prioriteiten zijn mij onduidelijk”, ” hoe weten we welke feature waardevol zijn” enzovoorts. Wat wel aangeeft dat het proces niet helemaal loopt als het zou moeten lopen.

Een voorbeeld

Een deel van de verklaring hiervoor zit hem waarschijnlijk hierin: bedrijven zijn ingericht in afdelingen (silo’s) echter bedrijfsdoelen houden hier  geen rekening mee, die gaan dwars door structuur heen. En dus ook daaraan gelieerde IT of software-ontwikkelingen. Een voorbeeld: Stel een leasemaatschappij wil graag sneller een auto kunnen uitleveren. Dat is iets wat door allerlei afdelingen heen gaat; aanschaf, verzekering, RDW en noem zo maar op. Het is goed voor te stellen dat IT een veelomvattende rol heeft in zo’n totaalproces en dat verbeteringen en aanpassingen door alle afdelingen heen gaat.

Ook al wil je graag een praktisch iteratief mechanisme toepassen, het zegt niet hoe de organisatiestructuur, bedrijfscultuur en individueel gedrag daar op aansluit. Het zal daardoor wel komen dat het wel lukt dit in een IT “afdeling” up and running te krijgen, maar dat de rest van de organisatie meer moeite heeft aan te haken. Dus ook al zijn er goede bedoelingen, bij bedrijven met een minimale adoptie kun je dan terechtkomen in deze situatie: Een groep developers op de achtergrond, een Product Owner ergens in het midden en mopperende gebruikers die niet goed zijn aangehaakt.

Hoe staat het er bij jouw voor? Je zou gewoon eens een paar praktische vragen bij langs kunnen gaan:

Is iedereen betrokken?

Collega’s met inhoudelijke kennis, of diegene die veel baat hebben bij de uitkomst van te realiseren functies zouden vanzelfsprekend  betrokken moeten zijn. Dan hoef je later ook geen bruggen te slaan, alsof er iets gerepareerd moet worden, en krijg je ook geen wijzende vingers achteraf.

Zijn de bedrijfsdoelen helder?

Het is verstandig de bedrijfsdoelen helder in kaart te brengen, daar een structuur voor te gebruiken waardoor alle betrokkenen weten wat de beoogde waarde precies is. Dit kan in een simpele vorm als: hoe is feature 1 gekoppeld aan bedrijfsdoel x. Of werk aanvullend met waarde indicator als een feature omzet of klanttevredenheid beïnvloed. 

Eigenlijk komt het erop neer het model van een klassiek georganiseerde bedrijf zo te kantelen dat collega’s van verschillende afdelingen of silo’s kunnen werken aan gezamenlijke bedrijfsdoelen. Hier wordt vaak als end-to-end teams aan gerefereerd. 

Natuurlijk ontstaan daar al snel praktische vraagstukken: Hoeveel tijd is er nodig, en wanneer plannen we dat precies? Wie heeft er ownership? Werk dus allereerst aan deze praktische zaken om zo de randvoorwaarden op orde te hebben, immers als je zonder dit te doen aan IT projecten gaat werken zullen de resultaten tegenvallen. Kortom met betrokkenheid en de juiste kennis en kunde in het team zal uitvoeren van IT en software projecten en de daarmee samenvallende  bedrijfsdoelen een stuk soepeler lopen.

Wil je hier over doorpraten? Plan een kennismakingsgesprek of neem contact op.

Literatuur:
Inspired – Marty Cagan
The art of business value – Mark Schwartz

Comments are closed.
Stel uw vraag direct via WhatsApp