Baselines: een uitdaging binnen Agile werken

Al enige tijd ben ik bezig met de zoektocht naar Quality Assurance binnen de IT, waarbij ik tot zover tot de volgende conclusie ben gekomen:

“Voordat je dus daadwerkelijk aankomt bij kwaliteitsbewaking of wel Quality Assurance, gaat er een heel proces aan vooraf”

Quality Assurance is alleen een veel omvattende term, want om welke kwaliteit gaat het nou eigenlijk precies en in hoeverre pakken bedrijven dit nu eigenlijk op.

Je hebt de testers die Quality Assurance toepassen op productniveau. De ontwikkelaars houden code reviews onderling en zetten bijvoorbeeld een applicatie als Sonar in om de kwaliteit van hun code te meten. Vanuit security word er vaak ook nog wel gevraagd om een formulier in te vullen aangaande een project vs. security en hier wordt een rapportage van opgemaakt. Dan hebben we nog de directie die bijvoorbeeld een medewerkersbetrokkenheidonderzoek laat uitvoeren om de kwaliteit te beoordelen en te waarborgen op bedrijfsniveau. En tot slot, ‘last but not least’, hebben we baselines, die kwaliteit moeten waarborgen op proces en project niveau.

Vaak bestaan baselines binnen organisaties uit: procedures, richtlijnen, templates, werkinstructies en best practices per afdeling/vakgroep. En ondanks dat het natuurlijk fantastisch is dat we zoveel gedocumenteerd hebben aangaande de baselines, blijft er toch iets bij mij kriebelen, want wat moet je er nou eigenlijk mee?

Wie, wat en waarom Baselines?

Baselines zijn geschreven om een zo duidelijk mogelijk beeld te geven van hoe men een proces en/of project zou moeten doorlopen om te voldoen aan de ‘afgesproken’ kwaliteit. Echter bestaat een baseline vaak uit een complete procesbeschrijving (en nog meer) en is het vaak een dik document met veel pagina’s. Dus wie volgt nou daadwerkelijk de baselines, of beter gezegd, zijn de baselines praktisch genoeg opgesteld en daarmee goed en snel toepasbaar in praktijk? Persoonlijk denk ik van niet, maar ik weet ook nog steeds niet wat de verwachting nou exact is aangaande een baseline. Want moet ik nu een baseline van bijvoorbeeld 30 pagina’s uit mijn hoofd leren en mijn collega’s er op wijzen als ze dus niet voldoen aan deze baseline of is het toch anders bedoeld?

De verwachting van een Baseline

Waar zou een baseline nou eigenlijk aan moeten voldoen, vraag ik me dan af. In mijn optiek zou een baseline moeten bestaan uit iets simpels; bijvoorbeeld een processchema, iets wat niet meer dan 1 A4-tje beslaat, iets wat men gemakkelijk kan onthouden. Het moet ook een richtlijn zijn en niet een vast gegeven. Maar je zou wel moeten kunnen zien dat als een project niet lekker loopt en de kwaliteit achteruit gaat, dat dit dan zou kunnen komen omdat je een stap van de baseline hebt overgeslagen. Of misschien moet een baseline zelfs wel bestaan uit een rijtje ‘Principals’. Maar hoe dan ook, door iets op papier te zetten, betekent nog niet dat iedereen dit ook gaat doen. Sterker nog, ik denk dat we zelfs met zijn allen wel kunnen concluderen dat dit in zijn algemeen niet werkt en daarom willen we ook Agile werken! Agile, wat was het ook alweer…

  • Indivduals and interactions over processes and tools’
  • Working software over comprehensive documentation’
  • Customer collaboration over contract negotiation’
  • Responding to change over following a plan’

Baselines vs. Agile mindset

Ja, als ik die Agile Manifesto zo even opschrijf, vraag ik me al meer af waarom die baselines er zijn. Maar beter, hebben we die nog wel nodig als we eigenlijk met zijn allen Agile willen werken? Moeten we van te voren uit kauwen in een baseline hoe we moeten werken met zijn allen zodat we gelijke mate van kwaliteit leveren per project en op die manier Quality Assurance inzetten? Of zouden we het op zijn ‘Agiles’ moeten aanpakken en is Quality Assurance gewoon onderdeel van een project en zit dit verwerkt in bijvoorbeeld de ‘Definition of Ready’ en de ‘Definition of Done’ waarbij we een aantal principes hanteren die we willen naleven omtrent kwaliteit? Tijdens de Nederlandse Testdag heb ik aan de hand van het model van Laloux geleerd dat de meeste organisaties eigenlijk gewoon in de kinderschoenen staat als het komt tot Agile werken. Het model van Laloux geeft aan in welk level een organisatie zich kan bevinden, waarbij elk level specifieke kenmerken heeft. In totaal zijn er 5 levels waarbij het eerste level gelijk staat aan een ‘roedel wolven’ (rood) waarbij er één leider is en de rest volgt. Het laatste level is een ‘zelfgestuurd organisme’ (teal), waarbij iedereen dus gelijk is, er geen specifieke leider is en iedereen gezamenlijk verantwoordelijk is voor het einddoel ofwel ‘full-blown’ Agile. De levels daar tussen zijn het ‘leger’ (amber) waarbij hiërarchie, rollen en processen ontzettend belangrijk zijn. De ‘machine’ (oranje), hierbij is er al meer ruimte voor innovatie, zijn resultaten belangrijk ofwel werkende software en gaat het er om de competitie te verslaan. Tot slot de ‘familie’ (groen) wat gericht is op mensen ‘empowered teams’ en een partnership met de klant.

laloux

Tijdens de Nederlandse Testdag zagen we dat veel organisaties vergeleken konden worden met een ‘leger’ (amber) of misschien zelfs al een beetje met een ‘machine’ (oranje), een enkeling gaf aan dat hun organisatie al een ‘familie’ (groen) was… Wel maakt dit het duidelijk waarom er dan baselines zijn, want als je kijkt naar de amber kleurige cirkel hebben de meeste organisaties dus nog behoefte aan proces ofwel baselines en formele rollen ofwel een functiehuis. Waar denk jij dat jouw organisatie staat en welk rol speel jij hierin? Heb je misschien meer uitleg nodig om hier überhaupt een mening over te vormen, kijk dan even dit filmpje: het model van Laloux https://vimeo.com/121517508

Mijn conclusie is dat Quality Assurance voor nu dus op meerdere manieren moet worden ingezet, wat eigenlijk jammer is. Maar je kan niet ineens van een ‘leger’ (amber) naar een ‘zelfgestuurd organisme’ (teal) gaan… Helaas, dit heeft tijd nodig…

Maar ondanks dit, weet ik wel dat de manier hoe nu Baselines worden opgezet, zeker niet bijdraagt aan waar de meeste organisaties naartoe willen. Het moet echt anders willen we hieruit iets van meerwaarde halen, maar hoe het dan precies wel moet weet ik ook nog niet zeker en hier kom ik graag op terug in een volgend blog. Wel weet ik dat we de zekerheid willen hebben dat de kwaliteit van ons werk afdoende is en dat een klant tevreden is over de kwaliteiten van ons product en trots is op zijn of haar opgeleverd product!