Category Archives: Agile

Als je het zo goed weet, dan doe je het toch lekker zelf!

Eerlijk is eerlijk – ondanks dat we het (inmiddels) al een aantal keren eerder gedaan hadden bleef het toch spannend. ’s Ochtends in de auto kon ik diverse “Maar wat als…” gedachten niet onderdrukken. Maar wat als er helemaal geen ontwerp uitkomt… maar wat als ze het niet eens worden… maar wat als de manager toch weer zelf het heft in handen neemt?

Deze “ontwerp-je-organisatie” sessie waar ik naar toe onderweg was is voor mij één van de next-level voorbeelden van de principes “zelforganisatie” en “verantwoordelijkheden laag beleggen” die beide terugkomen in het cultuur manifest van deze organisatie. Gewoon aan de mensen zelf vragen hoe zij denken dat je de organisatie het beste kan inrichten om je klant het best te helpen… klinkt heel logisch… maar zo spannend :)

Continue reading

Tagged , , , ,

Prime Directive

Wanted to make sure I had the retrospective Prime Direction within reach for a session today…

Regardless of what we discover, we must understand and truly believe that everyone does the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

(as taken from Ben Linder’s website which has some pretty cool stuff on Agile and even more awesome stuff specifically on doing good retrospective’s)

…of in het Nederlands:

Ongeacht wat we ontdekken, moeten we begrijpen en er op vertrouwen dat iedereen het uiterste heeft gedaan om zijn of haar werk te doen, binnen de grenzen van de kennis van het moment, zijn of haar vaardigheden en capaciteiten, de beschikbare middelen en de situatie zoals die was.

SAFe from a LeSS perspective

I ran into this nice informative post called “SAFe impressions from a LeSS Practitioner” on the “Fail fast, move on” blog (good reads, even tho or even more because I don’t always agree) . This specific post resonates with me because I know several people who are slowly putting a nuance in their original dislike of SAFe… the writer of this post not only states honestly what he likes and dislikes about SAFe (him coming from LeSS) but he also states why… he raises some good points…

It’s a theme for me the coming weeks also since:

  • I’ll be teaching my third “Leading SAFe” class in October/November. Always a lot of good discussions there on the pro’s and cons of SAFe.
  • I’m off to enjoy a “Certified LeSS practitioner; principles to practice” in October (by Graig Larman) and so looking forward to that! Maybe I should write a “LeSS from an SAFe perspective” blog afterwards :)
  • together with a colleague of mine we’ll most likely/hopefully be doing our fun and tongue-in-cheek “LeSS vs SAFe Battle” presentation at least two more times somewhere this year (we submitted it for Samenwerking Noord’s Agile Congres)

Lots of fun stuff happening! Lots of learning going on…

F16? Oja… OODA

f16Iedere 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

Henrik Kniberg on his MVP picture…

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!

Making-sense-of-MVP-

 

Tagged , ,

Het is inderdaad inspanning ipv complexiteit…

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.

simple-complex

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).

Tagged , , , , , ,

Declaration of Interdepence?

Soms kom je op het wereldwijde web “oude” zaken tegen die toch/nog steeds klikken. Zijn vaak de beste – want blijkbaar zijn ze houdbaar.

doi1In 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):

Verklaring van onderlinge verbondenheid(?)

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:

  • Verhogen we de Return on Investment door te focussen op continue stroom van waarde.
  • Leveren we betrouwbare resultaten door het betrekken van opdrachtgevers middels veelvuldige interactie en gezamenlijk eigenaarschap.
  • Verwachten we onzekerheid en sturen daarop middels het werken met iteraties en rekening houdend met verandering.
  • Geven we ruimte aan creativiteit en innovatie door te erkennen dat medewerkers de belangrijkste bron van waarde vormen en een omgeving neer te zetten waar ze het verschil kunnen maken.
  • Verbeteren we de prestaties door teams verantwoordelijk te maken voor hun eigen resultaten en effectiviteit
  • Verbeteren we effectiviteit en betrouwbaarheid middels situatie specifieke strategieen, processen en manieren van werken.

(vertaal tips en verbeteringen zijn van harte welkom!)

Leuke collega’s

Nee echt! Dank dank!

continuous-delivery-mike… en het onderschrift is zo mogelijk nog briljanter,
maar daarvoor verwijs ik jullie naar de site van goerp!

Tagged , , , ,

The Phoenix Project: DevOps in roman vorm

Eind 2014 was ik alvast begonnen met één van mijn goede voornemens voor 2015: Meer lezen! Of… nu ik erover nadenk – heb ik door nog “even” een boek te lezen in 2014 de lat (“meer…”) voor dit jaar alleen iets (nl. 1 boek) hoger gelegd?

Hoe dan ook – ik heb dus maar weer eens een boek gelezen (voor het eerst van mijn leven een compleet e-book maar ook dat is niet relevant). Vakgerelateerd, maar in roman vorm. De interesse en het voornemen om dit boek te gaan lezen was er al eerder maar door het nieuwe veranderingsproject waar ik sinds vorige week projectleider van ben geworden is ook opeens enorm relevant geworden.

The Phoenix Project (want daar gaat het over) is wat mij betreft een aanrader voor iedereen die wat meer wil weten over Continuous Delivery, DevOps, Kanban en de weg erna toe. Sterker nog – door de manier waarop het boek geschreven is en de verschillende (behoorlijk stereotype) personages in het boek zal het voor iedereen in de IT een feest der herkenning zijn.

PPhardcoverDe roman verteld het verhaal van Bill die min of meer tegen wil en dank promotie maakt en verantwoordelijk wordt voor de IT binnen het onderdelen bedrijf Parts Unlimited. Het bedrijfs meest belangrijke IT-initiatief (wat eindelijk de business eens echt zal gaan ondersteunen) loopt gierend uit de klauwen en de CEO eist dat IT zijn zaken op orde krijgt. Onder de druk en dreiging van ge-outsourced worden moet er dus eea duidelijk en veranderd worden. Met wat hulp van een wat vage guru ziet Bill het licht en red de IT (zoals altijd) het bedrijf van ondergang… in dit geval door de introductie en het toepassen van principes uit Theory of Constraints, Lean, Kanban, Continuous Delivery en DevOps.

Dat is ook meteen mijn kantekening bij dit boek. Qua lezen is het aanrader… in drie avonden – en wat wachtpauzes her en der –  was ik erdoor op het scherm van mijn telefoon. Makkelijk leesbaar, leuk om te lezen… feest der herkenning – maar het het is al met al wel een hallelujah verhaal. De zaken waarmee gexperimenteerd en verbeterd worden bij de IT van Parts Unlimited mislukken niet, de CEO en beveiligingsfunctionaris ziet uiteindelijk toch het licht en de slechterik (die andere achterbakse projectmanager) delft natuurlijk het onderspit…

Ja, leuk boek! Het is en blijft een roman – maar het is zeker een aardige en toegankelijke manier om een eerste indruk te krijgen van de voordelen die Continuous Delivery, DevOps en Kanban kunnen bieden.