Daar waar Agile ontwikkelmethodieken bij maatwerksoftware vaak verrassend goed werken, is het minder goed gesteld met de contractvorming rondom dergelijke trajecten. Wat vooral een probleem is in die gevallen dat een Agile ontwikkeltraject mislukt.
Als eerste zijn it-contracten die aansluiten bij Agile zeer zeldzaam. In de praktijk wordt vaak naar contractdocumenten gegrepen die ooit bedoeld waren voor meer traditionele ontwikkeltrajecten. Enerzijds omdat standaardcontracten in veel organisaties het beleid zijn en die ooit opgesteld zijn voordat meer iteratieve ontwikkelmethodieken in zwang raakten. Anderzijds omdat veel it-juristen, maar ook inkopers, Agile ontwikkelmethodieken eigenlijk per definitie onjuist vinden. Maar ook omdat het Agile-manifest onder andere het volgende bevat:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Werkende software
Een contract hebben wordt daarbij door ontwikkelaars als ‘niet Agile’ ervaren. En dat is niet eens zo’n vreemde gedachte, want veel contracten hebben een focus op juist die onderwerpen waar men in het Agile-gedachtengoed vanaf wil. Vooraf gedefinieerde specificaties, uitgebreide planningen en budgetten, focus op processen. Want al die andere zaken zijn lastig te objectiveren. Want wat is ‘m ‘werkende software’ nu eigenlijk?
En dat is een reden, naast gewone menselijke koudwatervrees, waarom veel juristen instinctief een afkeer hebben van Agile methodieken. Ons denken wordt nu eenmaal bepaald door de vraag ‘hoe leg ik een rechter uit dat ik niet gekregen heb wat ik mocht verwachten als het project fout gaat?’. Een specificatie vooraf is de meest tastbare vastlegging van de redelijke verwachtingen van de afnemer. Maar één van de grote problemen van traditionele ontwikkelmethoden is nu juist dat de specificaties, die bij aanvang misschien klopten, bij oplevering vaak al niet meer overeengekomen met de veranderde organisatiebehoeften. Wat betekent dat meer klassieke ontwikkelmethoden haast onherroepelijk in iets resulteren wat niet meer aansluit bij de behoeften en er dus onvrede in de relatie sluipt. En Agile methoden worden juist gekenmerkt door het ontbreken van die vergaand uitgewerkte specificatie vooraf.
Ingewikkelde dossiers
In de praktijk komen echte Agile contracten minder vaak voor dan Agile projecten, en worden er vaak ‘watervalcontracten’ gehanteerd. En ik denk dat bovenstaande factoren daar een rol bij spelen. En voor wie zich afvraagt of dat een probleem is: ja, dat is een probleem. Want als partijen in werkelijkheid heel anders met elkaar omgegaan zijn (want Agile) dan ze gecontracteerd hebben (klassiek), dan zal de rechter in een geschil het hele contract toch anders bezien of zelfs terzijde schuiven, met alle gevolgen van dien. Ik zou zelfs willen stellen dat geen contract beter is bij Agile dan een ‘watervalcontract’. Want dan zitten partijen in ieder geval niet schijnafspraken en –zekerheden die bij een uiteindelijke rechtszaak niet overeind blijven, en had men de kosten van het opstellen van het contract zich beter kunnen besparen. Niet dat het niet hebben van een contract nu heel wenselijk is, rechtszaken over mislukte ict-projecten hebben notoir onvoorspelbare uitkomsten omdat het vaak ingewikkelde dossiers zijn en de ontwikkelingen in de ict maar beperkt aansluiten bij de belevingswereld van de rechterlijke macht. Voor wie het ook redelijkerwijze niet mogelijk is om de ontwikkelingen in iedere bedrijfstak, zeker snel veranderende zoals de ict, bij te houden. Een contract is bij ict-geschillen, meer nog dan anders, een belangrijke leidraad voor rechters bij de geschilbeslechting. In de praktijk zijn ict-contracten om die reden dan ook relatief uitgebreid.
Omgekeerd is hanteren van Agile geen vrijbrief voor het afleveren broddelwerk. Of een vrijbrief om geen specificaties te hebben. Juist het vakmanschap van softwareontwikkelaars waar Agile methodieken zich zo op richten vereist het bestaan van specificaties en andere documenten. Alleen misschien als onderdeel van wat opgeleverd moet worden aan het einde van een iteratie en bij sommige methoden wordt dit per iteratie vooraf vastgelegd in de documentatie. Waartegen getest en geaccepteerd kan worden. En toch zie je dat Agile in contracten gebruikt worden als aanleiding om de leverancier te ontslaan van zijn verantwoordelijkheden. Bijvoorbeeld in de algemene voorwaarden van de branchevereniging Nederland ICT waarin gesteld wordt dat bij Agile ontwikkelmethoden de afnemer aanvaardt dat de ontwikkelde software af kan wijken van de specificaties.
Bordje van afnemer
Een andere benadering in een soortgelijke lijn die ik wel eens tegen ben gekomen is om Agile projecten maar weer als uurtje-factuurtje projecten te contracteren. Waarmee we zo’n dertig jaar aan best practices in de ict overboord gooien en het risico volledig op het bordje van de afnemer leggen.
Een goed Agile contract bevat een erkenning dat de afnemende partij niet goed in staat zal zijn de verwachtingen bij aanvang te formuleren en dat een onderdeel van de dienst de zoektocht is naar die verwachtingen (al zal er vaak nog wel een vast te leggen organisatiedoel zijn, maar dat kan wel te abstract zijn om veel baat te bieden). De uitruil van de zekerheid dat iets conform specificatie gebouwd wordt tegen een grotere kans dat wat uiteindelijk geleverd wordt beter aansluit op de organisatiebehoefte kan heel vaak door de commerciële afspraken opgevangen worden. Zo zijn er succesvolle maatwerkbouwers die op basis van Scrum (een veelgebruikte Agile methodiek) werken en hun afnemers de mogelijkheid geven om bij iedere sprint de stekker uit de relatie te trekken. Wat betekent dat het vele malen makkelijker is om ten halve te keren als het gevoel ontstaat dat er ten hele gedwaald gaat worden. Hoe dan ook, met gecombineerde juridische en commerciële creativiteit kan er een contract ontstaan wat juist de gemeenschappelijke doelstelling van werkende software in overzichtelijke stappen reflecteert.
De algemene voorwaarde van de branchevereniging ICT die genoemd wordt is (naar mijn bescheiden mening) een beetje bizar.
Als vragende partij stel ik een zak met geld beschikbaar om een product te laten ontwikkelen, en dan moet ik dus aanvaarden dat ik niet krijg wat ik gevraagd heb ???
Ik zou de leden van deze branchevereniging willen vragen: als je 3 ton uitgeeft voor een huis, en je aannemer maakt niet wat jij gespecificeerd hebt, hoe zou jij je dan voelen? (uiteraard er vanuit gaand dat de specs realistisch zijn etc)
Is het dan zo vreemd dat een opdrachtgever in de ICT deze aspecten contractueel vast wil leggen?
Hmm… de contractuele inertie versus de gewenste wendbaarheid is altijd een leuke als we kijken naar de juridische-economische aansturing. Ik moet dan ook een beetje lachen om het hele verhaal als ik kijk naar idee van ‘vrijwilligerscontract’ van het eenzijdige denken.
Aangaande ‘quid pro quo’ principe vraag ik me dan af welke verplichtingen er precies zijn als er uiteindelijk geen geldelijke vergoeding tegenover de inspanningsverplichting staat. Kortom, je kunt een prachtig contract hebben maar de waarde ervan is soms het papier niet waard.
Agile contract?
Wie dit leest is gek 🙂
Wat mij telkens weer blijft verbazen is het missen van dat ene alles omvattende gegeven in en met IT/ICT dat men maar telkens niet wil oppakken.
Elke stap in en met IT is voor 100% voorspelbaar.
Het is eenvoudig. Alles in en met IT, ook ontwikkeltrajecten, vanaf de kleinste stap tot grootste traject is afhankelijk van ‘Value’. Ongeacht of ‘Value’ nu een getal, routine, gebaar is. Zo is ook je doel, tenmiste als het goed is, volkomen bekend.
Immers, elke stap die je in en met IT zet heeft een vooraf gesteld doel. Ben aan het programmeren dan weet je dat maar wil je als gebruiker je tablet gebruiken, zul je met je wijsvinger op de knop van je tablet moeten drukken. (Value)
Als je hele ingewikkelde dingen gaat bedenken voor iets zoals ontwikkelen, en je gaat daar methodieken voor bedenken die niet lineair zijn? Krijg je dit soort schrijfsels. Tel hierbij op dat wanneer commercie ergens de overhand in krijgt je al snel IT naar de achtergrond verdrijft, lees, heel veel hoge rekeningen gaat genereren, dan krijg je dus weer precies waarvoor je IT niet in zet.
Agile, Lean, Scrum, Panorama, Nieuwe Revu, Veronicablad…….
Als je de metodiek niet naadloos aanpast op de lineariteit van IT, krijg je dus dit. Heel veel hele hoge rekeningen, weinig ROI en weinig resultaten.
En die contracten kennen wij toch allemaal wel?
Scrum/agile is niet voor alle projecten nodig of wenselijk.
Misschien verklaart dit waarom sommige mensen afwijzend reageren.
Mijn ervaring bij projecten met meer research, onduidelijke specificaties, en/of lange doorlooptijd hebben is dat een lean aanpak kan helpen om de klant bij het project te betrekken en zo tot bruikbare value te komen, al in een vroegtijdig stadium.
Agile versus waterval etc is ook niet de discussie in dit artikel, maar hoe je een goed contract opstelt bij agile.
Concreet: een lopend project wordt agile uitgevoerd, maar binnen een fixedprice offerte. Je krijgt dan rare constructies, namelijk: een bepaalde feature mag eigenlijk niet gebouwd worden want het is niet geoffreerd, terwijl het NIET bouwen nu tot veel meer werk leidt dat bovendien in een RFC alsnog ongedaan moet worden gemaakt (conversie etc…).
Agile kan je alleen in relatie met de klant gebruiken als er openheid en vertrouwen is. Vertrouwen kan groeien, openheid is een vereiste.