Principles and Practices of ... Showing Up With the Needed Value, at the Needed Time, for the Needed Cost

There are no shortages of project, software development, or any other technology methodologies or processes being put into practice today. And, yet, these methods rarely appear to have been developed on a foundation of immutable, unambiguously simple principles.

Starting with the PMI "products" for agile development, moving to firms that provide training and consulting for product or project development, to individual voices describing how you should be doing things while spending other people's money.

Without a clear understanding of the principles by which the processes and practices have come about and how they can be successfully applied, in a specific domain, with defined measures of effectiveness and performance, there is little chance applying those practices will be successful.

In our complex system of systems project management domain, there are Five Immutable Principles of success:

1. Where are we going? - what does Done Look Like in Units of Measure Meaningful tho the Decision Maker?
2. How do we get there? - what's the Plan to arrive at Done with the needed Capabilities to accomplish the mission or fulfill the business strategy?
3. Do we have enough time, resources, and money to get there? - suggesting we'll discover this along the way is called a Death March, as described in Yourdon's book of the same name. Agile does not help in the least if you don't know what Done looks like. Without knowing Done in terms of capabilities, Done can only mean "we've run out of time and/or money before arriving at something the customer has paid for.
4. What Impediments will we encounter along the way? - all development work operates in the presence of uncertainties. Reducible uncertainties and Irreducible uncertainties. These uncertainties create risk. And as Tim Lister tells us Risk Management is How Adults Manage Projects.
5. How do we know we are making progress to plan? - the simple answer, we must measure physical percent complete again in units meaningful to the decision-makers. These measures start with the Effectiveness and Performance of the produced outcomes defined upfront, so we'll recognize them when they arrive.

A Simple Definitions of Agile

Given the endless discussion of what it means to be agile, usually driven by those trying to sell you a solution to a problem they have failed to define, here's a simple definition, from Ashton Carter, Under Secretary of Defense for Acquisition, Technology, and Logistics, Sep/Oct 2010, Defense AT&L Journals.

Agile Means ...

All Project or Product Success Starts with Capabilities Based PlanningW

Without know what Capabilities are needed to accomplish the Mission or fulfill the Business Strategy, we can't know what Done looks like before we run out of time and money

The Customer wants to buy a capability to solve a problem ...

Here's an actual example of Capabilities Based Planning, using Agile Software Development and a health insurance enterprise business management system, deployed with Iterative and Incremental management processes

A Cautionary Tale

Agile is about People

• If the integration doesn’t start with the behaviors of the people, Agile is not starting off on the right foot.
• The Guidelines of EVM are necessary, but far from sufficient for success when applying Agile.

Agile is about Process

• The success of Agile depends on performed the ceremonies of software development (Scrum, XP, DSDM, Crystal).
• Top to bottom automation is needed, starting with the PMB, flowing to the Agile Development System, and back to the Capabilities Based Plan.

Agile is about Tools

• Automation of everything is needed for Agile to Scale beyond de-minimis projects (where no one cares if you're late, over budget, and what you built doesn't work).
• Skipping any opportunity for automation will decrease the probability of success.

In The End, It's About Knowing What Done Looks Like in Some Form

Without knowing what DONE looks like in units of measures meaningful to the decision-makers, you're simply spending other people's money to explore not being able to recognize what you'll discover is useful. This is a core fallacy of many of the talking heads of agile - Oh let's just start coding and we'll discover as well go if we're on the right path.

If that's your approach, make sure those paying you to produce Value concur with that wandering around because, in fact, you're on a Snipe Hunt.

In case you weren't in the Boy Scouts in the 1950's and 1960's in the?Texas Panhandle, a?snipe hunt?- a?fool's errand - is a type of practical joke that involves a?group of?people making fun of credulous newcomers by giving them an impossible or imaginary task. The novice Scouts were sent on a Snipe Hunt, out into the woods and along the?Canadian?River?in search of a mythical creature, with a bag and a flashlight.

The search for a method of making decisions in the presence of uncertainty - reducible (event-based, Epistemic) and irreducible (statistical variances, Aleatory) in the underlying work processes) - produces?the same outcome. An empty bag at sunrise.