Agile, Programming

If You’re Using Pull Requests, You Probably Aren’t Doing Continuous Integration

I tend to agree with David Masters that pull requests (merge requests) hold the team back. They prevent you from doing continuous integration as it was originally defined in Kent Beck’s Extreme Programming:

Continuous — Every day (the when)
Integration — The mainline branch (the where)

On Medium: Are Pull Requests Holding Back Your Team? by David Masters.

Agile

Wat is “Agile”

Ik vind het lastig uit te leggen wat ik versta onder “agile”, of wat je zou moeten verstaan onder “agile”. Wat ik zeker niet “agile” vind is een methode die in detail procedures voorschrijft om “agile” te zijn. Scrum is niet agile. Agile is een houding, een attitude. Dat is ook wat ik in mijn boek beschrijf. Daar staat geen lijst je in, geen voorschrift geen schema. Ik heb daar anekdotisch opgeschreven wat ik “agile” vind.

Daarnet las ik een stukje dat volgens mij wel de vinger legt op een cruciaal punt van agile werken. Agile is dat de baas de medewerkers vertrouwt, en ze een eigen verantwoordelijkheid geeft. Op medium: 5 Innocent but Damaging Things Bosses Say

Agile, Blog, Programming

Ontwerp voor fail safe

Bij de grand prix in Zandvoort is Sebastian Vettel komen stil te staan, er komt rook uit zijn auto. Hij rommelt met een brandblusser, marshals mogen er niet gelijk bij, en als er de rode vlag is, doen ze toch vrij weinig. Het duurt allemaal nogal lang voordat de auto wordt weggehaald. De commentator legt het later uit: “De brandweerman had bij de pit nagevraagd of er stroom op de auto stond, het antwoord was nee, maar hij kreeg toch een optater. De chef van het circuit heeft toen gezegd: als ik van de één te horen krijg dat er geen stroom is, en van de ander van wel, dan neem ik het zekere voor het onzekere: er staat stroom op de auto dus is er rode vlag”.

Dat is een vorm van het “fail safe” principe, ook wel genoemd “bij twijfel niet inhalen”. De circuitbaas kiest voor de oplossing die altijd veilig is, namelijk de aanname dat er stroom op de auto staat. Is dat zo, dan moet de race worden gestopt, is dat niet zo, dan kan het geen kwaad dat de race wordt gestopt. Zou andersom worden beslist, iets van “bij twijfel wel inhalen”, dan bestaat het risico dat de brandweer gaat spuiten en er iemand wordt geëlektrokuteerd.

Tijdens het natuurkunde bijvak in mijn sterrenkunde studie (ik heb in mijn doctoraalstudie veel elektrotechnische dingen gedaan) heb ik veel geleerd over “fail safe”. Ik deed onderzoek met een spectrograaf, een apparaat waarmee je licht kunt ontleden. Dat resulteert in een foto waarbij alle golflengten van het licht apart worden weergegeven. Bovenstaande illustratie is zo’n spectrum, gemaakt met één van de spectrografen waarmee ik heb gewerkt (ontleend aan het proefschrift van Ton Raassen). Het is een spectrum van UV licht, van rond 122nm golflengte. Ultraviolet licht wordt niet doorgelaten door de lucht om ons heen, dus de spectrograaf bevond zich in een grote tank die we vacuum konden pompen. De lichtbron was een staafje van een bijzonder metaal, Yttrium of Ytterbium of eén van al die bijzondere metalen. Omdat we een vonk lieten overspringen tussen twee staafjes Yttrium, en een vonk niet ontstaat als er geen lucht is om de elektriciteit te geleiden, moesten we een hoge spanning op de staafjes zetten zodat met het pietsebeetje lucht (het vacuum was niet perfect, dat kan niet op aarde) toch een vonk ontstond. Ik bediende dus een “plofkast” waar maximaal 10 kilovolt mee opgewekt kon worden en een stroom van een paar duizend ampère. Er was een trillingskring (je weet wel, een spoel, en condensator en een weerstand) om de vonk even gaande te houden. Je begrijpt dat een spoel voor 10kV en een paar duizend ampère een groot ding is: een flinke koperen pijp in een paar windingen gedraaid. De condensator was enorm, de weerstand ook.

De tank was een groot ijzeren ding waarvan de bovenkant hydraulisch omhoog kon zodat je de een fotografische plaat in de spectrograaf kon zetten. Achter de tank zat een vacuumpomp die werkte met een olie-scherm, en daarachter twee mechanische vacuumpompen. De spectrograaf had een tralie (een glazen plaat met streepjes die werkt als een prisma, maar dan anders). Dat tralie had een gouden coating en had zoveel duizend lijntjes per milimeter, en kostte iets van 20.000 gulden. Als de mechanische vacuumpomp uitviel, werd het oliescherm van de olie diffusiepomp in de tank geblazen en konden we het tralie weggooien. Als de hydraulica het begaf als ik net in de tank leunde kwam het deksel naar beneden en was ik doormidden. Als ik te dicht bij de plofkast kwam, was ik verdampt. Vandaar dat op vele manieren het fail safe principe was geïmplementeerd. Rond de hele opstelling stond een aluminium hek, dat goed was geaard. Als er ook maar het minste mis was met het hek, ging de elektriciteit uit. Op de plofkast zat een “schakelaar” die met perslucht werkte, en als de perslucht uitviel ging de schakelaar in de veilige stand, dat wil zeggen de elektra ging uit. Als de mechanische vacuumpomp uitviel, sloten onmiddelijk alle kleppen van de olie-diffusiepomp, zodat er geen olie in de tank kon komen. Er was een bedieningspaneel voor alle apparatuur, buiten het hek, als daar iets mee was, ging de hoogspanning uit en de kleppen op veilig. Alles in de hele installatie was zo ontworpen dat als er iets mis ging of stuk ging, niemand gewond kon raken en het tralie niet beschadigd kon raken. Het was ontworpen voor fail safe.

Natuurlijk heb je geen garantie. Toen ik op een middag lekker zat te ploffen merkte een collega op dat er vonkjes van het aluminium hek sprongen. We hebben alles gelijk stilgezet, en na grondig onderzoek gevonden dat het hek niet goed geaard was. Dikke koperen strips bleken niet genoeg aarde voor de hoge spanning. Ik kon een week niet ploffen omdat een installateur een nieuwe aardleiding moest maken in het grondwater. Diezelfde collega-student is er later in geslaagd toch een instelling te vinden waardoor de olie in zijn installatie (er waren twee spectrografen, hij werkte met de ene, ik met de andere, we gebruikten hetzelfde hek en plofkast) op het tralie belandde. Prof. Klinkenberg was daar niet blij mee.

Je verwacht dat wetenschappers allemaal begrijpen wat fail safe is. Niet alleen in het ontwerp van installaties (of sofware) maar ook bij het interpreteren van metingen en het nemen van beslissingen. Ik was daarom zeer verbaasd toen Jaap van Dissel het volgende zei over de mogelijkheid dat het coronavirus via aerosols verspreid kan worden. Hij zei “het is niet bewezen dat het virus via aerosols verspreidt dus we gaan daar niet van uit”. Huh? Fail safe zegt dat je als je iets niet weet, je van de veilige situatie uitgaat. Als je niet weet of een virus via aerosols verspreid raakt, is de veilige situatie die waarin mensen niet besmet raken, dus neem je aan dat het virus zich wel via aerosols verspreidt en neem je daar maatregelen tegen. Je kunt stoppen met die maatregelen als bewezen is dat het virus zich niet via aerosols verspreidt. Van Dissel verbaasde mij des te meer omdat er levens op het spel stonden, en staan. Als blijkt dat het virus zich via aerosols verspreidt, dan is dat in heel 2020 gebeurt, en zijn er weet hoeveel mensen besmet geraakt die niet besmet waren geraakt als Van Dissel iets had begrepen van fail safe.

Er komt natuurlijk meer bij kijken dan alleen “fail safe”. Bij de oude ADM werf in Amsterdam Noord hadden ze in het magazijn een snijmachine om metalen platen te snijden. Een enorm apparaat dat met een valmes zo een plaat doormidden sloeg. Het ding werd bediend met twee drukknoppen op ooghoogte op afstand van elkaar om te zorgen dat je beide armen uit de buurt had als het ding in werking was. Maar dat is natuurlijk onhandig, want dan kun je niet de plaat snel nog even recht leggen, dus zat er ineens een stuk ductape om de ene knop. De ontwerper moet dus verder gaan en detectie inbouwen dat als een knop langer dan x seconden is ingedrukt, de hele installatie uitvalt en niet zomaar weer kan worden aangezet. Waarna mensen dan toch weer iets vinden om het weer gevaarlijk te maken. Lees in “Gödel, Escher, Bach” van Douglas Hofstadter het verhaal van de krab en de schildpad over hoe zo’n wedloop nooit ophoudt.

De moraal van dit verhaal: als je iets ontwerpt, doe het dan zo dat als er iets mis gaat, de gevolgen beperkt blijven. En voor de manager, als je iets moet beslissen en je mist informatie, beslis dan zo dat er in ieder geval geen dooien vallen.

Agile, Programming

Stil op je fiets zitten

Een poos terug fietste ik mijn vaste rondje, ik begon met wat sprinttraining, daarna wat intervallen, en dan lekker uitrijden. Ik haalde bij zo’n sprint een vrouw in, ze fietste een constant tempo langs de vaart, na de sprint haalde ze mij in, en we wisselden in de loop van een uur een paar keer af. Bij Lisserbroek haalde ik haar weer in, en we reden een kort poosje samen, al pratend. Zij deed bloktrainingen, ze ging met haar vriend de Mont Ventoux beklimmen, en had wat extra training nodig. Ze zag een beetje op tegen de inspanning om zo’n grote berg op te fietsen, denk ik. Ik vertelde haar dat ik al wel een poosje fietste, en toen zei ze “ja, je zit zo mooi stil op je fiets”. Ik legde haar uit wat het geheim is van stil op je fiets zitten.

Je ziet nogal ‘s een wielrenner fietsen met bewegende schouders, de rechter schouder naar rechts en omlaag als het rechterbeen omlaag gaat, en links hetzelfde. Hij duwt als het ware zijn been omlaag met zijn schouder. Dat werkt natuurlijk niet, de beweging van je bovenlichaam kost wel energie maar draagt niet bij tot de snelheid. Zo iemand duwt de pedalen omlaag, eerst rechts, dan links, en om en om, net als je op je stadsfiets doet, net als iedereen fietst op een gewone fiets. Maar op een racefiets zitten je voeten vast aan de pedalen en kun je beter een ronddraaiende beweging maken. Je duwt je voeten niet alleen omlaag, maar op het laagste punt ook naar achteren, en dan omhoog, en dan naar voren, en dan weer omlaag. Het moet voelen dat je je voeten in een cirkel beweegt, waarbij je in het ideale geval op ieder punt van de cirkel evenveel kracht zet. Dat lukt natuurlijk niet, want omlaag duwend kun je meer kracht zetten dan omhoog trekkend, en omhoog trekkend meer dan vooruit of achteruit duwend. Toch kun je met een goede ronddraaiende beweging permanent kracht zetten, in plaats van alleen een kwart cirkel rechts en dan een kwart cirkel links. Door permanent met beide voeten te duwen lever je meer vermogen dan als je een kwart van de tijd links omlaag duwt en een kwart van de tijd rechts omlaag duwt. Het voordeel is niet alleen dat je 100% van de tijd duwt, je gebruikt ook meer spieren. Omlaag duwen doe je met je grote dijbeenspier, maar voor ronddraaien gebruik je alle spieren van je been. En meer spieren gebruiken geeft meer kracht op de pedalen. Het effect van je benen goed ronddraaien is dat alleen je benen het werk doen, en dat je dus mooi stil op je fiets zit. Kijk naar wielrenners in een wedstrijd en je ziet dat ze allemaal stil op hun fiets zitten. Behalve Bauke Mollema dan.

Ze fietste verder met haar volgende blok, en ik bolde nog wat uit, en voorbij de Kaag haalde ik haar weer in. Ze zei “ik probeer mijn benen goed rond te draaien, zoals je zei, en dan gaat het fietsen inderdaad makkelijker. Ik moet er nog wel bij nadenken om het zo te doen”. Ja, dat is altijd, als je iets op een andere manier doet, moet je dat in het begin bewust doen, totdat het vanzelf gaat. We praatten verder, ze zei dat ze het ook tegen haar vriend ging vertellen, dat ze over twee weken naar de Mont Ventoux ging, en we praatten over het werk, en over werken in coronatijd, en we kletsten verder terwijl we aan het uitrijden waren.

Gisteren fietste ik weer langs Lisserbroek, in een strak tempo, en toen bedacht ik dat stil zitten op de fiets een metafoor is voor het werken met scrum. Of beter, voor het werken zonder scrum. Stil zitten op je fiets wil zeggen dat je benen 100% van de tijd vermogen leveren, 100% van de tijd effectief bezig zijn. En of je nu hard fietst of lekker rustig, 100% constant vermogen geeft de maximale snelheid bij gegeven vermogen. Dan denk ik aan een scrum sprint, stel dat die twee weken duurt, tien werkdagen effectief. De dag dat de nieuwe sprint start heb je een retrospective meeting, een demo meeting, een sprint-start meeting, en die dag kom je aan software maken dus niet toe. De volgende dag ga je je verdiepen in nieuwe features (user stories, in scrum terminologie) en overleg je met collega’s en zoek je informatie bij elkaar, die dag is niet een heel effectieve programmeer-dag. De laatste dag van de sprint moet je zorgen dat je administratie op orde is, dat alle items op het scrum bord op “done” staan, dat de verslaglegging goed is, en dat je je demo van de volgende dag voorbereidt. Die laatste dag is ook niet de meest effectieve programmeerdag. Dus van de tien werkdagen in een sprint, kun je zeven dagen optimaal werken. Behalve dan dat je iedere dag een kwartier “stand-up” hebt, daarvóór kom je aan geconcentreerd werken niet toe, je bent zomaar een uur kwijt iedere dag. Effectief werk je zeven dagen van zeven uur aan de software. En in die bijna 50 uur doe je minder dan in 10 dagen van 8 uur. Of je moet in die 50 uur meer “vermogen” leveren dan in 80 uur, zoals je op de fiets als je niet stilzit bij het omlaagtrappen meer vermogen moet leveren als dat je mooi rond trapt.

Natuurlijk pleit ik er niet voor dat een software ontwikkelaar de hele dag alleen stilletjes in een hoekje moet zitten programmeren. Natuurlijk is overleg nodig, natuurlijk is afstemming nodig met collega’s, natuurlijk moet je samen de grote lijnen bepalen en bijstellen. Alleen, dat gebeurt evengoed wel. Dat gebeurt meestal als het nodig is, om elf minuten over drie ‘s middags, of om tien voor negen in de ochtend, en niet op het moment dat scrum zegt dat er een standup moet zijn of een refinement meeting. In de praktijk zijn de meeste vergaderingen en overleggen die scrum voorschrijft “extra”, dat wil zeggen, bovenop de discussies die je evengoed al hebt met je collega’s. En dat is waarom ik scrum vergelijk met de schokschouderende fietser: je bent niet 100% van je tijd productief bezig en je levert dus minder resultaat dan je zou kunnen, of je moet in de mindere beschikbare tijd harder werken om hetzelfde te bereiken.

In een eerdere blog heb ik geschreven hoe empowerment van medewerkers leidt tot beter resultaat. In een nog eerder stukje heb ik opgeschreven wat de frustraties zijn die werken met scrum voor veel software ontwikkelaars opleveren. In de praktijk – mijn ervaring in het werken in software ontwikkel teams beslaat een periode van 40 jaar – zie ik dat iedere methodiek verwordt van een handige tool om beter te werken tot een doel dat het werk zelf in de weg staat. Dat was zo bij SDM in de jaren ’80, dat was zo bij Prince2, en dat is zo bij Scrum. Waar agile (slagvaardig, wendbaar) werken goed is, verwordt het tot een rem op het werk zodra je het vastlegt in regels en procedures.

Als je als manager wilt dat je mensen effectief en met plezier werken, dan kun je er het beste voor zorgen dat ze zelf mogen sturen, en dat je ze stil op hun fiets laat zitten om maximaal resultaat te halen.

Agile, Programming

Zelf sturen, in het peloton

Ik wielren. Dat doe ik al een poosje, ik ben begin jaren ’70 begonnen. Ik had een racefiets gekocht, een studiegenoot was secretaris van de wielervereniging GGMC, en voor ik het wist reed ik mijn eerste clubkoers op een stratenparcours in Weesp. Het eerste jaar viel het niet mee, maar gaandeweg ging het beter en kon ik de groep steeds beter bijhouden. Het waren clubkoersen, oud en jong, jongens en meisjes door elkaar, om aan het begin van het seizoen (vanaf februari, brrr, koud!) in vorm te raken voor de wedstrijden. Ik reed alleen criteria, de kleine wedstrijden op een klein parcours rond het dorpsplein of de kerk. 40 rondjes van 1.5km over hobbelige klinkerstraten met scherpe bochten en smalle straatjes. Dat is natuurlijk veel minder heroïsch dan de grote ronden door het Hollandse landschap waar ze in waaiers tegen windkracht 5 in rijden of met z’n vieren een uur lang een voorsprong moeten houden op een ontketend peloton. Maar toch, ik vond het super leuk. Gezellig ook, de saamhorigheid in de wielerwereld is groot, als beginner krijg je links en rechts tips en goede raad, en soms bij de start een wiel (“je hebt een afloper, hier, neem dit wiel maar”). Eén ding heb ik goed geleerd, in 15 jaar criteria rijden: sturen. In het begin is het eng, in een grote groep schouder aan schouder op een smalle bocht af stormen, je aarzelt, en voor je het weet zijn 20 renners je voorbij gegaan. Gebeurt dat een paar keer, dan rij je achteraan, en moet je jojo’end aan de staart dubbele inspanning leveren. Diezelfde secretaris, Maarten Wijdenes, heeft me goed geholpen. “Je moet je smal maken, dan pas je nog in het gaatje voor je”. Hij had zelf om die reden een heel smal stuur op zijn fiets. Ieder gaatje waar je je nog tussen kan wurmen is meegenomen, want hoe meer je middenin de groep een beetje vooraan rijdt, hoe minder inspanning het kost. En ja, dan voel je een hand die je iets opzij of vooruit duwt, of duw je zelf iemand een beetje naar voren. Je gaat schouder aan schouder, soms wringt het wat, maar je aarzelt niet, want dan raak je achterop en moet je meer inspanning leveren. En ja, je raakt wel eens met je voorband een achterband. Geen paniek, je stuur goed vasthouden, en doorfietsen, dan komt het altijd goed. Soms gaat het niet goed. Dan lig je ineens op de klinkers. Dan sta je op, en je leert dat die schaafwond op je dij best wel weer snel geneest, en dat die snee in je wang best wel mooi gehecht kan worden, en een week later zit je weer op je fiets in de ronde van Landsmeer. Of Rijsenhout. Of Volendam. En je wurmt je er weer tussen, en je haalt er in de bocht een paar in, omdat je wat sneller door de binnenbocht durft.

Ik fiets nog steeds. Geen wedstrijden, die zijn er niet voor mijn leeftijdcategorie, maar ik train op hetzelfde niveau als vroeger. Meestal 250km in de week, in de jaargetijden dat het licht het toelaat om na het werk nog even te gaan fietsen. Ik train alleen. Deed ik vroeger, doe ik nu. Fietsen in een groep op de openbare weg vind ik spannend, onoverzichtelijk, en soms gevaarlijk. Er zijn paaltjes, voetgangers, uitwijkende auto’s, andere fietsers, en alleen zie je dat allemaal op tijd, in een groep ben je afhankelijk van anderen. Bovendien hoef je in je eentje niets te plannen: ik ga fietsen als het uitkomt. Wat ik wel doe is als een groepje mij voorbij komt, dat ik aanpik. Dan rij ik een poosje mee, en als het getrainde wielrenners zijn, dan rijden we vloeiend door het verkeer, maken een simpel handgebaar als er een voetganger of een paaltje is, rijden heel dicht aan het wiel maar als iedereen een strak tempo rijdt gaat dat prima. Doet iemand dat niet, dan laat je die achter je, strak tempo is belangrijk. “Strak” in de zin van “heel constant”.

Soms rij ik mee met een groepje vrouwen van de wielervereniging waar ik lid van ben. Het is een groepje vrouwen die lekker kunnen fietsen, de ritjes zijn meest gericht op het contact en de gezelligheid. De wielerbond stelt verplicht om als je in clubverband in een groepje rijdt, dat er dan een “wegkapitein” bij is. Die wegkapitein zorgt dat de groep veilig en verantwoord door het verkeer rijdt. Je rijdt met z’n tweeën naast elkaar, tempo tegen de 30 per uur, als de weg smal of druk wordt, moet je achter elkaar rijden, als er een paaltje is moet je achter elkaar en rechts erlangs, en als er een voetganger, fietser of tegenligger is wordt er “voor” of “tegen” geroepen. Of “paaltje!”. En eerlijk gezegd, ik vind dat niet prettig fietsen. Rij je met een groep van tien en iedereen kan goed sturen en let goed op, dan hoeft er niets geregeld te worden en is er geen gevaar, je rijdt vanzelf goed om de paaltjes en langs de fietsende oudere echtparen. Heb je teveel vaart, dan schuif je in het gaatje tussen anderen, of je haalt iemand in, in het ergste geval pik je een stoeprandje mee. Het gaat organisch, vloeiend, en veilig, omdat iedereen goed kan sturen en goed kijkt. In de groep met de wegkapitein kan dat niet. Je mag niet in het gaatje piepen, want je moet met z’n tweeën naast elkaar blijven, of als er een paaltje is moet je er rechts langs, je mag niet als je teveel vaart hebt er dan maar links langs want dan raken anderen in de war. Iemand die teveel vaart heeft, remt, dan moeten anderen remmen, en voor je het weet ligt er iemand op de grond. Het klinkt paradoxaal, maar ik vind fietsen in een groep met een wegkapitein en strikte regels voor de veiligheid veel gevaarlijker dan fietsen in een groep met mensen die ik verder helemaal niet ken en die allemaal naar eigen inzicht over de weg fietsen. Ik zie dat regels in de groep en centrale leiding veel minder effectief zijn – of zelfs contra-productief zijn – dan 100% vertrouwen op de stuurkunst van de individuën. Ik rij dus niet vaak met het vrouwenclubje mee, maar pik als het kan wel aan bij een groepje voorbij snellende wielrenners.

Ik zat dit daarnet op de fiets te bedenken (ringdijk langs de Haarlemmermeer, veel wind, regen) en ik realiseerde me dat het fietsen in een groep een mooie analogie is voor het werken in een team. Ik heb in de loop van de tijd in veel software development teams gewerkt, in verschillende rollen. Een deel van die teams werkte in een klassieke organisatie met managers en functiebeschrijvingen, een deel van die teams waren startups zonder structuur of direct management, en in toenemende mate zijn het teams die volgens scrum werken. Scrum is een methode die ontwikkeld is door een groep mensen die een analyse heeft gemaakt van succesvolle software development teams en vervolgens regels en procedures heeft opgesteld voor het werken als team. De eerste analyses op dit gebied zijn gemaakt door Ikujiro Nonaka en Hirotaka Takeuchi, in de jaren ’90. Zij gebruikten rugby als metafoor, vandaar de naam “Scrum” voor de nu populaire methode. Een groep software developers heeft in 2001 het “Agile Manifesto” opgesteld, regels en principes voor effectieve software ontwikkeling. Tegenwoordig gebruikt iedere organisatie Scrum, een methode die in veel detail voorschrijft hoe je effectief en efficiënt software ontwikkelt. En als ik mijn ervaringen met waarlijk agile teams uit de jaren ’90 en ’00 vergelijk met de Scrum teams van nu, dan zie ik hetzelfde als wat ik zie bij het wielrennen in een groep: regels, gedetailleerde voorschriften en strakke leiding maken het proces slechter, niet beter. Als ik in het peloton besluit dat links in het gaatje duiken het veiligst en het snelste is, wil ik in een software team ook kunnen besluiten dat ik voordat ik mijn geplande werk doe eerst iets anders doe dat mij en de rest van het team helpt. Maar de wegkapitein roept “met z’n tweeën naast elkaar!” en de scrum master zegt “dan moet je eerst een user story maken en dan kunnen we die in de volgende refinement bekijken en dan volgende maand in de sprint meenemen”. Ik voeg me dus naar de wegkapitein, ik mis gelukkig net dat paaltje, en ik besluit niet zo vaak mee te rijden met een groepje met een wegkapitein. Welke paaltjes ik mis in de software development weet ik niet, het zullen er vele zijn, maar soms knal je dan wel op het paaltje. Dan hoeft er niets gehecht of verbonden te worden, behalve de schram op je ziel, maar je wordt er niet gelukkig van.

Als je goed kunt sturen en je weet dat de anderen in het peloton ook goed kunnen sturen, dan kun je doen wat je wilt en hoeven er geen regels te zijn, hoeft er geen wegkapitein te zijn. Goed kunnen sturen wordt bepaald door ervaring, talent, durf en motivatie. Ik denk dat agile werken ook wordt bepaald door ervaring, talent, durf en motivatie. Je kunt in een agile team werken als je ervaring hebt, en motivatie. Heb je geen ervaring, dan moet je talent hebben, en motivatie. Durf wordt nooit genoemd in de scrum- en agile leerboeken. Durf in een team betekent volgens mij dat je beslissingen durft te nemen zonder eerst een eindeloze analyse te doen. Je volgt je gevoel, en je accepteert dat je onderuit gaat (grote schaafwond op je ziel en hechting in je wang) en dat je de schade moet herstellen. Dat kan alleen als je weet dat de rest van het team dezelfde durf heeft, en fouten accepteert. Het gevolg van geen fouten durven maken is dat je achteraan fietst en door de extra inspanning halverwege de wedstrijd wordt gelost.

Wat je nodig hebt in een agile organisatie is een team van software developers die goed kunnen sturen en die zelf in dat gaatje durven sturen. Wat je nodig hebt zijn managers die durven vertrouwen op die stuurkunst.