An
Andy — I’ve known him for a year in-person and somewhat longer virtually — has a talent for word golf, putting important concepts in few words. At the Lean Kanban UK 2013 conference, he came up with the shortest definition of Kanban fitting in only 140 characters.
The Condensed Guide went through a review process by progressively increasing circles of reviewers. Starting with a relatively small number of Kanban coaches and trainers, the authors shared the refined versions of the Guide with broader circles, then with Lean Kanban conference attendees, and then with the public. Being one of the reviewers, I know Andy put a lot of work into the Guide. I wish the Brickell Key award committee recognizes his contribution with a nomination this year (here’s the link where you can do what I did about that.
Now I’d like to talk about how not to read this Guide.
I’ve heard the following phrases (or their variations) in many exchanges with various Agile coaches quite often. I need to qualify they weren’t Agile beginners, but from people with lots of experience, bona fide peer-reviewed status within the Agile community, and some pricing power when it comes to charging clients for Agile advice. Let’s listen:
- Agile Manifesto doesn’t say that…
- Scrum Guide says…
- According to the Agile Manifesto…
- Where in the Scrum Guide did you find that?
While I suppose some Kanban users will make similar references to the condensed Kanban guide, I expect experts to do so rarely.
I’ve been asked this week to give advice on some metrics-related material. My response was, the material was sound, but I pointed out it was a mismatch to the low organizational maturity. However, in a different organizational unit of the same client company, I made the opposite recommendation.
I couldn’t derive these two diametrically opposing pieces of advice from published values and principles. I didn’t do it by gut feel. I could have just said, let’s do it this way and then inspect and adapt, but that would’ve been nothing more than a case of intellectual laziness. I suppose there could have been some practice or algorithm to lead me to these two conclusions using different inputs. But I’d prefer having no such practice. Otherwise, we’d have to teach people to do things at the practice level. We’d get into arguments about the right way to do the practice. This would lead to dogma. Some of us would become purists, while others would practice the practice-but.
Instead, I simply made sense of a large number of available stories, of success and failure, my own and told by my peers (we meet often at conferences and leadership retreats, co-train, collaborate on engagements and keep up frequent correspondence). Even though these real-world stories are messy, gathering them, making sense of them and deriving useful heuristics are all teachable skills.
The Kanban community values observing what people actually do, how they act, what we can reasonably infer about their thinking. Kanban experts value paying attention to storytellers, making sense of their stories, and continuously questioning contextual appropriateness of their own actions and recommendations. We value it more than the printed word. We understand the knowledge worth having — and from the clients’ point of view, worth paying for — is and will be messy and conflicted.
In the four above situations, Kanban coaches didn’t assign much value to what the four respective Agile coaches said or to the printed word of the Agile Manifesto or the Scrum Guide. Instead, we simply paid attention to what the Agile coach actually recommended to their client in a given situation. Because we’ve come to value one thing more than the other.
The Essential Kanban – Condensed Guide will no doubt educate many current and future Kanban practitioners. But I don’t expect experts or proficient practitioners of the method to do the following very often: open the Guide on some page and say, here it says so.
Source link