Zeker grotere, al dan niet overheids- of financiële instellingen waarvan de bedrijfsvoering in meerdere mate IT en softwareontwikkeling bevat, leunen in de tijd van AI nog steeds op veilige werkwijzes zoals Scrum of SAFe. Hiervoor zijn producteigenaren en scrummasters aangenomen en processen ingericht die ervoor zorgen dat er volgens de opgestelde regels wordt gewerkt om aan interne of externe regelgeving te voldoen. Hierdoor worden werknemers wel technisch in staat gesteld door AI, maar in de praktijk kunnen ze nog steeds vastzitten in processen, overleggen en verwachtingen die ervoor zorgen dat de focus niet ligt op het volledig benutten van hun eigen kennis en de mogelijkheden die ze nu hebben. Zaken zoals dagelijkse stand-ups, refinements, afstemmingsoverleggen, etc. werkten voorheen goed omdat er een lang ontwikkelproces was, maar nu steeds minder goed.
Er zijn kernprincipes van softwareontwikkeling (de zogenaamde laws of software engineering) die dicteren dat je software in één keer goed moet ontwikkelen. Daar zijn processen zoals Scrum ook op ingestoken: er is een refinement nodig om erachter te komen wat de exacte specificaties zijn. Deze refinement heeft ook vaak verkennende processen of pre-refinements nodig. Dan zijn er vaak afstemmingsoverleggen met als doel blokkades wegnemen en tussentijds bijsturen. Deze structuur is niet meer logisch als je als ontwikkelaar met een opdracht aan een AI binnen een paar minuten een proefopstelling kunt opzetten of functionaliteit kunt implementeren. Sterker nog, het geven van deze opdrachten geeft vaak sneller weer wat de vereisten zouden moeten zijn en wat de blokkades zijn. Door de softwareontwikkelaar zelf in controle te laten zijn van dit totale proces (in plaats van dit in een team te beleggen) zorg je ervoor dat er beter kennisbehoud is bij ontwikkelaars. Ze weten namelijk precies waarom een idee wel of niet kan werken door dit soort oefeningen, en wanneer iets wel lukt is de drempel om het te implementeren vaak ook heel laag.
Vaak krijgen (ontwikkel)teams werk binnen vanuit een werkvoorraad die gevoed wordt door de organisatie en/of vanuit onderhouds- en beheerperspectief. Items op deze backlog kunnen snel verouderen en behoeven werk om op te stellen of bij te werken. Wanneer je vanuit een AI-geest ontwikkelt en kijkt vanuit mogelijkheden in plaats van historische vereisten, dan zou het logischer zijn om functionele beschrijvingen, redenen en verdere boekhouding die vanuit wijzigingen nodig is bij de code te houden in plaats van op een aparte werkvoorraad die vaak veel handmatig werk behoeft in beheertooling. In welke vorm dit moet zijn maakt niet veel uit. Je zou een wijzigingslogboek met zaken die je normaal in je werkitem schrijft (gebruikersverhalen of Gherkin bijvoorbeeld) in je repository kunnen noteren, zodat je waar nodig kunt voldoen aan processen die dergelijke documentatie vereisen. Ook geeft dit logboek inzicht in daadwerkelijk opgeleverd werk. Alle onderzoeken die wel gedaan worden maar uiteindelijk niet doorgevoerd worden zouden eventueel in een los logboek genoteerd kunnen worden. Door deze informatie uit systemen te halen en te noteren als pure tekst is het querybaar door AI en kan het snel inzichtelijk worden wat welke status heeft of wat momenteel de prioriteit zou moeten hebben. Het concept van inschattingspunten en planning kan losgelaten worden, want de menselijke waarde van die inschatting is verdwenen. Het heeft hierdoor niet heel veel zin meer om werk in te schatten.
Een Kanban-achtige werkwijze met een lijst aan onderwerpen kan bovenstaand proces voeden. Er is nog steeds een team nodig omdat er kennisoverdracht nodig is tussen teamleden, zodat deze elkaar kunnen vervangen en elkaars werk kunnen valideren. Er is nog steeds een vertaling nodig tussen de organisatie en het technische team door een soort producteigenaar, maar dit kan ook door een ontwikkelaar ingevuld worden. Mensen vanuit de organisatie zouden wensen direct op de lijst in de repository kunnen toevoegen met een prioriteit, of deze door AI laten bepalen aan de hand van zakelijke afwegingen.
Hierdoor kunnen teams kleiner worden (minder bijkomende lasten), er komt meer verantwoordelijkheid te liggen bij ontwikkelaars en ontwikkelaars kunnen zich meer opstellen als architecten, minder als uitvoerende kracht. Hierdoor gaat de productie en snelheid (wendbaarheid) van een team flink omhoog.
Wanneer ontwikkelaars meer als architecten werken, werk direct bij teams binnenkomt en de verantwoordelijkheid van ontwikkelaars stijgt, groeit een bedrijf kwalitatief als softwareproducerend bedrijf. Dit betekent dat het minder logisch is om te kiezen voor standaardoplossingen. Standaardoplossingen hebben namelijk vaak specialistisch personeel nodig (denk aan Mendix, OutSystems, SAP, contentmanagementsystemen etc.), hebben vaak hoge licentiekosten en trajecten naar nieuwe versies zijn vaak zwaar. Wanneer we echt wendbare ontwikkelteams van architecten hebben, zijn we in staat snel deze producten uit te faseren en te vervangen met opensourcevarianten die voortkomen uit de ontwikkelende AI-markt. Het is een kwestie van tijd voordat er opensourcevarianten van standaardoplossingen als paddenstoelen uit de grond zullen schieten. Welk bedrijf kan adopteren en hierop kan integreren zal financiële voordelen en voordelen in wendbaarheid behalen. Je ziet nu al dat hele projecten naar Rust nagebouwd worden of dat hele pakketten zoals Adobe Creative Cloud worden nagebouwd in Rust.