Agility one step at a time

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