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!
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).
Jim 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)
Vandaag 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.
Ja, ja… de laatste post was al weer eeuwen geleden – maar dat is het voordeel van een eigen persoonlijk blog: “it’s my party and blog when I want to…”. En aangezien de voertaal op het onderwerp van deze post (de Lean Kanban Central Europe conference) voornamelijk in het engels was – the rest of this post will also be in english.
I felt the need to quickly write down some of this stuff cause I (sort-off) know how my mind works – or at least enough of it to predict the gap that will be here if I wait to long. So I started with transcribing my notes from the first keynote session from monday. And just to warn you – there’s this TLDR risc… now consider yourself warned.
