Category Archives: Agile

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.

Op herhaling: het Agile manifesto

De afgelopen 2 maanden heb ik vreselijk vaak/leuk trainingen staan geven voor zowel klanten als Ordina intern. Bij alle varianten (de Agile en Scrum experience, de Kanban Game workshop en natuurlijk de alle DUO agile trainingen) komt het Agile zijn/werken en het Agile manifesto ruimschoots aan bod. Het is (in mijn ogen) het fundament voor de verschillende Agile methodes – en dus is het belangrijk om dat fundament keer op keer duidelijk en op stevige manier neer te leggen. De leukste trainingen (tenminste waar het dit aspect betreft) zijn de managementgroepen en de teams die al lang Agile werken.

Bij de eerste groep is het de uitdaging om eea goed te laten landen – het kwartje moet vallen, men moet zich beseffen dat het nogal iets betekent. Tijdens deze trainingen is de oefening waarbij de groep zelf de Agile uitgangspunten samenstelt erg zinvol en vermakelijk; aan iedereen in de groep wordt gevraagd welke van deze 8 belangrijke aspecten zijn volgens jou het meest kritisch voor projectsucces?… en welke van deze 8 stuurt of managed de organisatie op?

Voor de tweede groep zijn de 12 onderliggende principes vaak de eye-(her)opener. Simpelweg bij elk principe kort de vraag stellen: “ok.. dus jullie zijn Agile – doe je <dit> dan ook echt?” en vervolgens handopsteken levert al plenty discussie op over het betreffende principe en de werkwijze van het team – een leuk startpunt om coaching op te pakken. Binnen DUO hebben we de maturity matrix voor Agile werken gemaakt (zie voor de basis de vorige post) en daarmee zetten we het team dan aan het denken over wat ze verder zelf kunnen verbeteren.

Voor iedereen nog even het Agile manifesto dan? Ok… ik beloof dat het mijn laatste keer in 2014 is:

Wij laten zien dat er betere manieren zijn om software te ontwikkelen
door in de praktijk aan te tonen dat dit werkt
en door anderen ermee te helpen. Daarom verkiezen we
Mensen en hun onderlinge interactie boven processen en hulpmiddelen
Werkende software boven allesomvattende documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven het volgen van een plan
Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld,
hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.

En nog even (vooral nav de vragen tijdens de trainingen) Ja… alle acht aspecten zijn belangrijk – maar realiseer je goed dat links de meest kritische succesfactoren zijn, die het meest gaan opleveren als je naar succes wil toewerken. Rechts lijkt veiliger, rechts levert meer kansen op je in te dekken – de schuld voor mislukken ergens anders neer te leggen en mogelijk meer kansen succesvoller de financiele risico’s van mislukken ergens anders te verhalen… maar als alle partijen er echt een succes van willen maken zou de focus vooral op de linkerkant moeten liggen.

Rest mij nog tot slot; goede jaarwisseling allemaal en alvast de beste wensen voor 2015. Eén van mijn goede voornemens is wat vaker Agile/Scrum/Kanban/DevOps inhoudelijke posts te gaan schrijven het komende jaar. Het lijkt erop dat ik de eerste helft van het jaar mee mag helpen bij een pilot om DevOps te gaan werken met 3 van de teams waar ik verantwoordelijk voor ben… stof genoeg vermoed ik – dus het zou maar zo een succesvol voornemen kunnen worden 😉

note-to-self, some interesting old stuff I still need to read: Agile dood / Agile cultuur / leuke Agile oefening? / moe van Agile, Scrum, Kanban…

Maturity matrix coaching tool

At the customer I’m currently working for I’m part of this team assigned with creating and implementing a organization wide Agile training and coaching program in support of their bigger organization change which includes a broad agile way of working. Exciting stuff, lots of pitfalls for sure, a source for interesting discussions, learning a lot and above all a whole lot of fun. What we as a team ran into during our work was the need for a tool to coach the different teams in a way to let them discover themselves how mature they were with the agile implementation and what they should focus on next.

Kanban - Depth of Kanban Implementation - InstructionsI remembered David Anderson presenting a radar chart as a way to plot the maturity of a Kanban implementation during the Kanban coaching masterclass I attended. Trying to re-discover some of that I ended up at Christophe Achouiantz website where he describes his approach for using the radar chart as a coaching tool – very cool and some really awesome other stuff on his website as well btw. I was already very enthusiastic about the radar chart approach the first time I heard it, Christophe provided some great hints and tips to add to that.

This same past week a colleague of mine and myself ended up at an Agile Holland meeting where we got talking with a consultant describing his visualization tool for the maturity of a scrum team. It turned out he used the somewhat same technique Xebia used within this organization for visualizing DevOps maturity which is matrix approach/presentation that somehow seems to resonate within the organization a lot better then the radar chart I liked so much 🙂

Anyways – we decided we’re gonna put together an Agile maturity matrix specific for this organization to help the teams measure their progress and plan their goals and as an fun exercise I started to transform David’s and Christophe’s radar charts to a Kanban Maturity Matrix. Kanban Maturity MatrixNothing to fancy – and I wholeheartedly believe that everyone should fill, edit, tweak and tune this to their own specific situation. I think this matrix view is a very powerful way of visualizing and representing a maturity level to a team you’re working with.

For full jpg click the image and the powerpoint (incl. empty matrix) is available here for download – feel free to grab, customize and enhance. It would be great if you would let me know if you do!

Tagged , , , , ,

Iets om over na denken

Sinds vandaag volg ik Bob Marshall (via Twitter) omdat iets meer wilde weten over rightshifting en zijn Marshall model. Hieronder één van zijn tweets die mij meteen opviel… vooral natuurlijk omdat ik heel hard roep dat ik naast (Agile) projectmanager ook Agile coach ben:

@flowsensei: Agile Coach is as much of an oxymoron as Agile Project Manager.

Toch maar even opgezocht:

Een oxymoron is een speciaal geval van de paradox: die een schijnbare tegenspraak bevat, maar bij nadere beschouwing blijkt te kloppen. Bij het oxymoron blijft de spanning van het betekenisverschil echter in stand. Een oxymoron wordt vaak bewust aangewend voor retorische, poëtische of andere esthetische doeleinden. Dat is een verschil met de contradictio in terminis: ook dat is een tegenspraak, maar dan een waarbij de spreker zichzelf aantoonbaar tegenspreekt en dus een ondeugdelijk argument hanteert.

[wikipedia]

Daar ga ik maar eens even over nadenken 🙂

Ergens op zijn blog schrijft Bob dat hij het vreemd vind dat zo weinig mensen zichzelf als change consultant of change agent zien terwijl er wel zoveel mensen bij hem komen voor advies over het veranderen van hun organisatie. *grinnik* Agile change consultant klinkt wel luxe – of het nou allemaal heel veel uitmaakt vraag ik me af. Alhoewel het handhaven van de term projectmanager wel op een bepaalde manier indruist tegen een aantal Agile aspecten en het helemaal geen kwaad kan om meteen vanaf de start duidelijk te maken dat Agile geen 1, 2, 3 klik-klaar methode is maar voor de meeste organisatie een verandering vergt naar een mindset die door een heel team, hele organisatie gedragen en gevoeld moet worden.