Agility one step at a time

This is a personal and subjective perspective into the Accredited Kanban Consultant (AKC) community built on the story of how it unraveled for me over several years. The AKC program is driven and supported by Kanban University - https://kanban.university/resources/kanban-development-path/akc-credential/ . I went through most of my Kanban training between 2017 and 2019 and navigated through, course by course, with lofty expectations and a large baggage of misconceptions. The learning experience not only allowed me to accumulate a great amount of knowledge, but - hindsight 20/20 - also transformed the way I think and operate on a daily basis at work. Somewhere on that timeline I realized that experienced Kanban practitioners do not build their main value proposition on contributing more info, adding more practices and layering on more "Agile or Lean stuff". They help with deeper understanding of the concrete problems to solve and a systemic perspective into the concrete day-to-...

Command and Control is a controversial term that has gathered a lot of negative connotations over the years (or maybe decades?!?!?). First, I'd like to shift the lens on it, by defining the Command part as the feed forward - the signal traveling right-bound in the picture below -, while the Control part is the feedback connection - the signals traveling on the lower connection back towards the left of the diagram. Right away, I feel way better about it. Since it allows me to see it in the perspective of the learning system: 1. First, the entity driving it issues a command. 2. Then, the system proceeds to execute in accordance with its understanding of that command. 3. At this point, one or multiple control modules collect measures/signals/metrics/parameters about the system. 4. In this step, the driving entity is presented with these points of feedback. 5. Finally, the driving entity makes a decision based on the info at hand to issue the next command. This mental model applies to ...

In this post, I am going to challenge our current understanding of the value of Intellectual Capital. The concept has been widely treated and researched over the last several decades and a simple scan of the corresponding page on Wikipedia - https://en.wikipedia.org/wiki/Intellectual_capital -, simply defines it as: "... the result of mental processes that form a set of intangible objects that can be used in economic activity and bring income to its owner ( organization ), covering the competencies of its people ( human capital ), the value relating to its relationships ( relational capital ), and everything that is left when the  employees  go home ( structural capital )... ". So far, I'm guessing there will be significant agreement on this context. My challenge starts when I look at the balance sheet of a regular company - e.g. a public company that shares their balance sheet details for disclosure purposes. I've reviewed a handful - I have to admit my skills, knowl...

The fourth value of the Agile Manifesto is Responding to change over following a plan. Let's start with Eisenhower's words - " Plans are worthless, but planning is everything ". It makes no sense to start work on any initiative without planning at all. But it also makes perfect sense to constantly inspect our plans and if they are not realistic anymore or are irrelevant or out of date, we should change them. Another aspect that is really important here is the depth and width of our plans. If we have a detailed plan for task by task work for every person on our initiative for the next several months, I would submit that we are assuming NOTHING will change for the duration. I'm not sure about you guys, but I've never been on an initiative where nothing changed for that long! Between clarifications to requirements, technical and/or technology emerging details, core business stakeholders changing their minds about priorities, regulatory and compliance changes...

The third value of the Agile Manifesto is Customer collaboration over contract negotiation. This is a tough one - why on Earth would anyone want to mess with the contractual agreements, some explicit, some implicit, sometimes between multiple and diverse parties. Let me propose an approach that is very much based on (personal, but not only...) experience. Every time - towards the end of initiatives/projects/large releases -, that we had to go back to the contractual artifacts to review, discuss and potentially argue over provisions, scope items, other related details, there was a lot of fallout, bad blood, mistrust, etc. In general, nothing much good comes out of these situations. Reflecting on these, I noticed two emerging patterns: a. If the customers and end-users were happy with the deliverables - functionality, capabilities, quality, timeliness, etc. - nobody would bother to retrace our steps to the contractual details. b. Most of the times when things worked out, it was bec...

The second value in the Agile Manifesto re-calibrates our focus on value to be delivered to the business. The idea here is that the best way to gauge value to the business is through actual Working Software. Not that there is no value in documentation but rather that the documentation is a means to get to working software, with all the implicit characteristics and quality. It does not amount to business value by itself, but rather supports the delivery in various ways and aspects. It is not a matter of black or white - "either we are traditional so we focus on precise description of the project deliverables in document artifacts described by specific methodologies, or we're Agile and hence we don't need any documentation!". It is a matter of the self-organizing team focusing on continuously fine-tuning and evolving their needs for just-enough, and just-in-time, fit-to-purpose artifacts. The use of these artifacts is fundamentally different now - where they are me...