Wanneer wordt een IT afdeling te groot?

[Furion2000]

Ik ben benieuwd naar ervaringen en ideeen over het te groot worden van afdelingen?
Wanneer is het qua tijd/geld beter om te splitsen en wat zijn andere opties als je steeds meer ziet dat de afdeling langzamer het product oplevert?

De gedachte hierbij is dat je vaak ziet dat in de eerste paar jaar met 2-3 teams veel meer software gemaakt wordt dan wanneer het bedrijf x2, x3 en meer groeit. Langzamer beslissingen maken, veel tijd kwijt met alle meetings die zijn ontstaan en veel andere regels waaraan voldaan moet worden.

Op papier zal een nieuwe afdeling veel geld kosten kan ik mij voorstellen, maar toch heb ik het idee dat de cijfertjes het software bouwen nog niet goed kunnen meten (anders waren de voorspellingen wel beter) en dat de winst te behalen valt in klein blijven.

Jammer genoeg, als ik begin te googlen, blijf je hits krijgen op micro niveau 'hoe groot moet je scrum team zijn'

[Probub]

*knip* daar is de knop volgen voor

[ Voor 69% gewijzigd door ZieMaar! op 18-04-2023 20:11 ]

[Faeshaas]

Dat ligt ook aan je definitie van een afdeling.

Ik werk bij een groot bedrijf waar de IT 'afdeling' bestaat uit zo'n 250 engineers. Er wordt gewerkt volgens de SAFe methodiek waardoor er 4 ART's zijn van ongeveer 50 engineers per ART. De overige 50 werken weer in een ondersteunende rol voor deze 4 ART's.

Zie je dit als 1 grote afdeling of is elke ART eigenlijk weer een aparte afdeling?

Interessant onderwerp, aangezien bovenstaande beschrijving wat mij betreft ook niet altijd even efficiënt werkt.

[Qwerty-273]

Furion2000 schreef op maandag 17 april 2023 @ 17:15:
De gedachte hierbij is dat je vaak ziet dat in de eerste paar jaar met 2-3 teams veel meer software gemaakt wordt dan wanneer het bedrijf x2, x3 en meer groeit. Langzamer beslissingen maken, veel tijd kwijt met alle meetings die zijn ontstaan en veel andere regels waaraan voldaan moet worden.

Dat is ook een verschil tussen een concept of prototype opleveren waar veel nog ontbreekt, en een meer volwassen product waar je in de huidige feature set niet zomaar alles kan omgooien omdat je als ontwikkelaar een brain fart hebt

[The Eagle]

Aangezien het classificeren van "te groot" bij het management van de IT afdeling zal liggen, praat je eigenlijk sec over de span of control over die afdeling (of groep mensen) door management. En niet inhoudelijk.
Praktisch gezien is 30 - 60 man aan direct reports als (ervaren) manager te doen, mits je je verder niet met de inhoudelijke zaken hoeft te bemoeien. Hoe meer inhoudelijk je ook moet meebeslissen, hoe minder tijd je hebt voor je DR's dus hoe eerder je er een manager op het zelfde niveau bij wilt zetten, en de verantwoordelijkheden of aandachtsgebieden opsplitst cq verdeelt.
Of die groep mensen / afdeling nou een zwik IT'ers betreft of een zut boekhouders, maar eigenlijk niet zo heel veel uit.

[CH4OS]

Over welk aspect van IT gaat het? Een IT afdeling binnen een grote organisatie (gemeente van een overheid bijvoorbeeld) kan het maar zo 100+ man zijn. Toen ik bij een G4 gemeente op de IT afdeling werkte, waren er zo'n 150 personeelsleden vast in dienst en waren er ook ongeveer 150 personeelsleden ingehuurd. De servicedesk waar ik dan zat, was ook ongeveer 10-20 personeelsleden.

Ook heb ik bij een bedrijf gewerkt dat vooral PHP-applicaties doet. Teams van ongeveer 10 personen was dan weer gemiddeld.

Het ligt er dus ook maar ontzettend aan welke tak van sport je doet en de grootte van de organisatie natuurlijk.

[mjax]

Lees Mythical Man-Month en je snapt waarom dit zo werkt bij grotere afdelingen.

[ Voor 3% gewijzigd door ZieMaar! op 18-04-2023 20:12 . Reden: Referral uit link gehaald. ]

[downtime]

Daar is niets zinnigs over te zeggen. Netwerkbeheer van een bank is wat anders dan de ontwikkelafdeling van een game studio. Werken voor een interne klant is wat anders dan werken voor externe klanten. De overheid als klant is wat anders dan 14-jarige gamers als klanten.
Daarnaast kan een bedrijf heel verschillend denken over de taken van een manager. Is de manager een veredelde HR-medewerker of moet ie er inhoudelijk bovenop zitten? In mijn ogen is dit het soort vraag waarvoor je een consultant wilt inhuren. Hele bedrijfstakken zijn erop gericht om dit soort vragen voor een bedrijf te beantwoorden.

[Orangelights23]

Ligt compleet aan de organisatie.

Ik heb nu een functie in een bedrijf van totaal 2000 mensen, waarvan je rond de 1000 als IT’ers kunt zien. Het is de core business van deze organisatie, en we zijn hard op zoek naar extra personeel.

[Zenix]

Ik werk bij een organisatie met 3000 ICT'ers. Mijn afdeling bestaat uit 50 man, met daarbinnen nog weer 6 teams. In enterprise omgevingen gaat alles wat langzamer. In elk team zit rrn architect die weer overleg heeft met andere architecten. Op die manier bouwen we alles onder architectuur.

[Hbeez]

mjax schreef op maandag 17 april 2023 @ 17:47:
Lees Mythical Man-Month en je snapt waarom dit zo werkt bij grotere afdelingen.

Misschien leuk als je even toelicht waarom dan, zodat we niet een boek hoeven aan te schaffen en te lezen om je reactie te begrijpen

[Douweegbertje]

Langzamer beslissingen maken, veel tijd kwijt met alle meetings die zijn ontstaan en veel andere regels waaraan voldaan moet worden.

Dat is minder een team/afdeling probleem maar meer organisatorisch. Wat dat betreft zijn er natuurlijk genoeg boeken/ervaring geschreven.

Jammer genoeg, als ik begin te googlen, blijf je hits krijgen op micro niveau 'hoe groot moet je scrum team zijn'

Herhaling, omdat het ook niet zo zeer een "IT afdelingsprobleem" is maar bedrijfs/organisatie/structuur. Dus iets als, ik noem maar: https://www.bol.com/nl/nl/p/scaling-up/9200000109875392/ kan dan potentieel interessant zijn. Al is dat misschien meer interessant voor een verkapte start-up die groeit

wat zijn andere opties als je steeds meer ziet dat de afdeling langzamer het product oplevert?

Nja, wat je vaak ziet is dat de "stront naar beneden glijd" - maar eigenlijk zou het in 95% van de gevallen volstaan om een degelijke CTO/CEO te hebben. Dus oftewel de huidige vervangen (of misschien iets liever; die gene erop aanspreken) of er überhaupt één aannemen als dat er nog niet is.

Inherent vaak ook het gevolg van een redelijk succesvolle eigenaar op "kleine" schaal, waarna het bedrijf eigenlijk doorgroeit en je niet meer een "startup guru/entrepreneur" nodig hebt, maar een zeer goede leider (of 2-3). Het is namelijk een wereld van verschil of je nu 20-50 mensen hebt of 500. Simpelweg, niet iedereen is daar geschikt voor.

Niet jouw tekst maar van iemand anders, maar om even alleen dat te quoten

In enterprise omgevingen gaat alles wat langzamer.

Dat is alleen het excuus en de standaard die men hanteert maar eigenlijk slaat het nergens op. Behalve dat het globaal geaccepteerd wordt. Wij gaan nu ook richting de ~2000 engineers en wij leveren net zo snel op als menig startup. Daarnaast hebben we ook geen interessante doende architecten in elk team zitten of allemaal onzin meetings.


edit: ik merk dat ik alleen maar zeur en niet aangeef "hoe dan wel" maar dat is een heel groot betoog en ook super afhankelijk van het bedrijf
Zo uit het niets kan je niet exact vertellen hoe dan wel, en dan nog is het ook een transitie en een deel trial & error om dat goed te krijgen. Het enige wat ik vooral wel wilde vertellen is dat grote bedrijven niet log en langzaam hoeven te zijn EN dat men er vaak een handje van heeft om mensen/teams de schuld er van te geven. Terwijl het toch vaak een (hoger) management probleem/uitdaging is.

[ Voor 12% gewijzigd door Douweegbertje op 17-04-2023 22:50 ]

[Furion2000]

Ik redeneer vanuit de startup gedachte, zeg software ontwikkelteams 2-3 groot die opschalen naar x2, x3. Maar binnen bedrijven kun je dit evengoed zien als een klein startup project (afgezonderd van de rest van de afdelingen en processen) wat belangrijker en groter wordt en waarbij steeds meer teams aanhaken. In mijn TS wilde ik alleen ook niet andere IT afdelingen niet buiten sluiten, want misschien komen daar ook wel interessante reacties uit.

Ondanks dat elke situatie anders is, bekruipt er bij niemand soms het gevoel: "waar gaat het hier mis, dit moet toch veel sneller kunnen, hell het ging 3 jaar geleden nog wel snel"?

Ik dacht dat ik al hintte naar het idee dat ik ook denk dat het op organisatorisch niveau te doen gaat zijn en vanuit die hoek probeer ik het probleem ook te bekijken. Ook al zullen sommige afdelingen al zo 'Enterprise' zijn dat er weinig meer te fixen lijkt, ben ik nog strijdlustig en wil ik vooral in mogelijkheden denken. It is what it is neem ik nog geen genoegen mee

Horizontaal schalen van management is iets wat ik lees en dat klinkt goed tot een bepaald punt kan ik mij zo indenken. Er komt een moment dat je je die afdeling misschien beter kunt splitsen? Dan komen we ook weer een beetje terug bij de TS maar misschien kan ik hem al iets meer toelichten.

Wanneer word het ecosysteem te groot om alles in 1 lijn te houden en kun je beter 2 ecosystemen hebben? Hoe kun je die beslisvaardigheid behouden bij de teams ondanks de groei? Dat in 1 lijn houden kost een hoop tijd/geld en wanneer weegt dat niet meer op tegen het tijd/geld van een nieuwe afdeling.

Orangelights23 schreef op maandag 17 april 2023 @ 18:45:
Ligt compleet aan de organisatie.

Deze zie ik hier meerdere malen en ik hoor graag de ervaringen waardoor het komt dat je wel de snelheid denkt te houden in de situatie die je kent of vooral wat je niet moet doen.

PS: interessante boeken zijn welkom, ik lees graag meer hierover.

[ Voor 13% gewijzigd door Furion2000 op 18-04-2023 16:14 ]

[PietervSk]

Een interresante theorie die ik pas tegenkwam ging over het Ringelmann-effect. Kort door de bocht; hoe groter de groep is, hoe minder hard iedereen werkt.
Je hebt ook nog Richard Hackman bij Harvard rondlopen die juist in dit soort zaken zoals productiviteit van teams gespecialiseerd is. Die geeft aan dat je over het algemeen geen teams moet hebben met double digits, en liever max 6 teamleden.
Verschilt wel een beetje per organisatie natuurlijk, maar over het algemeen moet je het kernteam klein houden en alleen de mensen laten aansluiten die echt nodig zijn, of de werkzaamheden splitsen.

[Frame164]

PietervSk schreef op dinsdag 18 april 2023 @ 17:17:
Je hebt ook nog Richard Hackman bij Harvard rondlopen die juist in dit soort zaken zoals productiviteit van teams gespecialiseerd is. Die geeft aan dat je over het algemeen geen teams moet hebben met double digits, en liever max 6 teamleden.

Die teamgrootte klopt maar bij grote projecten moet je het werk wel verdelen over meerdere teams inclusief alle onderlinge afstemming. En dat heeft ook een zekere vorm van inefficientie. Alleen al het goed opsplitsten in brokken is al een dagtaak op zich voor meerdere mensen. En dan heb je in ieder team mensen nodig die de interface zijn met andere teams, en dan is een team van 6 personen aan de krappen kant. Dan is 8 of 9 beter. En boven alle teams heb je dan weerk program management nodig (of de agile equivalent daarvan.

Het is in ieder geval niet allemaal heel zwart-wit.

[Transportman]

Ik heb bij diverse grote en kleine bedrijven rondgelopen, en ik zie de grootste timesinks vooral in de randzaken optreden. Dat los je niet op met een opsplitsing van teams of een extra afdeling, maar zit meestal op een ander niveau in de organisatie iets niet lekker. De kans is zelfs dat je met een extra afdeling nog meer overhead introduceert, want dan gaat er nog meer discussie zijn over budget en wie is waarvoor verantwoordelijk en wie bepaalt de prioriteiten, en dubbele functies per afdeling die niet willen helpen bij problemen op de andere afdeling want het is niet hun afdeling.

Het ergste is vooral bij bedrijven waar zaken als infra geoutsourcet zijn, dan ontstaan er allerlei processen rondom aanvragen met ingewikkelde formulieren die niemand meer begrijpt, die door allerlei lagen van de organisatie moet voor goedkeuringen en dan maar hopen dat het daarna goed uitgevoerd werd. En iedereen ziet dat het simpelweg ruk is, maar niemand krijgt het verbeterd omdat die outsourcing op allerlei niveaus diep in de organisatie genesteld is.

[Verwijderd]

Te groot wanneer er mensen zitten waarvan de ander geen idee heeft wat die de hele dag doet.

Doorgaans zijn ICT afdelingen te groot gezien de hoeveelheid ICT's doorgaans niet in verhouding staan met de winst van de automatisering.

[naitsoezn]

Geldt voor grootte van de afdeling / team in relatie tot de snelheid / output niet gewoon (een versie van) de wet Amdahl (Wikipedia: Amdahl's law )? Je zult met een 2x zo groot team nooit 2x zo snel (of 2x zo veel in dezelfde tijd) kunnen ontwikkelen. Een direct gevolg hiervan is dus dat je het gevoel hebt dat je langzamer aan het ontwikkelen bent in grotere teams (en who knows: Misschien ben je dat ook wel).

Wanneer groot te groot wordt, zal afhankelijk zijn van diverse parameters zoals de complexiteit van het product waar je aan werkt, de stakeholders, en de kwaliteit van de individuele teamgenoten.

[ Voor 7% gewijzigd door naitsoezn op 18-04-2023 20:43 ]

[Hydra]

Ik heb een tijdje geleden Turn the ship around gelezen en dat is hier denk ik ook wel van toepassing. Waar het vooral om gaat is dat als je een sterke top-down cultuur hebt, dit niet schaalt als je bedrijf groter wordt, of als er een nieuwe 'top' komt. Wat je dus wil is zorgen dat er zoveel mogelijk 'lokaal' (in teams) besloten kan worden. Daar gaan veel bedrijven de mist in; dat alles top-down aangestuurd wordt en dat management dit niet los kan laten.

Als de mensen die het werk doen, en meestal de expert zijn, niet veilig zelf besluiten kunnen nemen, gaan ze zitten wachten tot iemand dat voor ze doet. En dat is enorm inefficient.

Ik vond het een erg interessant boek dat zeker mijn kijk op 'leiderschap' beinvloed heeft.

[downtime]

Douweegbertje schreef op maandag 17 april 2023 @ 22:38:
[...]

Dat is alleen het excuus en de standaard die men hanteert maar eigenlijk slaat het nergens op. Behalve dat het globaal geaccepteerd wordt. Wij gaan nu ook richting de ~2000 engineers en wij leveren net zo snel op als menig startup. Daarnaast hebben we ook geen interessante doende architecten in elk team zitten of allemaal onzin meetings.

En die 2000 engineers werken allemaal aan hetzelfde product? En dan geen architecten? Geen overleg? Geen afstemming? Wat voor moloch van een applicatie is dat wel niet? En hoe organiseer je dat dan?

Dat een toko als Microsoft het kan, dat geloof ik wel. Dat hun gamestudio's niet met de SQL Server-developers praten is niet raar en scheelt veel complexiteit. Maar 2000 engineers die aan één product werken, en dan het tempo van een kleine startup bijhouden, dat is wel knap.

[FirePuma142]

Hydra schreef op woensdag 19 april 2023 @ 12:56:
Ik heb een tijdje geleden Turn the ship around gelezen en dat is hier denk ik ook wel van toepassing. Waar het vooral om gaat is dat als je een sterke top-down cultuur hebt, dit niet schaalt als je bedrijf groter wordt, of als er een nieuwe 'top' komt. Wat je dus wil is zorgen dat er zoveel mogelijk 'lokaal' (in teams) besloten kan worden. Daar gaan veel bedrijven de mist in; dat alles top-down aangestuurd wordt en dat management dit niet los kan laten.

Als de mensen die het werk doen, en meestal de expert zijn, niet veilig zelf besluiten kunnen nemen, gaan ze zitten wachten tot iemand dat voor ze doet. En dat is enorm inefficient.

Ik vond het een erg interessant boek dat zeker mijn kijk op 'leiderschap' beinvloed heeft.

Grootste uitdaging met lokale besluiten in een complexe omgeving is vaak de blik naar buiten. Het blijkt vaak heel erg lastig om buiten de eigen applicatie, of het eigen domein te kijken. Dat levert dan nogal eens functionele rariteiten of onverwachte resultaten op. Dat oplossen kost vervolgens ook weer een boel tijd, en is daarmee inefficiënt. Ik vind het de juiste route, meer zeggenschap bij teams/engineers, maar het vergt wel een behoorlijke extra inspanning. Ik zie maar heel weinig engineers die die skillset hebben om die inspanning tot een goed einde te brengen.

[Hydra]

FirePuma142 schreef op woensdag 19 april 2023 @ 14:20:
Grootste uitdaging met lokale besluiten in een complexe omgeving is vaak de blik naar buiten. Het blijkt vaak heel erg lastig om buiten de eigen applicatie, of het eigen domein te kijken. Dat levert dan nogal eens functionele rariteiten of onverwachte resultaten op. Dat oplossen kost vervolgens ook weer een boel tijd, en is daarmee inefficiënt. Ik vind het de juiste route, meer zeggenschap bij teams/engineers, maar het vergt wel een behoorlijke extra inspanning. Ik zie maar heel weinig engineers die die skillset hebben om die inspanning tot een goed einde te brengen.

Dat wordt ook in het boek behandeld. Het is een leertraject waar je doorheen moet. Terwijl de meeste managers de neiging hebben om, als het een keer misgaat, meteen tot de conclusie te komen dat het niet werkt. En dan ga je het dus nooit fixen.

[Furion2000]

Ik lees afhankelijkheid van buitenaf, het missen van overzicht, complexe koppelvlakken en vind ze erg herkenbaar bij software ontwikkeling. Deels komt mijn vraag hier ook uit voort en ik wil automatisch ook graag over pipelines en dat soort zaken beginnen, maar ik dat zie ik dagelijks mis gaan in de onderlinge discussies. Direct inzoomen, terwijl overzicht in deze dingen wel key is.

Misschien een slecht voorbeeld maar het plaatje wat ik zie is;
Een timmerbedrijf dat met machine X een succesvol product X maken en 2 teams daarin hebben, vervolgens komt er innovatie en onstaat er een product Y dat erg veel lijkt op X en dus evengoed met machine X gemaakt word. Vervolgens product Z wat wel gelijkenissen heeft met product Y maar totaal niet met product X maar door de gedachte dat alles gestroomlijnt moet lopen zal product Z ook op machine X gemaakt worden. Team wat verantwoordelijk is voor products Z moet zich in alle hoeken en gaten wringen om het allemaal werkend te houden en overvragen logischerwijs de ervaring van de X teams die weer door dat tijdsverlies langzamer worden in product X.

Ondertussen ellenlange discussies allemaal met de focus op machine X door ervaren mensen
Management hoort de onvrede, maar het is op papier zo klaar als een klontje dat het op HR vlak (onderling uitwisselbaar) en onderhoud goedkoper is om 1 afdeling te houden.

@Hydra is dan raak met 'turn the ship around' maar ik denk dat het in praktijk ook een auto is die slecht uitgelijnd is en eigenlijk altijd naar een kant trekt. Ik heb voorbeelden van startup projecten die goed starten en dus snel zijn en dan vertragen, ze trekken weer naar de kant dat dingen worden gestroomlijnd om grip op zaken te houden. Ik weet niet of het boek ook antwoord geeft op die vragen en met oplossingen komt, maar het idee van een tweede startup project (clean slate met de kennis van het eerste project) in plaats van uitbreiden blijft knagen en kan het niet uitdrukken in logische tijd/geld argumenten

50 productie mensen ondersteund door 20 aansturende mensen, hoe druk je uit dat die 50 mensen die nog maar 50% productiviteit halen duurder worden een nieuwe startup waar dan bij wijze van 25 mensen met 15 aansturende (x2) weer op 100% kunnen werken.

[ Voor 5% gewijzigd door Furion2000 op 19-04-2023 15:48 ]

[Douweegbertje]

downtime schreef op woensdag 19 april 2023 @ 14:08:
[...]

En die 2000 engineers werken allemaal aan hetzelfde product? En dan geen architecten? Geen overleg? Geen afstemming? Wat voor moloch van een applicatie is dat wel niet? En hoe organiseer je dat dan?

Dat een toko als Microsoft het kan, dat geloof ik wel. Dat hun gamestudio's niet met de SQL Server-developers praten is niet raar en scheelt veel complexiteit. Maar 2000 engineers die aan één product werken, en dan het tempo van een kleine startup bijhouden, dat is wel knap.

Het is maar net van welke kant je kijkt maar in principe is het 1 dienst/service maar daar zitten natuurlijk 100den verschillende aspecten aan.

m.b.t architecten;
Ik vind architecten overrated. Als je teams hebt met seniors (en dan bedoel ik echte seniors) dan is dat naar mijn inziens 100x beter dan een architect die misschien super goed is in 'architecten' maar totaal niet techniek/applicatie specifieke kennis heeft. Dus ja, mijn ervaring is dat ze dan met allerlei frameworks komen aanzetten, eigenlijk alleen maar als gatekeepers functioneren en met name hoger management pleasen met mooie powerpoints. Ik ben heel erg van mening dat als je goede mensen hebt, dat deze zeer zeker zelfsturend kunnen zijn.

m.b.t. overleg;
Veel async en enkel wat overleg als het gewoon even nodig is. Ik ben zelf verantwoordelijk voor een aantal zaken en 100den teams / 1000+ engineers maken gebruik van ons spul en ik heb ongeveer 2 uurtjes max per week aan gesprekken.

m.b.t. afstemming;
Nee. Ik denk dat als er duidelijke doelen in de organisatie worden uitgedragen dan hoef je niet constant af te stemmen of toestemming te krijgen. Wij zijn slim genoeg om zelf in te zien of iets impact heeft en om dan even (async) een threadtje te starten en zo samenwerking op te zoeken. Dit zonder dat het in ingepland hoeft te worden in een sprint over 10 weken of over x-kwartalen.

m.b.t. hoe organiseer je dat dan
Dat is een beetje wat ik probeer uit te leggen, maar wat naar mijn mening best moeilijk is in een berichtje zonder al te veel context. Als je nou alle 'ruis' weg haalt en "overbodige functies" en "mensen die veel zeggen maar weinig doen/toevoegen" én... goede mensen (echte seniors) hebt, dan kan je best wel 'start-up' style doorgroeien.

En om eerlijk te zijn, ik heb bij genoeg partijen binnen gekeken (zoals eigenlijk alle banken in NL) en ik heb genoeg voorbeelden/argumenten om heel dat 'architectuur' om zeep te helpen Maar dat is misschien een te lange discussie/argument om hier neer te plempen

[Fr33z]

ik denk dat je ook onderschat dat er verschillende fases zijn in productontwikkeling. in het begin gaat dingen maken snel en maak je grote stappen. maar naarmate je meer hebt en grote ecosystemen etc moet je veel meer aan onderhoud doen. dat 'vertraagd' ook.

[downtime]

Douweegbertje schreef op woensdag 19 april 2023 @ 18:21:
[...]

m.b.t architecten;
Ik vind architecten overrated. Als je teams hebt met seniors (en dan bedoel ik echte seniors) dan is dat naar mijn inziens 100x beter dan een architect die misschien super goed is in 'architecten' maar totaal niet techniek/applicatie specifieke kennis heeft. Dus ja, mijn ervaring is dat ze dan met allerlei frameworks komen aanzetten, eigenlijk alleen maar als gatekeepers functioneren en met name hoger management pleasen met mooie powerpoints. Ik ben heel erg van mening dat als je goede mensen hebt, dat deze zeer zeker zelfsturend kunnen zijn.

Dat is meer een definitie kwestie. In mijn ogen kan de architect prima een (ex) developer zijn die een rol als architect in dat project heeft. Dat niet alle bedrijven dat zo zien is een ander verhaal. Maar in mijn ogen werken jullie dus wel met architecten, maar dan als rol en niet als functie.

m.b.t. overleg;
Veel async en enkel wat overleg als het gewoon even nodig is. Ik ben zelf verantwoordelijk voor een aantal zaken en 100den teams / 1000+ engineers maken gebruik van ons spul en ik heb ongeveer 2 uurtjes max per week aan gesprekken.

Dus toch overleg. Ook in een Enterprise omgeving hoeven dat geen urenlange wekelijkse overleggen te zijn waar nooit wat uit komt. Kan wel maar de cultuur van de organisatie bepaalt veel. Sommige organisaties zijn gewoon heel ambtelijk of risico-avers. En soms worden ze daar ook toe gedwongen door de wetgever en/of toezichthouders.

m.b.t. afstemming;
Nee. Ik denk dat als er duidelijke doelen in de organisatie worden uitgedragen dan hoef je niet constant af te stemmen of toestemming te krijgen. Wij zijn slim genoeg om zelf in te zien of iets impact heeft en om dan even (async) een threadtje te starten en zo samenwerking op te zoeken. Dit zonder dat het in ingepland hoeft te worden in een sprint over 10 weken of over x-kwartalen.

Dat is dan toch ook afstemming? Je mist alleen de papertrail. Als niemand om een papertrail vraagt is dat ook goed.

m.b.t. hoe organiseer je dat dan
Dat is een beetje wat ik probeer uit te leggen, maar wat naar mijn mening best moeilijk is in een berichtje zonder al te veel context. Als je nou alle 'ruis' weg haalt en "overbodige functies" en "mensen die veel zeggen maar weinig doen/toevoegen" én... goede mensen (echte seniors) hebt, dan kan je best wel 'start-up' style doorgroeien.

En om eerlijk te zijn, ik heb bij genoeg partijen binnen gekeken (zoals eigenlijk alle banken in NL) en ik heb genoeg voorbeelden/argumenten om heel dat 'architectuur' om zeep te helpen Maar dat is misschien een te lange discussie/argument om hier neer te plempen

Ik heb ook bij financials gewerkt en merkte ook dat veel acties in vijf minuten met de juiste personen aan tafel afgestemd kunnen worden, maar dat de papertrail (formele goedkeuring) daarna een veelvoud van die tijd kost. Maar ik vrees dat ze niet veel anders kunnen. Er zijn nu eenmaal toezichthouders en auditors die meekijken.

[Furion2000]

Fr33z schreef op woensdag 19 april 2023 @ 19:37:
ik denk dat je ook onderschat dat er verschillende fases zijn in productontwikkeling. in het begin gaat dingen maken snel en maak je grote stappen. maar naarmate je meer hebt en grote ecosystemen etc moet je veel meer aan onderhoud doen. dat 'vertraagd' ook.

Ik ben van mening dat we met dit soort uitleg zoet gehouden worden of althans dat blijf ik denken totdat iemand het mij goed kan uitleggen. Want hoe kan deze complexiteit dan ontstaan als je je product opdeelt in kleinere ecosystemen met goede interfaces ertussen (iets wat imo al erg goed begrepen word in de software wereld)? Meenemend dat de meeste ervaringen die hier genoemd worden projecten zijn die al gestart worden in een erg groot complex ecosysteem, maar door zich te ontkoppelen heel succesvol van start zijn gegaan.

@Douweegbertje Ik twijfel om te zeggen, go for it, want ervaringen delen waar andere weer op kunnen schieten is alleen maar goed, maar het moet geen architecten bashing worden. Misschien als de focus ligt wat er vanuit bepaalde hoeken voor beperkingen komen waardoor de snelheid eruit word getrokken.

Ik neig alleen wel naar woorden zoals afstemming/stroomlijning/grip als factoren die snelheid kunnen beperken. Allemaal goede dingen, maar ze lijken al snel 'TEVEEL' ervoor te krijgen als een afdeling groeit.

[ Voor 21% gewijzigd door Furion2000 op 20-04-2023 08:59 ]

[Webgnome]

Furion2000 schreef op donderdag 20 april 2023 @ 08:52:
[...]


Ik ben van mening dat we met dit soort uitleg zoet gehouden worden of althans dat blijf ik denken totdat iemand het mij goed kan uitleggen. Want hoe kan deze complexiteit dan ontstaan als je je product opdeelt in kleinere ecosystemen met goede interfaces ertussen (iets wat imo al erg goed begrepen word in de software wereld)? Meenemend dat de meeste ervaringen die hier genoemd worden projecten zijn die al gestart worden in een erg groot complex ecosysteem, maar door zich te ontkoppelen heel succesvol van start zijn gegaan.

@Douweegbertje Ik twijfel om te zeggen, go for it, want ervaringen delen waar andere weer op kunnen schieten is alleen maar goed, maar het moet geen architecten bashing worden. Misschien als de focus ligt wat er vanuit bepaalde hoeken voor beperkingen komen waardoor de snelheid eruit word getrokken.

Ik neig alleen wel naar woorden zoals afstemming/stroomlijning/grip als factoren die snelheid kunnen beperken. Allemaal goede dingen, maar ze lijken al snel 'TEVEEL' ervoor te krijgen als een afdeling groeit.

Soms worden systemen zo groot dat zelfs het opdelen in kleinere stukken er wellicht voor zorgt dat je dat stuk begrijpt maar dat je het hele complete plaatje niet door hebt. En wat dacht je van verloop? Mensen die jaren en jaren aan de codebase werken die weg gaan. Dan kun je het nog zo mooi opgedeeld hebben maar kan het voor nieuwe mensen als een boom in een heel groot bos voelen

[Furion2000]

Webgnome schreef op donderdag 20 april 2023 @ 09:26:
[...]


Soms worden systemen zo groot dat zelfs het opdelen in kleinere stukken er wellicht voor zorgt dat je dat stuk begrijpt maar dat je het hele complete plaatje niet door hebt. En wat dacht je van verloop? Mensen die jaren en jaren aan de codebase werken die weg gaan. Dan kun je het nog zo mooi opgedeeld hebben maar kan het voor nieuwe mensen als een boom in een heel groot bos voelen

Kun je dat verder omschrijven? Wanneer een complex systeem dat goed ontkoppelbaar is niet meer te begrijpen is voor teams? Wat word er dan bedoelt met complete plaatje (technische plaatje, business logic, functionaliteit)?

Het verloop kan een reden zijn als dat erg hoog is, maar dan heb je een goed aanwijsbare reden en is hij voor iedereen duidelijk en is zijn de onderliggende redenen ook vaak duidelijk. In de TS had ik dit soort basale redenen eigenlijk niet in mijn hoofd, terwijl ze er natuurlijk wel degelijk kunnen zijn, maar waar ik op doelde is meer de vertraging waar je iets lastiger je vinger op kan leggen.

[Hydra]

Webgnome schreef op donderdag 20 april 2023 @ 09:26:
Soms worden systemen zo groot dat zelfs het opdelen in kleinere stukken er wellicht voor zorgt dat je dat stuk begrijpt maar dat je het hele complete plaatje niet door hebt. En wat dacht je van verloop? Mensen die jaren en jaren aan de codebase werken die weg gaan. Dan kun je het nog zo mooi opgedeeld hebben maar kan het voor nieuwe mensen als een boom in een heel groot bos voelen

Sowieso schaalt bij een beetje een groot bedrijf de software ver ver voorbij wat een enkele persoon in z'n hoofd kan houden. Ik heb 2.5 jaar bij een startup op een greenfield project gezeten. In het begin waren we met een man of 8 aan developers en na een jaar ofzo was het gewoon niet meer voor een enkel persoon te bevatten.

[Hydra]

Douweegbertje schreef op woensdag 19 april 2023 @ 18:21:
Ik vind architecten overrated. Als je teams hebt met seniors (en dan bedoel ik echte seniors) dan is dat naar mijn inziens 100x beter dan een architect die misschien super goed is in 'architecten' maar totaal niet techniek/applicatie specifieke kennis heeft. Dus ja, mijn ervaring is dat ze dan met allerlei frameworks komen aanzetten, eigenlijk alleen maar als gatekeepers functioneren en met name hoger management pleasen met mooie powerpoints. Ik ben heel erg van mening dat als je goede mensen hebt, dat deze zeer zeker zelfsturend kunnen zijn.

Software architect is m.i. meer een rol dan een titel (en ik heb zelf die titel gehad). Mijn ervaring is dat elke 'architect' die niet ook zelf aan het product werkt, binnen een paar jaar irrelevant wordt en een eigen parallelle waarheid (die 'ie nog wel snapt) gaat creeeren. Dit levert een enorme schade op, omdat er een disconnect ontstaat tussen wat de business denkt dat er is, en wat er daadwerkelijk aan software gebouwd wordt.

In elke organisatie waar ik de laatste 20 jaar gewerkt hebt waar de business via de architecten praat (dus niet rechtstreeks met de teams) ontstonden grote problemen hierdoor.

Een bekend bedrijf met een blauw dik mannetje heeft niet voor niets de functietitel software architect gewoon opgeheven. Deze architecten moesten toen solliciteren op IC functies. M.i. een hele sterke zet.

[Douweegbertje]

Hydra schreef op donderdag 20 april 2023 @ 13:19:
[...]


Software architect is m.i. meer een rol dan een titel (en ik heb zelf die titel gehad). Mijn ervaring is dat elke 'architect' die niet ook zelf aan het product werkt, binnen een paar jaar irrelevant wordt en een eigen parallelle waarheid (die 'ie nog wel snapt) gaat creeeren. Dit levert een enorme schade op, omdat er een disconnect ontstaat tussen wat de business denkt dat er is, en wat er daadwerkelijk aan software gebouwd wordt.

In elke organisatie waar ik de laatste 20 jaar gewerkt hebt waar de business via de architecten praat (dus niet rechtstreeks met de teams) ontstonden grote problemen hierdoor.

Een bekend bedrijf met een blauw dik mannetje heeft niet voor niets de functietitel software architect gewoon opgeheven. Deze architecten moesten toen solliciteren op IC functies. M.i. een hele sterke zet.

Mijn sterkste punt is niet altijd om de tijd te nemen om mijn mening wat politiek correcter neer te zetten. Helemaal eens met wat je zegt, en ik wou dat ik het zelf zo had neer gezet

@Furion2000 - Geen bashen, het is een mening. En, wat ik hierboven zei.

downtime schreef op woensdag 19 april 2023 @ 19:56:

[...]

Ik heb ook bij financials gewerkt en merkte ook dat veel acties in vijf minuten met de juiste personen aan tafel afgestemd kunnen worden, maar dat de papertrail (formele goedkeuring) daarna een veelvoud van die tijd kost. Maar ik vrees dat ze niet veel anders kunnen. Er zijn nu eenmaal toezichthouders en auditors die meekijken.

Mijn ervaring was vooral dat er een legio aan mensen zelf werk creëren in audit/risk/management/proces. Het is ook een beetje wat Hydra aangeeft m.b.t architecten. Ik wil niet weer alles en iedereen over één kam scheren maar laat ik het dan zo zeggen: bij de traditionele enterprises zie je toch dat bepaalde functies worden ingevuld door mensen die daar in groeien.
Pak je zo'n financieel bedrijf met een oranje leeuw; letterlijk de beleidsbepalers zijn mensen die er 10-20 jaar zitten en daar gekomen zijn door promotie/invul. Naar mijn inziens niet omdat ze nou zo innovatief zijn. En verwacht nou ook niet baanbrekende veranderingen, want je zou maar een foutje maken en je gouden kooitje verliezen.

Dus om naar mijn punt te gaan:

Maar ik vrees dat ze niet veel anders kunnen

Dat kan dus zeer zeker wel, alleen dan moet dat wel gebeuren.

Er zijn nu eenmaal toezichthouders en auditors die meekijken.

En toch als je daar de connectie mee zoekt en eens kritische vragen stelt, hopende op mensen die ook vooruitgang willen, is daar heel veel mogelijk.

Ik heb zelf bij een andere bank een bepaald initiatief geleid waarbij we de eerste waren om in de cloud te gaan. Dus ik heb ook wel mijn ervaringen met DNB, audit, risk en commissies. Ik nam alleen de moeite om niet direct aan de richtlijnen te voldoen, maar een betoog te schrijven waarom de richtlijn onzin is en waarom wij het beter doen.

Misschien een concreet voorbeeld is dat er altijd de eis ligt/lag dat je periodiek failovers uitvoert. Je datacenters moeten x-km's uit elkaar liggen, etc. In de werkelijkheid doen banken dus een heel process van weken waarbij ze alles voorbereiden om zo'n failover te doen. Lekker "natuurlijk" is dat. Want in principe wijst het alleen uit _dat_ het kan, maar niet dat als de poep de ventilator raakt, dat jij nog online bent. Grote kans dat die mitigatie helemaal niet werkt omdat er 1 datacenter mist.
Anyhow, door aan te tonen dat alles continue over meerdere regio's en zones draait waarbij we af en toe chaos engineren kon ik die stappen toch afvinken. Dat terwijl alle 'oude heren' alleen maar tegen mij zaten te zeuren dat ik niet aantoonbaar mijn controls op orde had.

Dat is mijn punt, je hebt zoveel onzin wat gewoon een wassen neus is, en dat is prima te doorbreken en te verbeteren. Dan vraag ik mij (naar mijn inziens terecht) af waarom er dan zoveel mensen zitten die bepaalde zaken in leven proberen te houden. Ik vind dat echt gatekeeping, en puur gebaseerd op mijn ervaring; stikt het daar van bij heel veel bedrijven.

Resume, haal die ruis en al dat soort zaken weg. Zet er een paar innovatieve seniors neer die ook zin in hun werk hebben. Wellicht 1-2 oude rotten met goede praktijk ervaring. Voila, dat lijkt mij al veel beter.

[ Voor 57% gewijzigd door Douweegbertje op 22-04-2023 04:36 ]

[Croga]

Furion2000 schreef op woensdag 19 april 2023 @ 15:44:
Misschien een slecht voorbeeld maar het plaatje wat ik zie is;
Een timmerbedrijf dat met machine X een succesvol product X maken en 2 teams daarin hebben, vervolgens komt er innovatie en onstaat er een product Y dat erg veel lijkt op X en dus evengoed met machine X gemaakt word. Vervolgens product Z wat wel gelijkenissen heeft met product Y maar totaal niet met product X maar door de gedachte dat alles gestroomlijnt moet lopen zal product Z ook op machine X gemaakt worden. Team wat verantwoordelijk is voor products Z moet zich in alle hoeken en gaten wringen om het allemaal werkend te houden en overvragen logischerwijs de ervaring van de X teams die weer door dat tijdsverlies langzamer worden in product X.

Heel erg herkenbaar. Een "manager" die denkt dat software hergebruiken voor andere toepassingen een goed idee is en dan de link blijven houden tussen de huidige code bases. De grootste fout die ik overal gemaakt zie worden. Het resultaat is namelijk dat de machine die ooit alleen X deed plots code heeft die alleen ter ondersteuning van Y of Z is maar werking X wel in de weg gaat zitten......

De succesvolste bedrijven snappen dat dit niet gaat. Je kunt X forken om Y te doen en vervolgens X of Y forken om Z te doen maar je kunt niet Z gaan doen op X en dan X aanpassen om Z te kunnen blijven doen.

De meest succesvolle teams zijn een man of 5 (volgens Jurgen Appelo zelfs 5.6 man ). Het snelste team waar ik ooit voor gewerkt heb bestond uit 3 man, 1 scrum master en 1 product owner wat later uitgebreid werd met een tweede team van 3 man bij dezelfde scrum master en product owner. Die 2 teams hadden vervolgens sterk gescheiden taken op hetzelfde product (1 "plaform" team, 1 "proces" team). En zo'n beetje iedereen die je het in de Agile wereld vraagt stelt ook "Don't scale up your teams, scale down your product".

Stel in het eerste voorbeeld was er geen link geweest tussen X, Y en Z. Dan was er ook geen afhankelijkheid geweest, geen oneigenlijke code in X, geen eindeloos overleg.... Weliswaar ook geen perceived "economy of scale" maar de voordelen van de ontkoppeling zijn oneindig veel groter dan die van de schaalgrootte.

Zolang "managers" niet in onafhankelijke, of sterk losgekoppelde, producten kunnen denken ga je hier helaas niet komen. In de ideale wereld hebben we een bergje teams van een man of 5 die óf volledig losgekoppeld zijn, óf een beperkte hoeveelheid goed gedefinieerde interfaces. Tot die tijd kan SAFe je helpen om daar te komen (SAFe is geen doel op zich maar een middel wat helpt om afhankelijkheden duidelijk te maken en vervolgens te verwijderen. "The purpose of SAFe is to remove all SAFe" om Taiichi Ohno maar even te parafraseren)

[Harm_H]

Furion2000 schreef op maandag 17 april 2023 @ 17:15:

De gedachte hierbij is dat je vaak ziet dat in de eerste paar jaar met 2-3 teams veel meer software gemaakt wordt dan wanneer het bedrijf x2, x3 en meer groeit. Langzamer beslissingen maken, veel tijd kwijt met alle meetings die zijn ontstaan en veel andere regels waaraan voldaan moet worden.

Je linkt de verkeerde zaken: software productiviteit aan aantal IT'ers. Het zit namelijk ook intrinsiek in het beestje van coderen:

Nieuwe features zijn makkelijker te implementeren dan bestaande features aan te passen.

Om bestaande features aan te passen, moet je zowel de oude situatie als de nieuwe situatie begrijpen. Het is dubbel zo ingewikkeld als alleen nieuw bouwen. Daarom doen sommige succesvolle indie gamedevelopers aan rapid releasing denk ik. Product maken. Volgende product maken. Lessen toepassen bij het volgende product. Nederlands voorbeeld.

Grote organisaties hebben die luxe niet, omdat een applicatie onderhouden moet worden. Toegegeven, er moet wel vaker gekeken worden naar de kosten van onderhoud. Die liggen dus dikwijls hoger dan men denkt vanwege de menselijke aard:

"kritiek op het nieuwe, loof voor het oude"

[ Voor 12% gewijzigd door Harm_H op 22-04-2023 09:00 ]

[Furion2000]

Harm_H schreef op zaterdag 22 april 2023 @ 08:56:
[...]


Je linkt de verkeerde zaken: software productiviteit aan aantal IT'ers. Het zit namelijk ook intrinsiek in het beestje van coderen:

Nieuwe features zijn makkelijker te implementeren dan bestaande features aan te passen.

Het is alleen dat ik die complexiteit al meegenomen had in mijn overwegingen en ik al situaties heb meegemaakt dat dit probleem grotendeels werd getackled door goede ontkoppeling waardoor nieuwe features bijna net zo complex zijn als bestaande features aanpassen.

Ik weet ook niet of @Croga hier de uitspraak vandaan gevist had, maar deze blog omschrijft eigenlijk ook erg goed hoe ik het zie in grote organisaties als de way to go: https://medium.com/the-li...product-down-c70f335ccf3a

Vind het wel een eye opener, want je product kan al erg ontkoppeld zijn, als development teams onderling en op verschillende niveau's extreem veel stroomlijning vergt, dan kan er ook flinken vertraging opgelopen worden. Dan krijg je weer het machine x is perfect voor product x en machine y voor die van y en machine z word gekocht voor beide producten omdat het kan....

@Douweegbertje In die ervaringen, wat was dan de mandaat die er lag? Het is namelijk mens eigen om elk verandering ook te beoordelen op diegene die daarin de leiding neemt. E.g. een junior developer zal grotere moeite hebben dan een senior om een beleidsbepaler te overtuigen. (zegt niets over dat die junior niet via een senior impact kan hebben). Kan ook zijn dat er geen mandaat was, maar dat er werd overtuigd door daden (gewoon eerst uitvoeren, want dan heb je al bewijs).

[ Voor 15% gewijzigd door Furion2000 op 22-04-2023 14:31 ]

[Croga]

Furion2000 schreef op zaterdag 22 april 2023 @ 14:20:
Ik weet ook niet of @Croga hier de uitspraak vandaan gevist had, maar deze blog omschrijft eigenlijk ook erg goed hoe ik het zie in grote organisaties als de way to go: https://medium.com/the-li...product-down-c70f335ccf3a

Laten we zeggen dat de Liberators en ik uit dezelfde bron putten

[Douweegbertje]

Furion2000 schreef op zaterdag 22 april 2023 @ 14:20:
[...]

@Douweegbertje In die ervaringen, wat was dan de mandaat die er lag? Het is namelijk mens eigen om elk verandering ook te beoordelen op diegene die daarin de leiding neemt. E.g. een junior developer zal grotere moeite hebben dan een senior om een beleidsbepaler te overtuigen. (zegt niets over dat die junior niet via een senior impact kan hebben). Kan ook zijn dat er geen mandaat was, maar dat er werd overtuigd door daden (gewoon eerst uitvoeren, want dan heb je al bewijs).

Ha, ja ik denk eigenlijk dat er geen mandaat was. Ik heb het eerder gevoeld dat er een aantal mensen waren die voorzichtig de teentjes in het water deden. Deels oprecht in de zin van "nou, even dat voorzichtig aankijken" en dan een groot deel om nooit verantwoording te hoeven af te dragen.
Dan heb je nog wat mensen die best wel een keer in het jaar voor iets willen vechten of het nou wel of niet goed is, maar dat ze persoonlijk wel iets hebben van "hey dat is de richting die we moeten opgaan". Dus die heb je dan in elk geval mee.

Uiteindelijk het geen wat doorslag gaf en vertrouwen wint, is om 1 a 2 keer een dermate goede "presentatie" te geven. Dus je hebt dan voor bepaalde changes eigenlijk een commissie. Toen ik zelf in de historie keek daarvan zag ik toch best wel dat mensen dat zagen als "weer papierwerk". Terwijl het doel juist wel goed is. Kijken of wat je wilt doen logisch en goed is. Misschien dat er naar jaren mensen daar erg tegenop keken. Heel veel zaken werden ook 'afgekeurd', maar naar mijn inziens terecht. Er hing ook een cultuur dat je nooit in 1x door de commissie heen kwam.

Ik heb mij toen van niemand iets aangetrokken en puur bij mijn expertise, kunde en techniek gebleven. Pro-actief opgesteld om mijn spul gewoon op orde te hebben (wat voor mij gewoon de standaard is). Uiteindelijk die dag 5 mensen zien afgegaan en ik als noob was allemaal groene checks. Plus dat ik het over zoveel dingen had, wat hun niet begrepen.

Vanuit hier het vertrouwen gekregen en dan willen mensen opeens wel meedoen en aansluiten. Vanaf daar was alles eigenlijk wel makkelijk en komt er ook een mooie samenwerking waarbij oude loge processen eens werden herzien bijvoorbeeld.

Salient detail is misschien dat veel wat ons team heeft gedaan (echt niet alleen ik) onderdeel is geweest voor de start van een reorganisatie.

[Frankinho]

The Eagle schreef op maandag 17 april 2023 @ 17:39:
Aangezien het classificeren van "te groot" bij het management van de IT afdeling zal liggen, praat je eigenlijk sec over de span of control over die afdeling (of groep mensen) door management. En niet inhoudelijk.
Praktisch gezien is 30 - 60 man aan direct reports als (ervaren) manager te doen, mits je je verder niet met de inhoudelijke zaken hoeft te bemoeien. Hoe meer inhoudelijk je ook moet meebeslissen, hoe minder tijd je hebt voor je DR's dus hoe eerder je er een manager op het zelfde niveau bij wilt zetten, en de verantwoordelijkheden of aandachtsgebieden opsplitst cq verdeelt.
Of die groep mensen / afdeling nou een zwik IT'ers betreft of een zut boekhouders, maar eigenlijk niet zo heel veel uit.

Ik vind 30 tot 60 man aan direct reports wel heel erg enthousiast. Dan kun je om de week een uurtje aan iemand besteden en verder helemaal niets anders doen. Als je ook nog iets moet met de feedback/vragen van die persoon gaat het al helemaal mank.
Ik heb geen ervaring met direct reports in een IT omgeving, maar ik heb in mijn huidige rol 10 direct reports (verkoop gerelateerde rollen, hoge graad van zelfstandigheid en (relatief) goed betaalde functies) en daar ben ik goed zoet mee. Dat kan wel groeien tot 15 of misschien 20, maar dan houdt het realistisch gezien wel een keertje op als je je mensen ook nog serieus wilt sturen/begeleiden.
Maar misschien is mijn referentie kader gewoon heel anders, dat kan natuurlijk ook

[Mugwump]

Furion2000 schreef op maandag 17 april 2023 @ 17:15:
Ik ben benieuwd naar ervaringen en ideeen over het te groot worden van afdelingen?
Wanneer is het qua tijd/geld beter om te splitsen en wat zijn andere opties als je steeds meer ziet dat de afdeling langzamer het product oplevert?

De gedachte hierbij is dat je vaak ziet dat in de eerste paar jaar met 2-3 teams veel meer software gemaakt wordt dan wanneer het bedrijf x2, x3 en meer groeit. Langzamer beslissingen maken, veel tijd kwijt met alle meetings die zijn ontstaan en veel andere regels waaraan voldaan moet worden.

Op papier zal een nieuwe afdeling veel geld kosten kan ik mij voorstellen, maar toch heb ik het idee dat de cijfertjes het software bouwen nog niet goed kunnen meten (anders waren de voorspellingen wel beter) en dat de winst te behalen valt in klein blijven.

Jammer genoeg, als ik begin te googlen, blijf je hits krijgen op micro niveau 'hoe groot moet je scrum team zijn'

Als scale-up met een softwareproduct krijg je inderdaad te maken met de uitdagingen die komen kjiken bij een groeiende organisatie. Je haalt Scrum aan, dus ik ga er vanuit dat er binnen het bedrijf een Agile mindset aanwezig is.In de basis is elke start-up natuurlijk agile in de zin dat zo'n bedrijf dusdanig klein is dat er altijd 'bottom-up' innovatie is, business en IT nauw samenwerken (of gewoon dezelfde persoon zijn) en ga zo maar door.
Wat je in wezen wilt is de voordelen van een start-up behouden zonder dat het een totale chaos wordt. Het opschalen van agile is een complex vraagstuk waar velen zich al over gebogen hebben.
Het grote gevaar is dat om die totale chaos te voorkomen wordt gekozen voor rigide centrale sturing. Dat is feitelijk ook hoe grote enterprise organisaties doorgaans altijd hebben gewerkt (of nog steeds werken) en het veelal ook afleggen tegen veel innovatievere concurrenten die wél een agile mindset omarmen. Wat je dan heel veel ziet is dat er verstikkende methodologieën als SAFe worden geïntroduceerd die vooral wat hoepeltjes en ritueeltjes introduceren, alle centrale sturingslagen van wat andere naampjes voorzien en nog steeds nul autonomie en ruimte voor innovatie laten aan teams.

Het grote probleem met je vraag is dat er geen eenduidig antwoord te geven is op hoe je een organisatie vorm moet geven. In de basis is het advies om het empirisch en organisch te doen. Ga niet top-down proberen een organisatie vorm te geven, op voorhand op te delen in specifieke teams. Je kunt de markt en je eigen ontwikkeling niet voorspellen. Ik vind dit stuk in de Harvard Business Review van o.a. Jeff Sutherland altijd wel een aanrader waar het aankomt op het opschalen van Agile werken. Ook dit stuk van Steven Denning in Forbes over 'fake Agile' is wel een aanrader.

Als je dan kijkt naar jouw vraag, dan heb je het over een "IT afdeling", maar wat is in jouw ogen een IT afdeling? Wat zijn de beweegreden om één of juist meerdere afdelingen te hebben? Neem een bedrijf als Amazon. Oorspronkelijk een online retailer, maar inmiddels ook bijvoorbeeld de grootste speler in de cloud computing, waarmee ze hun meeste winst behalen. Dat is ooit voortgekomen uit een behoefte om teams veel autonomer en klantgerichter te kunnen laten werken. Je ziet daar in mijn ogen als gebruiker ook heel erg goed dat producten / diensten binnen helder gedefinieerde koppelpunten met de rest van de organisatie heel autonoom kunnen opereren en innoveren. Nieuwe diensten / producten / teams springen als paddestoelen uit de grond op basis van klant- / marktbehoeften en leveren snel en iteratief resultaat.

Vooropgesteld, dat is natuurlijk extreem moeilijk. De fout die ik vaak gemaakt zie worden in traditionele grote bedrijven en die hier in het topic ook bediscussieerd wordt is dat dit een analyse is die volledig buiten de uitvoerende teams heen gevoerd wordt door bijvoorbeeld een afdeling enterprise architectuur. Deze afdeling is volledig in z'n eigen papieren werkelijkheid gaan leven die geen enkel raakvlak meer heeft met hoe systemen en organisatie er daadwerkelijk uit zien. Ze werken centraal uit hoe je organisatie er uitziet qua teamindeling, vaak gecombineerd met iets als SAFe, waarbij dan kant en klare oplossingen teams in worden geduwd in plaats van dat uitvoerende teams en business samen kort iteratief werken aan (door)ontwikkeling van producten / diensten. Dat is eeuwig zonde.

Om je een voorbeeld te geven van hoe dat gaat, ik zit nu in een organisatie waar ik lead engineer in een (uiteraard veel te groot) team van pakweg 20 mensen dat verantwoordelijk is voor een vrij groot systeem dat in pakweg 2 decennia een allegaartje aan diensten en functionaliteiten heeft verzameld. Wij krijgen continu features op ons bord van de vorm 'voeg even deze informatie toe aan service X'.
Deze weigeren we categorisch en vragen naar het onderliggende probleem. Vaak blijkt dan de voorgestelde oplossing dat probleem helemaal niet op te lossen en bovendien ook nog vele ongewenste neveneffecten te hebben. Belangrijker is dat het veelal ook nog eens een innige verstrengelingen tussen meerdere systemen (en dus teams) geeft, waardoor de organisatie nog verder verlamt.
Gelukkig kunnen we zelf wel redelijk wat autonomie opeisen en kiezen we er dan voor om bijvoorbeeld nieuwe services op te tuigen, gaan we zelf shoppen in de organisatie bij andere teams die vermoedelijk relevant zijn qua koppelpunten en komen daar mooi geïsoleerde oplossingen uit.

Zo hebben we een tijdje terug zo'n dienst mooi geïsoleerd opgezet die nu een geheel eigen spin-off wordt met een geheel eigen team. Dat is in mijn ogen hoe je succesvol kunt blijven groeien als organisatie en dan maakt het aantal poppetjes dat onder een 'afdeling' valt niet zoveel uit. Als je echter de centraal gestuurde top-down aanpak wilt blijven hanteren, dan loop je echter heel snel tegen limieten en beperkingen aan.

[Furion2000]

@Mugwump Het was te lang en had het op de to-do list staan om te lezen, maar de to-do list was even verdwenen

Mooi geschreven, veel herkenning en die autonomie pakken is denk ik het belangrijkste punt wat ik eruit pak. Die autonomie op zowel techniek als organisatorisch.

@Hydra Turn the ship around zojuist klaar met lezen en moet zeggen dat dit een boek is om in de toekomst er vaker bij te pakken. Ik pas er nu al veel van toe en voel merkbaar het verschil.

Naast het boek the lean startup en wat goede gesprekken, moet ik zeggen dat ik het idee heb dat ik het duidelijker voor ogen heb. Als SM doe ik nagenoeg niks meer en zorg ik dat het team zelf de controle heeft e.g. mooi om te zien dat waar ik in het begin 'kort erop' zat om te zorgen dat resultaten behaald werden, spreek ik nu gewoon mijn visie uit van hoe we omgaan met zaken en het wordt opgepakt. We worden voelbaar beter en ik doe er minder voor. (stiekem eventjes iets meer door te investeren in deze kennis, maar dat betaald zich terug). Ook naar 'boven' toe zeg ik rakere dingen die mensen aan het denken zetten, dus hopelijk zet het zich voort

[Hydra]

Furion2000 schreef op maandag 10 juli 2023 @ 10:46:
@Hydra Turn the ship around zojuist klaar met lezen en moet zeggen dat dit een boek is om in de toekomst er vaker bij te pakken. Ik pas er nu al veel van toe en voel merkbaar het verschil.

Cool! En leuk dat je deze feedback geeft