Tag Archives: Agile

Get an earful!

Recently I’ve been driving up and down to Nieuwegein a lot more then I did before. That’s about 200 km and although I love listening to music I also found the trip got more and more boring and seemed to last longer each time I had to drive it. Now I’m not one to worry about wasted time that could have spent otherwise on drives like this – I actually embrace the traveltime as relaxing. What did worry me was that especially the second half of the trip I had trouble keeping focus on driving and sometimes even staying awake… (yeah I know.. it’s an age thing).

The solution was as simple as eye… euh ear-opening (for me at least): Podcasts! podcasts

Some of you might go “duh..” by now but for me podcast were something I heard about but never gave much thought to before. Now let me tell you: Podcasts are awesome on long drives!

So far I found 3 differrent ones that I like a lot and listen to regularly now:

  • Agile for Humans: great podcast on anything Agile and Agile coaching. “for Humans” so mostly staying away from tools and technical stuff :) Great host and usually excellent guests.
  • The Infinite Monky Cage: fun scientific podcast where 2 great hosts and funny briljant guests discus  a different scientific topic each episode in an excellent mix of making fun of stuff and learning about it at the same time.
  • NOS op 3 tech podcast: Dutch podcast from national radio where a host and varying panel discuss new gadgets, events and tech news. Nothing deep – but quick and fun weekly update for people who want to be nerdy but really aren’t.

Every now and then I throw some other podcast in the mix (I added SPaM cast today in preparation for my trip monday) but the above ones already deserved the “approved by Mike” certificate :)

Tagged , ,

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 , ,

LKCE2015 – Jim Benson on different kind of WIP’s

No worries – these LKCE2015 posts won’t be as long as the first one… the talks (videos) have been published online now so these posts will be about what I liked about the talks and how they resonated with me instead of summerizing them.

First off; Jim Benson – I say “limit WIP”, you say “Seriously?”. He was introduced as the stand-up comedian of the leankanban community so expectations for this talk were high on the entertainment scale (and yes – he delivered).

jimbenson-lkce2015Jim presented some very interesting stuff introducing several types of WIP and different ways of handling or management needed for each form. Very recognisable story (since I’m always the annoying guy telling people that working on 10 things for 10 differents people is the surest way of disappointing at least 9 of them). Limiting WIP is hard – and what kind of WIP are we actually talking about? Ah well… its a great talk – you’ll recognise a lot no matter what your role in the organisation is – so just go and see it! Really – just go… it’s ok and the rest of this text will be here until you get back :)

There were some fun (and great) takeaways from this talk; and one that resonated big time with me was his remark on the product owner (around 34:25 in the video):

“I said this before, but the product owner is actually the single worst invention in software development history”
Jim Benson during LKCE 2015

To be clear; this wasn’t the single core point made in his talk (not even close) – but it was one of the many things that clicked for me as it relates to the stuff I currently work on. Anyways – I was as “shocked” as the rest of the audience when he said this but this changed to relief on my side pretty to soon. The reasoning behind this statement was the question how it was ever considered a good idea to have one single person know and decide all for a systemen?

I realised that at my current client we actually ran into this and thought of a workable solution for this. What happened is that to allow the product owner to make meaningfull decisions (which actually affect his performance for his client) we ended up with product owners who have mandate over a complete chain of systems from and to the organisations clients. That’s a big scope so the downside to this is that it quickly gets to hard for the PO to know about every detail on everything in his scope. This organisation solved this by providing the PO a team with people who know about these systems and the proces they are adding value to. This team (called a business team) and the PO together act and do the PO job… it’s just the PO who has mandate once someone needs to make a decisions that turns out not to be easy (which I’m convinced won’t happen a lot when you actually think about the work, visualize or order it on a backlog). The business team and the PO do the backlog grooming and all the preparing work for the Delivery teams. Delivery teams which are btw dedicated to that PO and business team (so teams still don’t have more then one PO).

Anyways – don’t shoot me on not following some exact theory or method here, yes we do still run into problems with this setup as well – but main thing: for now it seems the be the best fitting way that works best for most of our teams :)

Ah and finally – did I mention this already? Go see the video! (and check him out on twitter as well – his twitter name is @ourfounder)

Tagged , , ,

Zelforganisatie, in den beginne was er…

men-with-puzzle-piecesVandaag weer een ervaring opgedaan die maakt dat het zo gaaf is om te doen wat ik momenteel doe; Agile trainer/coach bij een klant waar enerzijds veel moet gebeuren maar waar tegelijkertijd de ruimte en het enthousiasme er veelal wel is en er dus ook heel veel gebeurt. Dit voorbeeld begon ergens in augustus na aanleiding van een pittige maar ook verfrissende discussie op een vrijdagochtend over hoe teams te faciliteren bij hun start naar Agile en DevOps met in het achterhoofd de doelstelling de teams ook gaandeweg zelforganiserend te laten zijn. Toen die discussie dat weekend begon in te zinken (zoals dat wel eens gaat in chaotische hoofden zoals dat van mij) en ik ook (toeval bestaat niet) in datzelfde weekend dit artikel “the self organising  organisation” tegen kwam heb ik op die maandagochtend een memo de organisatie in geslingerd waarin ik een wild voorstel deed om onze teams ook op deze wijze zichzelf te laten samen stellen. Een (voor deze organisatie) wild idee waar ik veel zeer positieve reacties op kreeg maar men ook nog diverse beren op de weg zag. Te vroeg? te risicovol? Op dat moment kwam het er iig niet van.

Een tijdje niks  tot medio november zich weer een kans voordoet. Een bepaalde business eenheid sluit met een deel van hun organisatie aan bij onze pilot/proeftuin en laat het bedenken van welke teams er nodig zijn over aan een groot en representatief deel van de mensen uit de organisatie zelf. De volgende stap lijkt opeens voor de hand te liggen – als ze zelf de teams ontworpen hebben, en de verse product-owners bekend zijn, durven we dan ook het vullen van die teams aan de mensen zelf over te laten? Het aantal teams en de schaal is weliswaar aanzienlijk kleiner dan in mijn oorspronkelijke memo in augustus voorgesteld werd maar juist dat blijkt een argument te zijn waarom men het experiment wel aan durft. De keuze voor de betrokkenen is dus wel beperkt en zal door sommigen wellicht ervaren worden als een open deur maar we besluiten met het management van de business eenheid dat de kans en toegevoegde waarde te groot is om het niet te doen.

Continue reading

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 , , , , , ,

Follow the rule, break the rule, be the rule

240px-ShuHaRi

Shu-Ha-Ri betekent letterlijk de kata omarmen, afwijken van de kata en de kata loslaten. Welke klassieke Japanse kunst je ook volgt, altijd heb je te maken met ditzelfde onderwijsproces. Het is een unieke aanpak die al sinds eeuwen in Japan bestaat en waardoor vele oude Japanse traditionele kennis bewaard is gebleven zoals krijgskunsten, bloemschikken poppenspel, theater, poëzie, schilderkunst, houtsnijwerk en weven.

[ Akido Parkstad, Martin Fowler of meer… ]

 

Tagged , , ,

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 , , , ,

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 , , , , ,

DevOps – een waar liefdes verhaal…

devops-shieldNa Agile, Scrum en KanBan zie je de laatste tijd steeds vaker (interessante) artikelen over DevOps verschijnen. DevOps is voortgekomen uit de frustratie dat veel IT-projecten op gebied van software te laat worden opgeleverd, instabiele producten opleveren, onderpresteren, meer problemen veroorzaken dan ze oplossen en zodoende zeker gedane investeringen niet terug verdienen. Tijdens het bijlezen op dit onderwerp raakte ik door het lezen van “DevOps – A Valentine’s Day Fairy Tale” van Matt Watson  geïnspireerd tot het opschrijven van het Nederlandstalige DevOps sprookje

Heer, bijt u uw duim naar ons?

Continue reading

Tagged , , , ,