Zorgplicht ICT leverancier bij Agile softwareontwikkeling

[vc_row el_class=”.artikel”][vc_column][vc_column_text]

Softwareontwikkeling op basis van de 12 uitgangspunten van het Agile Manifesto is voor veel softwareontwikkelaars standaard geworden. Agile softwareontwikkeling biedt de klant veel voordelen, zo is de gedachte. Snel werkende software opleveren, in een vroeg stadium inspelen op nieuwe wensen en voortschrijdende inzichten, zijn veel gehoorde aanprijzingen van Agile softwareontwikkeling.

Veel softwareontwikkelaars zijn zich in grote mate onbewust van de juridische risico’s die aan Agile werken zijn verbonden. Agile contracten blinken vaak niet uit in helderheid.  De focus ligt immers niet op contractsonderhandelingen maar op productie van werkende software. Tijd is een schaars goed en dat gebruik je niet voor ellenlange onderhangelingen of requirementanalyses. Van een Agile contract kan dan ook niet veel worden verwacht in de praktijk. Juist niet omdat voorafgaand aan de start het niet helder is waar het project zal eindigen. Bij een geschil tussen de opdrachtgever en de softwareontwikkelaar zal de ontwikkelaar dan ook vooral worden afgerekend op zijn zorgplicht. Heeft de softwareontwikkelaar gehandeld zoals van een redelijk bekwaam softwareontwikkelaar mocht worden verwacht? Heeft de softwareontwikkelaar voldoende oog gehad voor de redelijke belangen van de opdrachtgever? Op deze vragen zal in een procedure door een rechter of arbiter antwoord gegeven moeten worden. In dit artikel wil ik enkele relevante punten benoemen waarop een Softwareontwikkelaar bedacht moet zijn.

1. Schattingen

Veel softwareontwikkelaars geven bij de start van een project een inschatting van het aantal benodigde uren. Of als de klant een vast budget heeft, welke functionaliteit met dat budget kan worden gerealiseerd. Vanuit de opdrachtgever is deze wens begrijpelijk. Immers wil iedere opdrachtgever vooraf enige zekerheid over de verhouding tussen het budget en de daarmee te realiseren functionaliteit. De softwareontwikkelaar kan zich met een dergelijke schatting snel op glad ijs begeven. Voortschrijdend inzicht is bij Agile werken eerder regel dan uitzondering. Eerder gedane schattingen kunnen daardoor achterhaald raken, terwijl de opdrachtgever er nog steeds van uit gaat dat de schatting realistisch is. Uiteindelijk zal dit resulteren in een teleurgestelde opdrachtgever omdat de schatting achteraf niet realistisch was. Een bron voor conflicten is daarmee een feit.

Wordt er gewerkt met schattingen dan is het van groot belang dat de softwareontwikkelaar met enige regelmaat de status van deze schatting communiceert met de opdrachtgever. In ieder geval op het moment dat tijdens de ontwikkeling voortschrijdend inzicht wordt geconstateerd. Een goed moment om een statusupdate te geven is tijdens de sprintreview. Ontwikkelsnelheid en complexiteit kunnen dan afgezet worden tegen de schattingen en aannames die vooraf daarover zijn gedaan. De opdrachtgever heeft zo voldoende mogelijkheden om het project bij te sturen en kan verantwoorde keuzes maken over de inzet van het budget. Wordt deze mogelijkheid de opdrachtgever onthouden, dan ligt een schending van de zorgplicht al snel op de loer.

Worden er bij de schatting punten gesignaleerd die niet goed of volledig zijn in te schatten, dan moet dit duidelijk vermeld worden. Het is niet alleen van belang deze risico’s te benoemen maar ook de eventuele consequenties te omschrijven. Als het risico zich voordoet, wat kan dit betekenen voor de schatting? Een duidelijke risicobenoeming in de schatting geeft de opdrachtgever de mogelijkheid verantwoorde keuzes te maken. Doen de risico’s zich tijdens de ontwikkeling daadwerkelijk voor? Communiceer deze dan direct naar de opdrachtgever. Ga er niet vanuit dat de opdrachtgever ook wel begrijpt dat het risico zich heeft voor gedaan en wat de gevolgen daar van zijn.

2. Verwachtingsmanagement

In het verlengde hiervan ligt de taak van verwachtingsmanagement die de softwareontwikkelaar goed moet uitvoeren. Juist bij Agile werken is er vaak sprake van veranderende doelen en uitgangspunten. Een opdrachtgever is meestal niet in staat om de gevolgen van deze scopewijzigingen (goed) te overzien. De softwareleverancier is dus verantwoordelijk om er voor te zorgen dat de opdrachtgever realistische verwachtingen heeft en moet deze verwachtingen zo nodig bijsturen. Uit rechtspraak blijkt dat verwachtingsmanagement vooral ziet op:

  1. de kosten van het project;
  2. de doorlooptijd; en
  3. de resultaten van het project.

Zodra op een van deze punten veranderingen optreden tijdens het project, dan moet de softwareontwikkelaar de opdrachtgever hierover informeren, bijvoorbeeld tijdens de project- en/of stuurgroepvergaderingen. Het is daarbij zeer aan te bevelen dit goed te documenteren.

3. Ervaring met Agile?

Een ander relevant punt met betrekking tot de zorgplicht, is de ervaring van Agile werken van de opdrachtgever. De softwareontwikkelaar moet vooraf vaststellen of deze ervaring er is en zo ja bij welke personen van de opdrachtgever. Agile softwareontwikkeling komt namelijk pas goed tot zijn recht als alle betrokken personen zich bewust zijn van hun rol en bijbehorende taken. Heeft de opdrachtgever nauwelijks ervaring met Agile werken, overweeg dan als softwareontwikkelaar om niet volgens de Agile methode te gaan ontwikkelen. De kans op strubbelingen tijdens de ontwikkeling is dan erg groot.

Als er wel wordt gewerkt met de Agile methode, zorg dan voor de volgende zaken:

  • Geef voldoende voorlichting over alle toebedeelde rollen in het ontwikkelingsproces en ga na of de betrokken personen voldoende doorzien wat dit van hen vraagt.
  • Selecteer nauwkeurig wie welke rollen op zich krijgt. Een deskundige werknemer voor een bepaald business proces, is niet altijd de geschikte kandidaat voor product owner.
  • Leg vooraf vast wie waarvoor verantwoordelijk is. Wie is de uiteindelijk verantwoordelijke voor de oplevering: de projectleider of de softwareontwikkelaar? Levert de softwareontwikkelaar alleen capaciteit of is deze ook verantwoordelijk voor het ontwerp en daadwerkelijke oplevering van de software?

4. Organisatiestructuur

Het is van groot belang om vooraf een duidelijke organisatiestructuur op te zetten. Wie zijn er betrokken? Wie heeft welke verantwoordelijkheden op zich genomen? Dit is met name relevant als meerdere partijen dan alleen de opdrachtgever en softwareleverancier aan tafel zitten, bijvoorbeeld softwareontwikkelaars van externe applicaties waarmee gekoppeld moet worden. Deelname aan een stuurgroep betekent bijna automatisch (gedeeltelijke) projectverantwoordelijkheid. Dus ook verantwoordelijkheid voor het niet slagen van het project. Van de partij die veel verantwoordelijkheden heeft wordt daarnaast een leidende en actieve rol verwacht. Een terughoudende opstelling past daar niet bij en kan leiden tot het verzaken van de zorgplicht.

5. Rapportage

Rapportage moet tijdens het hele ontwikkelproces plaatsvinden. Hoewel Agile sterk de nadruk legt op het ontwikkelen van werkende software, moet ook tijd besteed worden aan de deugdelijke rapportage. Spreek van tevoren af wanneer en hoe er gerapporteerd wordt. Welke indicatoren worden daarin benoemd? Welke scopewijzigingen hebben zich voor gedaan? Welke beslissingen heeft de opdrachtgever genomen die van invloed zijn op de ontwikkelsnelheid, budget en opleverdatum?

Conclusie

Werken met de Agile methode vraagt alertheid van de softwareontwikkelaar. Het contract bij aanvang kan door diverse scopewijzigingen en voortschrijdend inzicht in een heel ander licht komen te staan. Bij mislukte projecten biedt het contract dan ook vaak geen houvast en komt het er op aan of de softwareontwikkelaar heeft gehandeld zoals van een redelijk bekwaam softwareontwikkelaar mocht worden verwacht. Rapportage, communicatie en verwachtingsmanagement zijn belangrijke elementen voor de beoordeling van de zorgplicht.[/vc_column_text][/vc_column][/vc_row]