Business en IT in één release train? Het is eindelijk expliciet in SAFe 5.0!

Inleiding

Ik ben erg blij met de recentste versie van het Scaled Agile Framework. Deze 5.0 versie gaat waarschijnlijk in januari 2020 live. Deze versie zegt namelijk nu expliciet wat vanaf het begin al de bedoeling was, maar nooit expliciet is gemaakt. Een waardestroom bevat alle medewerkers ongeacht afdeling die gezamenlijk de business oplossingen voor die waardestroom kunnen realiseren en laten evolueren.

Ik heb echter het concept van business en staven opnemen in release trains al vaker voorgesteld in organisaties en stip het ook aan in mijn blog: ‘Functiehuizen? Slopen!’: https://newgility.eu/2018/07/30/functiehuizen-slopen

Niet dat organisaties er happig op zijn. Managers van de uni-disciplinaire silo’s als staven hebben liever hun medewerkers bij elkaar op 1 verdieping. Maar met staven hoort het zo te gaan als met alle andere disciplines die voorheen toebehoorden aan een functionele silo als bijvoorbeeld de afdeling test. Testers zijn nu opgenomen in multidisciplinaire teams, en borgen hun vakkennis en kennisdeling in communities. Zo hoort het met de staven dus ook te gaan.

Met business afdelingen kan dat anders liggen. Die zijn vaak al georganiseerd rond producten of productlijnen. Denk aan de afdeling levensverzekeringen bij een verzekeringsmaatschappij.

Hoe zie ik dat nu voor me, en hoe kijkt SAFe 5.0 daarnaar? Ik probeer dit middels eigen visualisaties duidelijk te maken.

De klassieke functionele silo’s

Zoals bovenstaand zien vele bestaande organisaties er nog steeds uit. Alle specialisaties zijn in de loop van de tijd verzuild in functionele silo’s die veelal uni-disciplinair zijn en eerder hun eigen (afdelings)-doelen nastreven dat de doelen van de producten die het bedrijf levert. In dit zeer versimpelde voorbeeld ga ik even uit van het feit dat de businessafdelingen al op onderscheidende productgroepen zijn georganiseerd.

Overlay van Release Trains

Scaled Agile Framework (SAFe) legt over de waardestromen (hier aangeduid als productgroepen) Agile Release Trains (ART’s of zelf organiserende teams van teams).

Ik laat de hier als 4^e genoemde Release Train even buiten beschouwing. Hoe je deze moet interpreteren heb ik al uitgebreid uitgelegd in deze blog: ‘Fractale structuur patronen bij het bedrijfsbreed schalen van agile’: https://newgility.eu/2018/03/04/fractale-structuurpatronen-bij-het-bedrijfsbreed-schalen-van-agile/

Verschillende soorten teams

De transitie die zowel business als stafafdelingen dienen te maken is nu als volgt:

De afdeling gaat zichzelf agile organiseren en werken
De afdeling splitst zich op en verdeeld zich over:
1. De waardestromen
1. Een te vormen corporate staf of portfolioteam
De individuele medewerkers richten zich op werken in een multidisciplinair team gericht op waardecreatie, specialiseren zich verder in agile werken en borgen hun vakkennis in communities (bijvoorbeeld een HR community)

Opheffen bestaande structuur

SAFe 5.0 stelt nu dat je de bestaande hiërarchie in stand kunt houden. En met het informele netwerk daaroverheen (de gevisualiseerde overlay) de wendbaarheid kunt bereiken die je wil.

Op dit punt ben ik het niet met de samenstellers van SAFe 5.0 eens. Hier moet het niet stoppen. Het in stand houden van de bestaande hiërarchie leidt alleen maar tot nog meer ineffectiviteit, sub optimalisatie, verstrengeling van belangen, enzovoort. Afdelingen behouden hun eigen ‘afdelingsplannen’, ‘afdelings-meetings’, ‘afdelings-targets’, ‘afdelings-rapportages’ etc. Dat terwijl iedereen in de organisatie zich juist moet richten op de product life cycle, en niet op sub optimale afdelingsdoelen.

Pas dan kun je een echte wendbare organisatie worden naar mijn idee. Voor mij is wendbaarheid dan ook vooral gestoeld op een wendbare structuur, zoals uit veel van mijn blogs blijkt. Natuurlijk moet je ook een wendbaar IT landschap hebben (loosely coupled), en een wendbare strategie. Maar uit een wendbare strategie volgt een wendbare structuur, en, zoals de titel al zegt: Cultuur volgt structuur.

Zie voor een goede visualisatie van de wendbare structuur ook mijn blog: ‘De wendbare organisatie analoog de Boston Matrix’: https://newgility.eu/2019/08/09/de-wendbare-organisatie-analoog-de-boston-matrix/

Dus: het is weg! met dat starre ERP systeem dat niet toelaat dat je makkelijk medewerkers verplaatst, of afdelingen opricht, of afdelingen beëindigd. En de adviesaanvraag aan de ondernemingsraad en FZ zou moeten zijn: ‘Wij willen als organisatie wendbaar worden en daartoe het wijzigen van de organisatie structuur drastisch versimpelen en alle daartoe benodigde advies aanvragen in de toekomst overbodig maken’.

Zet je die stap dan ziet het plaatje er als volgt uit:

Hoezo multidisciplinaire teams?

Om te illustreren dat het echt om multidisciplinaire teams gaat, en niet meer om een HR team, of iets dergelijks, zoom ik nog even in op 1 Release Train. In de bijlage aan het einde zijn de voorbeeld teams uitvergroot:

De rollen zoals hier genoemd zijn fictief. Het is meer om te illustreren dat het om multidisciplinaire teams gaat, en dat je in een release train meerdere soorten multidisciplinaire teams kunt onderscheiden.

Epiloog

Natuurlijk wil je een wendbare organisatie zo plat mogelijk maken met enkelvoudige teams die totaal verantwoordelijk zijn voor een business product. De praktijk maakt dat moeilijk. Daar waar het wel kan, moet je het zeker doen en eerder ‘De-scalen’ dan ‘Scalen’. De voorbeelden die ik hier gebruik zijn slechts ter illustratie van hoofd principes, en zijn vooral toepasbaar op grote organisaties. In detail is elke situatie anders, elke organisatie is anders van omvang, met andere doelen. Het op maat toepassen van welk framework dan ook als hulpmiddel om wendbaar te worden is dan ook altijd noodzakelijk.

In mijn ervaring (ik gebruik al 7 jaar het Scaled Agile Framework om organisaties te kantelen van functioneel naar productgerichte structuren) kunnen organisaties enorm profiteren in meerdere opzichten als je dit goed en adequaat toepast. De praktijk blijft echter altijd weerbarstig.

Ik geef al 5 jaar SAFe trainingen met veel plezier, en met hoge waarderingen (Zie mijn endorsements op LinkedIN). Ik ben nu ook gecertificeerd om de SAFe 5.0 trainingen te mogen geven. Ik deel graag mijn omvangrijke ervaring met mensen die SAFe willen leren kennen, en niet alleen maar naar die website willen kijken. Je zult erachter komen dat SAFe een besturingsmodel is voor het gehele bedrijf, en niet zomaar een werkwijze voor IT.

Geïnteresseerd? Schrijf je dan in op 1 van de open rooster trainingen ‘Leading SAFe’ van Ammerlaan IT Training en Advies te Wateringen.

Bijlage:

Het gaat bij visualisatie van de soorten teams slechts om voorbeelden. Er kan veel worden gezegd over T en W shaped medewerkers, wat er wel en niet in een DevOps team zou moeten zitten, dat de Scrum Guide geen onderscheid maakt in teamrollen buiten Scrum Master en Product Owner. Maar de essentie gaat hier over het feit dat we alleen nog maar denken in multidisciplinaire teams als ‘bouwblok’ van de wendbare organisatie, en niet meer in individuele medewerkers die ‘deliverables’ creëren. Omdat de voorbeeld rollen hiervoor niet goed leesbaar zijn hierna de voorbeeld teams uitvergroot: