Mag ik mensen certificeren als Agile scrum master?

Een lezer vroeg me:

Mag je zomaar een certificaat ontwikkelen en uitgeven? Wij geven trainingen en workshops in Scrum, een vorm van Agile. Andere opleiders geven een certificering uit. De cursist is na het volgen certified scrum master, certified agile coach et cetera. Kan dit zomaar c.q. kunnen wij dit ook doen?

De term ‘certificaat’ is niet beschermd. Het betekent niet meer dan dat jij formeel iets verklaart. Iedereen mag dus anderen certificeren voor wat dan ook. De waarde van een certificering is dan ook wat de markt er van vindt.

Natuurlijk mag je geen certificeringen uitgeven die pretenderen door een ander uitgegeven te zijn, zeker niet als daar het merk of logo van die ander in staat. De vraagsteller kan dus niet “Microsoft certified” verklaringen afgeven, om eens wat te noemen.

Je mag wél een certificering uitgeven voor een merkproduct, zoals Microsoft Office. Als ik vind dat iemand goed kan omgaan met dat pakket, dan mag ik dat verklaren, en dat Microsoft een merk heeft op de term “Office” maakt daarbij niet uit. Ik mag echter niet de indruk wekken dat dit een certificering dóór Microsoft is, of zelfs maar dat mijn certificering op een of andere manier door hen goedgekeurd is.

Een certificering mag natuurlijk ook niet verklaren dat iemand een als merk beschermde titel heeft, zoals in dit voorbeeld Microsoft Office Specialist. Alleen de houder van dat merk mag verklaren dat iemand die certificering heeft ontvangen. (Af en toe zie je mensen die certificeren dat iemand aan de criteria voor zo’n beschermde titel voldoet. De grap is dan dat je formeel niet zegt dat iemand MOS is (wat dus niet mag) maar alleen dat hij dat volgens jou zou moeten/mogen zijn. Ik denk niet dat dat de giecheltoets overleeft.)

Voor Agile en scrum bestaan geen merken, voor zover ik weet. (Dat zou ook gek zijn want dat zijn gewoon termen voor een bepaalde methodologie, dat héét gewoon zo.) Iedereen mag dus iedereen “certified scrum master” of iets dergelijks verklaren, en je mag daarbij ook je eigen criteria hanteren die zelfs mogen afwijken van wat gebruikelijk is. Het is overigens wel handig als je die criteria ergens publiceert.

Als je wat groter wordt, dan zul je ook meer eisen van zorgvuldigheid moeten hanteren bij het toekennen van de certificering. Jouw verklaringen hebben dan meer waarde in de markt, en daar mag je dan niet lichtzinnig mee omgaan. Je criteria moeten dan duidelijk en objectief zijn, zodat iedereen weet waar hij aan moet voldoen en hoe hij die kan halen.

Studiemiddag: agile softwareontwikkeling juridisch bekeken

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