De aarde is niet plat maar rond (toch nog in twee keer goed)

Agile software developement wordt meestal vanuit het Engels vertaald als wendbaar ontwikkelen. Waar vroeger het te bouwen systeem voorafgaande aan de bouw gedefinieerd werd (en dit veranderde daarna amper), wordt nu tijdens de bouw snel geanticipeerd op nieuwe inzichten en veranderende wensen. Ik hoef agile ontwikkelen niet verder uit te leggen: Wikipedia: Agile en het lezen van het sublieme Scrum from the trenches geeft al voldoende info om er enthousiast van te worden.

Helaas is Agile ontwikkelen niet voor ieder project weggelegd. Ieder groot project is op te delen in kleinere deelprojecten, grootte mag het probleem dus niet zijn. Een belangrijke factor is de organisatie zelf. Agile ontwikkelen vergt veel communicatie over en weer met direct betrokkenen welke ook nog eens beslissingsbevoegd moeten zijn. En die personen moeten dus ook nog eens echt beslissingen gaan nemen. Als in het verleden altijd mooie nieuwe glimmende applicaties (..) over de schutting gegooid zijn dan is dit een aardige cultuurschok. De klant mag meekoken met de kok. En er komt tevens een redelijke macht bij de (power) users te liggen dus ‘politiek’ ligt ook nog eens op de loer. Kortom, agile projecten slagen voornamelijk in agile organisaties welke hun waterval verleden kunnen loslaten.

Maar er is nog een belangrijke factor waar heel eenvoudig aan voorbij gegaan wordt, ook door direct betrokkenen. Agile projecten moeten uitgevoerd worden door agile ontwikkelaars. Want hoewel het snel opleveren van steeds betere iteraties ronduit verslavend is, moeten door hen ook offers gebracht worden.

Er valt veel voldoening te halen uit het opleveren van solide code welke meegroeit met de organisatie en de veranderende wensen van gebruikers. Je probeert dus in te spelen op mogelijke toekomstige veranderingen in je ontwerp. En je wilt ook nog eens leren van fouten uit je verleden dus speel je al in op mogelijke tekortkomingen in de gebruikersvereisten. Want je wilt het nu eindelijk eens in één keer goed doen…

Maar dat is dus niet agile! Want agile betekent eigenlijk loslaten. Als ontwikkelaar moet je niet bang zijn eenmaal gemaakte keuzes toch weer snel los te laten. Neem je verlies, verander je ontwerp, refactor je code of begin desnoods opnieuw. Dit is moeilijk en vergt een nieuwe mindset. Want dit betekent dat je dus bij de tweede keer implementeren pas goed zit. Geef de poweruser de ruimte om tot inzicht te komen en wees luchtig met het op tijd wenden. Dit is geen nonchalance of een tekortkoming. Want de keuzes in het verleden waren goede keuzes met de kennis die toen voorhanden was. Dus als de gebruiker vind dat de aarde plat is, dan maak je zonder tegenzin een applicatie voor een platte wereld. En als een sprint later blijkt dat de aarde toch rond is, dan pas je jouw ontwerp gewoon net zo eenvoudig weer aan.

Ga dus niet zitten brommen dat de aarde wel degelijk rond is, want voor sommige organisaties is de aarde nog steeds plat. En dit loslaten is de ware wendbaarheid van agile projecten.

Advertentie

Het echte voordeel van standup meetings

Al enkele jaren draai ik mee in projecten waarbij een standup meeting een
dagelijks ritueel is. Met deze meetings werd in het verleden eerst ervaring
opgedaan met enkele agile projecten terwijl de rest van de organisatie nog in ‘waterval’ dacht.

De agile projecten waren door de korte sprints met bijbehorende opleveringen
veel zichtbaarder voor alle partijen (lees: de productmanagers) en dat sloeg
aan. Alles zou opeens agile moeten. Toen bleek dat niet alle teams en projecten
eenvoudig konden overstappen naar een agile traject werd gekeken of er andere
verbeteracties gestart konden worden. De introductie van standup meetings werd daarbij als een duidelijke verbetering voor de projecten gezien welke ook nog eens weinig investeringen met zich mee bracht. Het kost eigenlijk maar een
kwartiertje per dag van het team, toch?

Er valt veel informatie te lezen over de doelen en de invulling van standup
meetings, ik verwijs graag naar http://martinfowler.com/articles/itsNotJustStandingUp.html .
Er wordt namelijk nogal eens verkeerde verwachtingen gewekt rond de redenen van een standup meeting. Door de dagelijkse standup zouden namelijk veel problemen sneller tot uiting komen en zou de voortgang sneller te controleren zijn. Er wordt hierbij vaak geschermd met de te stellen drie vragen: Wat heb je gisteren gedaan? Wat doe je vandaag? Wat zijn de beren op je weg? Dit is inderdaad een mooie kapstok voor de meetings maar als dit de enige manier is om tot inzicht te komen over problemen en voortgang dan kan je gaan twijfelen over de totale haalbaarheid van het hele project.

De standup is namelijk vooral een lakmoesproef voor de commitment van het
team. Let er maar eens op! De onderlinge afstand in de kring van nog groot zijn
bij de start van een project met nieuwe teamleden of als een nieuw teamlid zich
aansluit aan een bestaand team. Men moet elkaar nog aftasten. Naar mate de
teamleden meer op elkaar afgestemd raken zal de onderlinge afstand afnemen, men laat elkaar toe in zijn persoonlijke ruimte. En dat zal zo blijven zo lang het
project goed draait. Bij tegenslag, frustraties of afnemende commitment door een andere reden zal onbewust, non-verbaal de onderlinge afstand weer toenemen.

Een ander opmerkelijk fenomeen is het halen van koffie vlak voor de standup.
Bij voorkeur ligt het tijdstip van de dagelijkse standup vroeg in de ochtend.
Door flexibele werktijden zal een team pas rond 9.00uur echt compleet zijn, een
belangrijke voorwaarde voor een standup 🙂 Een standup zal dus pas vanaf
9.15uur kunnen plaatsvinden. Dit geeft de teamleden ‘sochtends nog even de
gelegenheid om werkzaamheden van de dag ervoor eventueel af te ronden, de mail te lezen, (zelf-)reflectie danwel om nieuwe inzichten een eerste vorm te geven.
Maar vlak voor de standup schieten soms een paar teamleden richting de
koffiehoek om met een volle mok aan de standup meeting te beginnen. Dit kan
leiden tot twee standup meetings: één informele bij het automaat en één formele
met het project als onderwerp.

Zo kan het halen van een volle mok ook als een teken van verminderde
commitment gezien worden, want dit straalt uit dat de groep maar even moet
wachten. Hierdoor wordt het team uit het ritme gehaald en ook zal de noodzaak
tot een standup verminderen. De belangrijkste aandachtspunten zijn vrijwel zeker al naar elkaar uitgesproken, maar alleen aan diegene die staan te wachten voor hun bakkie troost. Het is verstandig de standup zo te plannen dat deze
afgesloten wordt met een gezamenlijke tocht naar de koffieautomaat. De standup
wordt hierdoor efficiënter want discussies tijdens de standup krijgen een plaats
en eventuele vervolgacties kunnen direct doorgesproken worden.

Bij een verminderde commitment of een verkeerde balans tussen de teamleden
zullen ook bij een standup een mindere voortgang of ‘beren op de weg’ niet
sneller zichtbaar worden, simpelweg omdat het onderlinge vertrouwen niet
optimaal is. De voortgang en eventuele problemen worden gemeten door bepaalde controles uit te voeren en een degelijke planning te voeren. De standup is hierbij een peilstok voor spanningen binnen het team.