Agility one step at a time

This time of the year I usually find time to reflect on the past few months and sometimes even further back. And I rejoice in some successes and positive experiences that randomly (or is it?!?!) come to mind. I also cringe at some of the opportunities that I missed, sometimes despite the fact that they were staring me in the face! So let's "rewrite" some of those "close encounters of the third degree" together over the next couple of pages right here. Setup - consultant Ted walks into the office of Mary, Head of Line of Business XYZ at a large financial organization. Ted was recommended to Mary by another executive at a similar financial institution in the context of business improvements that resulted in clear, demonstrable positive trends on the balance sheet of the organization and specifically for a similar LOB. The two are sitting in Mary's office, on a frigid Monday morning in early January. The view out the window is filled with the top of the downtow...

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

"Individuals and interactions over processes and tools" (http://agilemanifesto.org) - t he first value in the Agile Manifesto is a reckoning of the issues stemming from the current state of affairs and a call to action to re-focus on what turns out to be the most important fact - that especially in software development (but maybe not only...) each person operates differently, but more so that a person will operate very differently in different teams and environments. Hence the agile approaches and methodologies are much more detailed in describing objectives and principles than providing specific and direct predefined processes and tools to be re-used over and over again with little to no adaptation to the current conditions. Because of this shift there is a lot of FUD (fear, uncertainty and doubt) in the industry, and newcomers to Agile are concerned with the "lack of direction" and the "lack of structure" in the new world. Just to clarify - this is...

"We are uncovering better ways of developing software by doing it and helping others do it." -  http://agilemanifesto.org This is how the Agile Manifesto starts. Let's just pause for a few minutes - I know how hard it is to stop thinking of deadlines, and technical challenges, and releases and velocity and burn down charts, etc., etc. But do me a favour, grab a cup of coffee or tea or your favourite brew, sit down, take a few deep breaths and join me for a few minutes. What we're saying in that awesome starting statement is that: 1. We're developing software. And while we're doing that... 2. We're helping others develop software. And while we're doing that... 3. We are uncovering better ways to do just that - software development. Here's a few perspectives on how to look at these 3 activities side by side. First on my mind - if we're uncovering better ways to do software development, then we all need to agree we don't have it ...

Have you considered the ripple effects of your day to day work? As Scrum Masters, Tech Leads, Managers or Agile Coaches most or our actions could have all kinds of more or less predictable effects. Let's consider a few situations. A Scrum Master that tries to support their team on their Agile Journey, could easily get at odds with the values and principles of the larger organization that is earlier in its journey. There are plenty out there that still assume that the Scrum Master should provide the same command and control perspective and the same updates and "dashboards" and "metrics" like the Project and Program Managers in traditional initiatives. A Tech Lead that pushes hard for the team to adopt some really advanced XP techniques - mob programming, ATDD, code analysis, etc. - too early, might turn off some other team members which will impact progression of the team through the forming-norming-storming-performing cycle. Note - adopting these technic...