Ontwikkelingsfase 5: Bedrijfsbrede product- of domeinafdelingen (terug naar de silo!)
In mijn blog over 'Ontwikkelingsfase 4: 'DevOps binnen IT' heb ik toegelicht wat de voor- en nadelen zijn van het samenvoegen van de development en operations afdelingen in zogenaamde domeinafdelingen. Voor zover deze stap opportuun is, zal deze weer meer rendement opleveren dan als men operations en development apart heeft gestructureerd.
In dit laatste deel gaan we met name kijken naar de eeuwigdurende beweging tussen centralisatie en decentralisatie van de IT en de drijfveren daar achter. Een nieuwe drijfveer om te decentraliseren lijkt nu het creëren van de ultieme agile organisatie. Een decentrale organisatie zou namelijk sneller kunnen reageren of zelfs anticiperen op veranderingen in haar omgeving. Maar zal dat ook echt kunnen werken? Ondanks dat ik nog geen organisatie ken, die zo is georganiseerd, ga ik een poging wagen om te onderbouwen waarom dit voor het creëren van een agile organisatie een goede laatste stap zou kunnen zijn.
In deze blog betrek ik de onderwerpen sociotechniek en holocracy.
Hierna ter referentie de ontwikkelingsfasen nog een keer op een rij:
- Iteratief werken binnen projecten in de matrix
- Virtuele productteams over functie afdelingen heen
- Fysieke productteams, al dan niet virtueel aangevuld met Ops
- DevOps binnen IT
- Bedrijfsbrede product- of domeinafdelingen
Dit is de 5e blog in een serie van 5, over de 5e agile volwassenheidsstap.
Sociotechniek, de jaren 50 herleven!
Uit wikipedia:
De sociotechniek is volgens Frans van Eijnatten een "toegepaste wetenschap die zich beijvert voor het verbeteren van het functioneren van zowel mens als organisatie door middel van aanpassing of fundamenteel herontwerp van werkprocessen en organisatie van de techniek of diensten én van de menselijke arbeidstaken"
Ulbo de Sitter is de grondlegger van de sociotechniek in Nederland en vat de kern van de sociotechniek samen als: "complexe taken in een eenvoudige organisatie in plaats van eenvoudige taken in een complexe organisatie". Dit in relatie tot een op dat moment aanwezige behoefte aan meer slagvaardigheid van organisatie naar de afzetmarkt en dienstverlening enerzijds. En anderzijds een betere aansluiting te krijgen naar de arbeidsmarkt. Beter en hoger opgeleide medewerkers zoeken interessantere banen dan op dat moment voorhanden waren.
Toepassing
Belangrijke bijdragen vanuit de sociotechniek aan de vormgeving van organisaties zijn de begrippen:
- hele taakgroepen (later: zelforganiserende teams!);
- stroomsgewijs produceren (lees: business domeingewijs, value streams!);
- productiestructuur en besturingsstructuur (Er wordt productgericht gewerkt i.p.v. projectmatig, hiertoe wordt de besturing tevens aangepast);
- integrale organisatievernieuwing, dat in Nederland haar oorsprong vindt bij de Stichting NKWO en de Adviesgroep KOERS (zie ook holocracy);
- kwaliteit van de organisatie, kwaliteit van de arbeid en kwaliteit van de arbeidsverhoudingen (zie ook de intrinsieke motivatoren van Dan Pink).
Hoezo agile werken in ' Value Streams'? Al vlak na de Tweede Wereldoorlog was er schijnbaar een stroming in Nederland die het aantrekkelijk maken van intelligent werk boven massaproductie promootte. In de daarop volgende jaren zijn bedrijven weer meer het traditionele efficiency denken gaan aanhangen (software ontwikkeling als lopende bandwerk). Dit versus de wisselwerking tussen mens en organisatie en met name flexibele inzet van mens en organisatie. Blijkbaar werd toen al voor het vereenvoudigen van de organisatie gepleit, en dat is precies hetgeen ik in dit laatste deel van de blogserie tevens wil promoten.
De eeuwigdurende golfbeweging van centralisatie en decentralisatie van de IT en business organisatiestructuur versus de architectuur (IT landschap)
Centralisatie en decentralisatie kun je op meerdere aspecten betrekken. In deze blog kijken we naar de organisatie structuur (vereenvoudigen analoog value streams) en het IT landschap.
We weten nog wel dat IT binnen de business afdelingen ontstond doordat medewerkers allerlei Excel-achtige applicaties produceerden om hun eigen taken te verlichten. Op den duur werd dit ononderhoudbaar, er was geen documentatie van, en het was foutgevoelig. Dat was onder andere reden om het IT landschap te centraliseren, naast het kostenaspect. Total cost of ownership dreef architecten ertoe om dezelfde applicatie voor alle business domeinen voor te stellen. Dit leidde tot horizontalisatie van het IT-landschap, daar waar de business domeinen er verticaal op staan.
Figuur 1. Waardestromen voor business producten staan haaks op het horizontale IT-landschap
Mark Paauwe stelt in zijn artikel in XR magazine: Centralisatie of decentralisatie - wanneer houdt dit nu eens op? dat de golfbeweging nooit zal stoppen. Tevens zegt hij dat trends in IT als SOA, web services en cloud maken dat de drijfveren voor centralisatie van het IT-landschap wegvallen. Daarom zou dit geen belemmering meer hoeven te zijn voor het decentraliseren van de organisatiestructuur voor innovatie en onderhoud per business domein of value stream. Dit heeft echter in de praktijk vele haken en ogen. Zie hiervoor de voor- en nadelen.
Voor het realiseren van een ultieme agile enterprise zie ik nu de trend naar de decentralisatie van de organisatiestructuur gebaseerd op business domeinen of value streams. Dit versus het reeds gecentraliseerde IT-landschap dat, door flexibilisering en terugdringen van technische schuld, de genoemde decentralisatie van de organisatiestructuur zal dienen te ondersteunen.
Figuur 2: IT is geïntegreerd met, en onderdeel van, de diverse business domeinen (Domein of value stream silo's)
Holocracy: de ultieme vorm van continue verbeteren!
Deze nieuwe vorm van besturen van een organisatie gaat ervanuit dat elke medewerker een sensor is voor problemen, verspilling en kansen. Via het verlenen van autonomie en mandaat voor verbeteren van processen en zelfs de organisatiestructuur, binnen gestelde kaders, aan medewerkers of teams, worden actoren gecreëerd, die daadwerkelijk verbeteringen door kunnen voeren. Dit alles dient wel een bepaald doel, een bedrijfsdoel. Dit sluit helemaal aan op het creëren van autonome zelf organiserende teams, het lager leggen van inhoudelijke besluitvorming in de organisatie, continue procesverbetering en waardecreatie als belangrijkste doel van het agile gedachtegoed. Het is wel een radicale andere manier van bedrijfsvoering, die maakt dat vele managementlagen overbodig worden, of zelfs het gehele management in traditionele zin overbodig maken.
Figuur 3. De drie uiteenlopende vormen van de organisatiestructuur bij een traditionele organisatie. Bron: holocracy.org
Figuur 4. Structuur past zich continu aan, en informele = formele organisatie. Bron: holocracy.org
Waarom de rollen in de organisatie niet steeds aanpassen aan de nieuwe rollen die ontstaan door een andere aanpak die wordt gekozen. Bij het kiezen voor een agile framework, zoals nu op grote schaal wordt gedaan, zul je rollen als Scrum masters en Product Managers en Owners zien ontstaan.
En waarom de structuur van de organisatie niet vereenvoudigen en richten op de waarde stromen van de business producten die men aan de eindklant wil leveren.
Net zoals je als een mammoettanker de samenstelling van vaste teams dient te herzien aan de toe of afname van het innovatiewerk (wat is de trend van je portfolio backlog?), dien je ook op regelmatige basis de organisatiestructuur te bezien aan de status van de life cycle (Star, Cach Cow, Problem child?) van je business producten.
Het agile principe 'At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly', dat staat voor continue procesverbetering, zou je dus ook kunnen projecteren op de organisatie. Continue organisatieverbetering is waar holocracy voor staat. Het lijkt de ultieme agile beweging op organisatievlak. Ik opteer voor continue verbetering door het hele bedrijf. Van zelfverbetering door een team per sprint, tot verbetering van de structuur door het management bijvoorbeeld eens per half jaar, onder invloed van de impulsen van de medewerkers, die hiervoor als de sensoren dienen!
Voor- en nadelen van ontwikkelingsfase 5
Voordelen:
- Het business domein heeft zijn eigen voortbrenging en ondersteuningsteams, die kennis hebben van het domein.
- De organisatie is in staat zichzelf aan te passen aan wat de business vraagt aan innovatie en ontwikkeling dan wel afstoten van business producten.
- Elk business domein kan eigen eisen stellen aan de release treinen die innovatie en onderhoud van hun business producten ondersteunen, denk aan focus op time-to-market versus kwaliteit.
- Management heeft slechts één doel, optimaliseren van de waardecreatie binnen het domein. Geen afgeleide doelen meer per afdeling / eiland.
Nadelen:
- Vergt een gezonde balans tussen flexibiliteit van het IT-landschap en de mate van technische en functionele schuld (een gezond IT-vermogen), hetgeen bij de meeste bedrijven ver te zoeken is.
- Vergt werken met feature teams hetgeen weer een omslag in configuratie management betekent, HR problematiek opwerpt, en voornoemd gezond IT-vermogen vergt.
- Vergt een management dat tevens geheel agile denkt en acteert, en aan continue organisatie verbetering doet gebaseerd op de product life cycle status.
- Complexiteit en omvang van afdelingen (span of control) en IT-landschap (veel interfaces) kunnen vereenvoudiging van structuur en flexibilisering van het IT-landschap moeizaam tot nagenoeg onmogelijk maken.
- Managers moeten in staat zijn en empowered worden om zichzelf overbodig te maken, terwijl management juist is gericht op het 'managen' en dus behouden van een status quo.
Qua rendementspercentage krijgt deze stap een 200%.
Note: deze blogserie had focus op de organisatie structuur bij de transitie naar een agile enterprise. Zoals eerder genoemd komen er veel meer facetten kijken bij deze transities, zoals cultuur, architectuur, besturing, HR en financiën.
Het definiëren van agile volwassenheidsniveaus zal dan ook niet slechts van deze focus op structuur af mogen hangen, en zal alle genoemde facetten mee dienen te nemen. In een volgend artikel neem ik jullie mee naar een agile volwassenheidsmodel, zoals dit samen met een klantorganisatie is ontwikkeld, en dat hierop aansluit.
Bijlage
Figuur 5: Het fluency model van James Shore en Diana Larsen, geprojecteerd op de beschreven volwassenheids niveaus van deze blog serie.
Ook interessant
Bekijk hier ons uitgebreide opleidingenaanbod op het gebied van Agile en lees hier meer Agile gerelateerde blogs.