Hypothese: elk team heeft een conjunctuur! Herkenbaar?

Na 3 jaar met en naast ttcrum/DevOps teams te hebben gewerkt weet ik het zeker, teams hebben een conjunctuur. Teams gaan lekker en dan na een paar maanden gaat het weer even wat minder, ze zakken terug in hun performance, focus en discipline. Hoe kan dit, waar komt het door, is het erg en wat kan je er aan doen.

Ik heb hierover 3 vragen voor je:

  • Herken je dit?
  • Wat zouden mogelijke oorzaken hier van zijn?
  • Wat kun je doen om op een hoogtepunt weer een nieuwe groei in te zetten?

Voorbij: Forming – Storming – Norming – Performing

Bruce Tuckman publiceerde al in 1965 een model met 4 stadia waar een team door heen gaat als ze een team gaan worden. Voor mij is dit model nog steeds een valide model. Een team moet er zwaar en diep doorheen als ze helemaal nieuw zijn. Maar ook elke keer bij een wissel van een teamlid zul je even moeten wennen aan elkaar. Een nieuw lid brengt immers weer even verwarring in de pikorde.

Grood beschrijft dit in zijn boekje “Agile in de echte wereld, starten met scrum” (link) een model waarin teams doorheen moeten aan de start. Hierin is een dip nadat de euforie voor scrum is doodgeslagen door de naakte waarheid van de organisatie (systeem) waar dit team onderdeel van is. Ik heb het nadrukkelijk niet over deze eerste dip maar over de golven die daarna komen.

Het vreemde is echter dat de conjunctuur die ik zie plaatsvind na de Performing fase. Gewoon na een paar maanden of paar jaar als een team lekker aan het werk is. Ik heb het dan over stabiele teams die voor langere tijd met elkaar samenwerken. Waarom en waardoor vindt dit plaats?

De conjunctuurgolf van het team

Het lijkt wel alsof elk team zijn vaste conjunctuur heeft met zo’n twee hoogte punten per jaar. Een hele golf duurt dus ongeveer 5-7 maanden. Richting de piek van de golf zit de flow en spirit er goed in. Het team levert veel, zit vol energie en heeft een hoge voorspelbaarheid. Richting een dal is de geest uit de fles, worstelen ze met delivery en is de voorspelbaarheid erg laag en is dit zichtbaar op het teambord met veel werk tegelijk onderhanden en pairen, dat doen ze bij de koffiebar.
Continue reading

3 Belangrijkste ingrediënten voor Continuous Compliance

Het is al weer even geleden dat ik 5 redenen voor Continuous Compliance deelde, en de introductie gaf op dit onderwerp. Het jaar is inmiddels 8 maanden verder en zo ook de visie en inrichting van dit onderwerp.

In dit blog delen we met veel plezier de 3 belangrijkste ingrediënten voor Continuous Compliance.

  1. Maak gebruik van Build Breakers in de pipeline
  2. Zorg voor een goede segregatie van rechten
  3. Zet monitoring bovenop je pipeline

Een eerlijke onthulling

Persoonlijk ben ik het met nummer 1 volledig eens, nummer 2 en 3 vindt ik wat over de top. Ben je echter werkzaam binnen een omgeving waar Sox, audits en compliancy behoren tot de woordenschat van je bedrijf dan zul je er niet aan ontkomen om ze op te zetten. Als je dat doet, doe het dan goed en zo veel als mogelijk geautomatiseerd. Het ultieme doel is dat je er nauwelijks het omkijken naar hebt.

Maak gebruik van Build Breakers in de pipeline

Dit is echt een van de belangrijkste componenten om een veilige pipeline te hebben. Maar niet alleen veilige maar ook een pipeline die kwalitatief hoogwaardige software moet opleveren. Build Breakers zijn punten in je pipeline die ervoor zorgen dat de software niet wordt neergezet op omgevingen (Test en Acceptatie) verder in je pipeline als je niet voldoet aan bepaalde kwaliteitscriteria.

Door op deze manier te werken is er een garantie dat alles wat naar productie gaat ook daadwerkelijk de testen heeft doorstaan. Voor de auditors is dit echt een cruciaal punt. Deze manier van werken heeft twee grote bijkomende voordelen, de beslissing of iets naar productie kan gaan is in verre mate te automatiseren en het levert enorm snelle feedback cycles op voor iedereen in het proces.

4 Voorbeelden van build breakers:

  • Elke rode of oranje bevinding uit je static secure code analysis (op te zetten met Fortify SCA)
  • Een code coverage onder bijvoorbeeld 85% (op te zetten met SonarQube)
  • Een (API) regressie test die faalt (op te zetten met bijvoorbeeld Concordian)
  • Een performance daling van een stuk functionaliteit (op te zetten in Gatling)

Zorg voor een goede segregatie van rechten in je pipeline

Dit deel is eenvoudig en vanzelfsprekend. Een goede segregatie van rechten is een een hoog gereguleerde omgeving van cruciaal belang. Het komt er kortweg op neer dat je pipeline moet kunnen aantonen dat de persoon die de code maakt of aanpast niet de persoon is die de release naar productie kan aanzetten.

Continue reading