Ontwikkeling en onderhoud van software via Agile methodieken komen we steeds meer en meer tegen. Veel IT organisaties worden tegenwoordig geconfronteerd met leveranciers die aanbieden hun werk iteratief uit te zullen voeren. Ook omgekeerd zien we een tendens dat IT opdrachtgevers van leveranciers eisen dat men iteratief werkt en elke iteratie of sprint werkende software oplevert.
Maar wat betekent dit voor een IT opdrachtgever organisatie? Welke veranderingen in mindset moet men zich dan aanmeten?
Agile methodieken worden meer en meer gemeengoed en de enige manier om software te ontwikkelen en onderhouden in deze snel veranderende economie!
Met de snel veranderende economie wordt de noodzaak voor bedrijven om snel in te kunnen spelen op deze veranderingen in de markt ook steeds groter. Dit betekent dat een snellere ‘Time to Market’ wordt gevraagd aan de IT organisaties door de klantorganisaties.
Er is wetenschappelijk aangetoond dat de doorlooptijd die een wens van een klantorganisatie erover doet om in productie geïmplementeerd te worden twee maal de gemiddelde doorlooptijd van een IT project of release is in de IT organisatie. Dat betekent als die gemiddelde doorlooptijd van een IT project 6 maanden is, dat een wens gemiddeld een ‘Time to Market’ heeft van één jaar! Dat kan niet meer.
In de huidige crisis situatie is het snellere ‘Time to market’ wat de klantorganisatie wil. Daaraan ten grondslag liggen kosten en doorlooptijd besparingen. Verbeterde kwaliteit en verminderde ‘technical debt’ is een leuk neven effect daarbij.
Wat zijn de implicaties voor een IT opdrachtgever organisatie
IT opdrachtgever organisaties worden geconfronteerd met drie zogenaamde ‘Paradigm shifts’ of noodzakelijke veranderingen van gedachtegang:
Als eerste is er de ‘Paradigm shift’ in denken van ‘plan driven’ naar ‘value driven’ werken en hoe om te gaan met project toleranties:

Dit betekent dat we niet meer de scope vastzetten en in beton beitelen, maar dat we juist de kosten en doorlooptijd fixeren en de scope variabel maken. Als ik dit aan mensen vertel griezelen zij meestal en zeggen dat je dan een carte blanche geeft aan een project en niet weet wat je gaat krijgen (een gevoel van verlies van controle). Lees hoe dat wordt afgevangen in mijn andere blog post: ‘Agile misverstand nummer 1: Je kunt agile projecten niet begroten en plannen’
Dit principe wordt het beste ondersteund als we niet meer praten over black box projecten met een vaste scope, maar over transparante product teams die een continue stroom aan features (de scope uit de projecten opgeknipt en gegoten in een product backlog) produceren. Het is te allen tijde helder voor alle partijen welke features in welke sprint worden geproduceerd en wat de meest actuele volgorde van de features in de product backlog is. Het geeft zowel opdrachtgever als leverancier ook meer focus.
- de tweede verandering is er een voor de project managers. De aard van hun projecten gaat namelijk meer van het ‘Management by Exception’ principe zoals nu meer wordt gehanteerd, naar dagelijkse regie met zeer veel discipline (of zij nu zelf het proces aansturen als Scrum Master, of een aparte Scrum Master hebben).
Zelf de dagelijkse regie op zich nemen betekent bepalen welke content gaat in welke sprint, gezamenlijk met business, IT en leverancier steeds verbeteren en productiever worden. Dit betekent voor diegene die dit doet het opbrengen van veel meer discipline dan voorheen en een veel grotere inspanning per project. Door nu gezamenlijk met Business en IT en leverancier elke sprint te bepalen wat er gerealiseerd gaat worden, creëer je een zeer transparant proces. Je gaat van ‘black box’ naar ‘glass box’ ontwikkelen en van ‘Managing’ naar ‘Directing’.
Als project managers gewend zijn aan die rol als Demand Manager, en ‘Management by Exception’, is de kans groot dat zij het micro management, noodzakelijk voor de dagelijkse aansturing van een iteratief project, niet aan kunnen, of het niet bij hun functie vinden passen. Dat is de reden dat je vaak ziet dat andere rollen in de organisatie de Scrum Master rol op zich nemen als analisten en lead engineers.
De project manager heeft in klassieke organisaties nog steeds een rol in het managen van de omgeving en het team afschermen van de invloeden van die omgeving. Hierbij moet je denken aan stuurgroepen, Juridische en Compliancy afdelingen, financiële ‘toll gates’, rapportages aan programma management enz.. De project manager die wel de rol van Scrum Master op zich neemt zal echter geen 10 projecten tegelijk meer kunnen managen, wat ik wel tegenkom in de praktijk. Dus een goed HR beleid is noodzakelijk als je dit soort veranderingen inzet.
- De derde verschuiving of verandering is het formeren en smeden van één team uit de Business, IT afdeling en leverancier. Analoog daaraan een stroom van eisen die top down consistent met elkaar zijn. Dus Businesseisen vanuit de Business die vertalen in Systeemeisen op IT afdelingsniveau, naar kleine brokken werk die door een leverancier zelfs naar een offshore partij gestuurd kunnen worden. Dit vergt intensieve face to face samenwerking en een zeer goede kennis van definiëren van eisen op alle niveaus. In beide gevallen weer: grote transparantie!
Conclusie
Goede agile projecten dan wel trajecten kenmerken zich door transparantie in wat er moet gebeuren, en wanneer, over alle linies heen. Ook vergt het een goede samenwerking tussen alle partijen tot een sterke voorkeur naar partnership. Dit komt ook tot uiting in de vorm van contracten die partijen aangaan als het gaat om een agile samenwerking. In deze contracten komt meer en meer te staan hóe men met elkaar samenwerkt, versus dat erin staat wát men gaat realiseren samen.