Met het achter ons laten van silo applicaties en het omarmen van publieke cloud technologie lijkt er ook een trend te ontstaan dat it'ers steeds meer van meer dingen moeten weten. Vroeger was het simpel: je bent back-end ontwikkelaar, front-end ontwikkelaar of integratie ontwikkelaar. En binnen deze hokjes specialiseerde je vaak weer. Daar red je het nu niet meer mee!
Als we kijken naar de lijst van bouwblokken die beschikbaar zijn in Microsoft Azure’s Platform as a Service is dat best schrikken. Wat een lijst! Het aantal services neemt ook nog steeds toe. De ontwikkelingen zijn met de komst van cloud computing in een enorme stroomversnelling terecht gekomen. Agile en snelle innovatie gaan kennelijk echt hand in hand. Big data, internet of things, machine learning, bot framework; het zijn allemaal vakgebieden op zich, maar we hebben het wel stuk voor stuk nodig om er moderne oplossingen mee te creëren. Ga er maar aan staan!
Agile oplossingen realiseren
Ook het creëren van oplossingen op de voor ons op een Agile manier beschikbaar gestelde innovatieve cloud platforms gebeurt tegenwoordig meestal op een Agile manier: Eén of meerdere Scrum-teams die aan producten ontwikkelen die telkens verder evolueren aan de hand van realtime business input en een vaak experimentele aanpak. Deze teams zijn multi-disciplinair.
Dat betekent dat elk team in staat is om end-to-end een complete oplossing of deelproduct te realiseren. Een product dat als geheel in productie kan. Inclusief database, back-end logica, front-end en alle integraties. En dat men in staat moet zijn om taken van elkaar over te nemen, elkaar te helpen. Het team levert de oplossing. Men is zo min mogelijk afhankelijk van individuele ’towers of knowledge’. Die schalen namelijk niet. En zijn ook single points of failure.
Domein expertise verschuift
Voor hard-core specialisten is dit een grote uitdaging. In plaats van puur bezig te zijn met een bepaalde technologie, bijvoorbeeld SQL Server, Azure Stream Analytics of .Net ontwikkeling, heeft de ontwikkelaar ook verstand nodig van de oplossing die er gebouwd moet worden én is hands-on kennis van de aanpalende technologieën nodig. Er wordt aan hele stories gewerkt met verschillende mensen en het team moet immers leveren. De gereedschapskist blijkt al snel te klein. Wat een enorme hoeveelheid componenten en technologische doorbraken. Hoe houdt men de ontwikkelingen bij?
Pair programming is hierbij een goed middel om de kennis te delen. En natuurlijk de gewone Scrum rituelen. Tegelijkertijd ontwikkelt het team zich tot een kenniscentrum voor een specifiek business domein. Dat is erg waardevol en blijkt in de praktijk een grote driver voor het sneller kunnen leveren van waardevolle oplossingen. Verticaal specialiseren, als team. Ongeacht de te gebruiken technologie.
Terug in je hokje?
Nee. We eisen veel van de ontwikkelaar en ze worden daar ook prima voor betaald. In plaats van specialistische individuen, is teamontwikkeling veel effectiever. Leren van elkaar, elkaars taken kunnen overnemen, bredere kennis opdoen maar tevens verdieping zoeken. Continue blijven leren hoewel het soms lijkt alsof ‘we’re drinking from the firehose’ (zoals de Amerikanen dat zo mooi zeggen).
We hebben meer generalisten nodig, die voor 80 procent uit de voeten kunnen met alle componenten. En voor de overgebleven 20 procent hebben we dan nog een aantal lone wolves. De towers of knowledge. De echte nerds. Af en toe laten we ze uit hun hokje, en mogen ze hun kunstje doen.
He ja. Pair programming voor kennisdeling. Was oorspronkelijk bedoeld t.b.v. kwaliteit, maar toen men erachter kwam dat het natuurlijk de velocity in de weg zit, lieten men het meteen weer vallen.
Met z’n allen in de heksenkring, scrum zombies met T profielen, maar dan zonder tower, “want die schalen namelijk niet”. Flink de druk op de snelle levering en oh wat zal er toch een innovatieve oplossing uitrollen. Soort van de back-end logica van mijn achterwerk.
Maar goed, altijd beter dan lezen over de gevaren van Excel, de tips van Salomons moeder en onze printproblemen in het grote HP cartridge topic.
Herkenbaar, en voor mij daarmee ook een punt van zorg en aandacht.
Doordat het aantal generalisten toeneemt, worden veel tools en achterliggende gedachten / technieken niet optimaal en efficiënt ingezet. Ook de integratie van de tools en technieken gaat vaak mank of op de verkeerde manier.
Vanuit de agile gedachte heb je dan wel snel een “Minimal Viable Product”, maar de (vaak ondergeschoven) “technical debt” neemt in een razend tempo toe.
Dit maakt het zoeken naar de juiste mensen voor je organisatie heel lastig. Je wil inderdaad geen die-hard specialisten. Een T-profiel is eigenlijk weer te oppervlakkig. Zelf denk ik altijd meer driehoek-model (een dichte V zeg maar). Een brede basis, specialisatie (de punt van de V) maar ook veel kennis van de aanpalende disciplines en omgevingen.
Vandaar dat men naar ‘generalisten’ zoekt die op alle specialisaties 100% scoren. En dan ook nog eens 100% op communicatieve vaardigheden uiteraard.
Ik krijg de indruk dat we momenteel over peak-scrum heen zijn. En dat is niet erg, want men heeft het van een aantal handige zaken (eXtreme Programming destijds) in een soort methodologie en geloof ongevormd.
Het belangrijkste waar het om gaat is teamontwikkeling, zeker gezien de grote complexiteit die er nu is. Bij complexe producten en relatief kleine teams zullen de specialismen goed op elkaar afgestemd moeten zijn waardoor er balans in het team ontstaat. Meer generalisten is volgens mij niet de oplossing.
Goed artikel weer Gijs.
Ik probeer op de drie grote platformen bij te blijven (Azure, AWS, GCP), maar ik ben kansloos. Iedere developer word wat meer een DevOpser en de tradionele Ops uit DevOps moet zichzelf opnieuw uitvinden. Wat ik bedoel te zeggen: Ontwikkelaars doen steeds meer dan code genereren alleen en gebruiken daarvoor heel veel tools, beheerders hebben echter weinig verstand van code en als ze coderen is dat van met CLI tools, hoe dan ook beide partijen hebben een hoop te leren om bij te blijven.
Maar ook als je kijkt naar de Ghetto waarin front-end ontwikkelaars zich moeten verdiepen (lees: Javascript frameworks), dan is een goede ontwikkelaar zijn gewicht in goud waard…
Heel veul hokjes dus!
Goeie discussie. Wat vinden jullie van Pa Va Ke’s response? Eens? Deels?
Ik denk dat het zo moeilijk lijkt omdat het oude denken ovet IT centraal staat.
Nu IT meer en meer comodity wordt moeten de IT’ers de business in ondersteund door integratie specialisten.
Als bedrijf interesseert het me niet of we Azure, B-zure, of C-zure gebruken. Het blijft een zure bedoeling met Microzacht.
Business staat centraal en ik zou bedrijven juist adviseren om niet achter de volgende hype aan te rennen omdat iedereen dat doet. Kijk wat Sharepoint heeft gebracht…..veel geld voor Microzacht.
Een platform als Box.com wat richt op integreren. daar ligt een kracht.