Iedere keer als ik (iets over) een F16 hoor, zoals bijvoorbeeld die knal hier gisteren in de provincie denk ik aan Agile… “kunst, jij denk altijd aan Agile!” – inderdaad – dat is (helaas) ook waar maar er ligt sinds ongeveer een jaar ergens in mijn grijze masse een associatie tussen de F16, de architect van de F16: John Boyd en zijn bijdrage aan de Agility; de OODA loop (Observation, Orientation, Decision en Action).
Daar gaat die JSF voor mij niks aan veranderen vermoed ik
A post mostly for myself… so I can find this again later – but such a good read I felt it deserved to be shared in a better way then just a link way down below…
Click the picture to read Henrik’s reasoning and explanation behind it – it’s a great read!
Een paar weken terug, werd ik door één van de teams die ik momenteel coach expliciet gevraagd of ik bij hun retrospective aanwezig kon zijn. Ze weten dat ik regelmatig sowieso wel aanschuif, maar nu was er dus blijkbaar echt iets aan de hand 🙂
Ze gaven aan dat ze bij het schatten regelmatig tegen dezelfde problemen en discussies aanliepen en inmiddels waren die al zo hoog opgelaaid dat sommige teamleden “gewoon” weer terug wilden naar urenschattingen. Het team waar het om ging was kortgeleden gestart met het doen van storypoint schattingen. Bij hun sessies bleef keer op keer de vraag naar voren komen wat ze nu precies aan het schatten waren. Gaandeweg terwijl ze me het dilemma voorlegden realiseerde ik me dat ik ze waarschijnlijk zelf met dit probleem had opgezadeld:
Mike, we doen nu geen urenschattingen meer maar storypoint schattingen. Daarmee schatten we items relatief tov elkaar op basis van complexiteit… maar wat is nou precies complexiteit?
Ooit tijdens de trainingen waar storypoints en planningspoker was uitgelegd werd (terecht) nogal de nadruk gelegd op dat urenschatten voor mensen een erg onbetrouwbare manier van schatten is met ook nog eens maar heel beperkte waarde.
In plaats daarvan kon je beter relatief gaan schatten (met de relatieve eenheid van storypoints). Bij het werken met uren kan bijvoorbeeld de ene ontwikkelaar iets op 40 uur inschatten terwijl een ander er maar 16 uur voor nodig denkt te hebben – zo onstaat er dus een (ongewenste) afhankelijkheid tussen de raming en de ontwikkelaar. Diezelfde twee ontwikkelaars kunnen het er echter wel over eens worden dat hetzelfde item 2 punten is – waarbij ze allebei iets wat ze grofweg 2x zo veel tijd kost dan ook allebei als 4 punten in zullen schatten.
Na de training ging het betreffende team er (dus) vanuit dat ze dus niet meer op uren wilden ramen maar op complexiteit – ik vermoed zelfs dat ik ze dat zelf verteld had (foei!) en gaandeweg deze discussie kwamen we er dan ook op uit dat dat onjuist was.
Immers, een enorme bult werk kan best bestaan uit heel veel eenvoudig werk – en een complexe taak kan ook relatief veel kleiner zijn. De uitkomst van de discussie was dus ook een bevestigend:
we moeten schatten op inspanning ipv complexiteit!
(en slechts één van die factoren die daarbij een rol kan spelen is complexiteit).
Soms kom je op het wereldwijde web “oude” zaken tegen die toch/nog steeds klikken. Zijn vaak de beste – want blijkbaar zijn ze houdbaar.
In dit geval klikte via-via opeens door naar deze beschrijving van noodzakelijk kwaliteiten van Agile werkende projectmanagers en leidinggevende: De “Declaration Of Interdepence” van het ALN “(Agile Leadership Network). Snelle (voor de vuist weg) nederlandse vertaling (die ik zeker nog eens onder de loep moet nemen):
Agile en adaptieve methodes om mensen, projecten en waarde te verbinden.
Wij zijn een groep projectleiders die zeer succesvol zijn in het leveren van resultaat. Om deze resultaten te bereiken:
(vertaal tips en verbeteringen zijn van harte welkom!)
Nee echt! Dank dank!
… en het onderschrift is zo mogelijk nog briljanter,
maar daarvoor verwijs ik jullie naar de site van goerp!