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
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.
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:
Lots of fun stuff happening! Lots of learning going on…
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!
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:
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
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
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