Agility one step at a time

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