Category Archives: Kanban

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…

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

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.

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