Agile-software-ontwikkeling is een conceptueel raamwerk voor het uitvoeren van software-ontwikkelingsprojecten als alternatief voor traditionele methodes. Oké, leuk, maar wat moeten juristen daarmee? Met die gedachte was ik gisteren bij de najaarsvergadering van de NVvIR.
Agile coach Serge Beaumont trapte af met een introductie over “Enabling Agile”. Zijn bijna-openingszin “Maar het contract zegt” somde de kern mooi op. Het contract bepaalt hoe je mág werken, en als het contract geen rekening houdt met agile, dan heb je een probleem. Hij noemt meteen al een kernpunt: early termination, oftewel tussentijds opzeggen als het wel goed is (of als je er niet meer uitkomt samen).
Veel contracten gaan uit van wat Serge “productdenken” noemt: je legt vast waar je heen wilt, en de implementatie is dan de route daarheen. Maar Agile biedt een veel meer moving target, je weet nog niet precies waar je gaat komen. En dat is lastig: je kunt wel netjes vastleggen welke producteigenschappen er moeten komen, maar Agile focust op de doelen voor de stakeholders, het waaróm van die eigenschappen. En dat is veel moeilijker om op papier te krijgen.
Dat moving target betekent dus ook continu aanpassen gaande de rit. Dat is veel lastiger in het watervalmodel, omdat dat uitgaat van “eerst specificeren dan bouwen”. Gebruikers die niet weten wat ze willen, zijn irritant – in dat model. En helemaal moeilijk wordt het als Agile eigenlijk niet goed wordt begrepen (of geaccepteerd) door het management, want je kunt als Agile team snel dingen tegenkomen die jouw macht/bevoegdheid te buiten gaan en dat moet dan op een hoger niveau worden opgelost.
Early termination impliceert een andere manier van werken. Je probeert zo snel mogelijk iets te bouwen dat eigenlijk werkt, en dat wordt steeds uitgebreider en beter. Als illustratie: je begint met een potloodtekening, zet die dan in waterverf, daarna komt er wellicht een achtergrondillustratie en uiteindelijk kun je dingen in de inkt zetten. Of niet. Het is dus niet meer “wanneer is het af” maar “wat is wanneer klaar” en dan kiezen “zo is het wel genoeg”. Dit vereist wel dat je met de scope kunt variëren.
Daarna sprak Rutger Alsbach over de juridische kant: agile contracteren. Hij raadde overigens het rechtsboven gelinkte boek over Agile aan. Na een korte bespreking over de tekortkomingen van de watervalmethode legde hij de vinger op een aantal gevoelige punten bij Agile. Mooi punt vond ik, er komt steeds wat nieuws bij dus hoe bepaal je nu wat er geleverd moet worden? En continu wijzigen de prioriteiten: hoe kun je dan ooit iemand wanprestatie verwijten of in gebreke stellen?
Oh, nog een leuke: wanneer wordt de betaling getriggerd? Je kunt het niet aan oplevering ophangen want je weet niet vooraf wanneer wat opgeleverd wordt. Meten op uren kan altijd maar is niet altijd wenselijk. Een alternatief is factureren per functiepunt (pdf).
Grootste juridische beer op de weg: je kunt niet werken met Agile én de klassieke RfP/watervalprocedure. En dat blijkt een groot probleem in de praktijk want de klant is zó gewend aan die klassieke procedure dat ze er niet eens bij stilstaan dat het nu compleet anders gaat werken. Maar ook het omgekeerde is een risico: al te makkelijk werken met vage contractjes en onduidelijke einddoelen gaat ook tot problemen leiden. Ik vond tussendoor googelend nog deze goede contractsprimer over Agile contracten. Leesvoer voor later.
Na de pauze vertelde organisatiepsycholoog Hanneke Grutterink over werken in teams, een belangrijk deel van Agile ontwikkeling. Het idee van “scrum verbetert je teamprestatie” is alleen succesvol als je aan een aantal voorwaarden voldoet voor crossfunctionele teams. Dit zijn: betrokkenheid, coördinatie, kennisdelen en ondersteunende structuur. Bij betrokkenheid is een grote valkuil bijvoorbeeld dat mensen in meerdere teams tegelijk zitten, of dat de beloningsstructuur niet goed is. Bij coördinatie is een goede scrummaster (teamleider) essentieel. Kennisdelen vereist vooral een veilige omgeving waarbinnen mensen kritisch durven te zijn (wat natuurlijk ook weer op de teamleider terugkomt maar ook de organisatie).
Als laatste sprak ICT-advocaat Juliette van Balen. Zij benoemde als jurist de speerpunten in het contract: resultaat, prijs, aansprakelijkheid, garanties en beëindiging (exit). Maar, zo vroeg de zaal, waar is het proces dan, de samenwerking die zo cruciaal is in het Agile proces? Daarvoor verwees Juliette naar de vrij beschikbare modellen voor Agile contracten. De collega’s van Bird & Bird geven de nodige kennis weg in hun position paper met handvaten voor Agile contracten. Ook dit Franstalige Creative Commons-contract biedt perspectieven maar is gek genoeg niet voor commercieel gebruik gelicentieerd (parbleu). Juliettes presentatie bevatte nog vele nuttige aandachtspunten, deze komt binnenkort online.
Daarna ontstond een interessante discussie of Agile wel juridisch haalbaar is. Het verschil in inzicht ging met name over de vraag of je het resultaat voldoende bepaalbaar kunt omschrijven – waarbij er een wereld van verschil bleek te zijn tussen mensen die “ik wil een huis” als resultaat zien en mensen die “ik wil wonen” zien als resultaat. En dat is voor mij de belangrijkste les van Agile: de andere manier van kíjken naar softwareontwikkeling.
Arnoud
Leuk artikel! Een aardige benadering zag ik eens bij het muzieknoten programma lilypond, waarbij je een feature kon kopen. Je betaalde dus voor een enkele “user story”, en die kreeg je dan niet apart in licentie, maar werd gewoon aan de open source code toegevoegd voor iedereen: een typisch voorbeeld van software maken als dienstverlening.
Als je een softwareprodukt maakt als standaard pakket, en je werkt Agile, dan kun je iedere keer een wat uitgebreider en dus concureerender produkt in de markt zetten. Je hele keten moet daar dan wel op ingesteld worden, iets wat niet altijd makkelijk is binnen grote organisaties, die veel meer gewend zijn in grote blokken updates te krijgen. Elke week een nieuwe release met een enkel extra toetertje of belletje hier of daar zijn ze niet gewend, en leidt dan tot absurd veel overhead.
Het vereist een ander denkmodel: je wil als klant meestal niet een product maar een dienst, en uiteindelijk zal een bedrijf dan ook in het geheel niet meer het product “software” aanbieden, maar de onderliggende dienst, wij houden je boekhouding bij, of je patientenadministratie, oid, en je betaald gewoon voor die dienst, niet voor de software die die dienstverlener daarvoor ontwikkeld en gebruikt.
Een interessante analyse van de juridische perspectieven van Agile softwareontwikkeling. Het is duidelijk dat dit onderwerp meer aandacht verdient, aangezien de wettelijke aspecten in deze context vaak complex zijn. Het is cruciaal om de balans te vinden tussen flexibiliteit en juridische helderheid in Agile projecten.
-edit: Dag ChatGPT!