Update to Agile Manifesto and Its Impact On Traditional Project Management

Scott Ambler writes in an IBM Developer Blog that the agile manifesto needs updating. Scott is one of the original thought leaders in "agile" process. In the past, he has confused the concepts of Earned Value Management (ANSI-748B style) with Business Value Delivery, but that gap seems to have been closed with his current concepts.

His post presents a logical and executable approach to managing software development projects using agile. Scott connects the notion of "deliverables" to the assessment of the value of these deliverables. Our own Deliverables Based Planning^® method does that for traditional projects, including enterprise IT.

This approach to defining value of the deliverables in units of measure meaningful to the stakeholders is starting to be common. This is the basis of the Integrated Master Plan / Integrated Master Schedule paradigm, where increasing maturity of the Technical Performance Measures defines what progress is being made.

The Updated Agile Manifesto and its Connection with Traditional Project Management

Here's Scott's suggestions for moving the manifesto forward. Outside the agile software development domain, where software intensive projects still occur, hardware, steel and concrete, human intensive projects are common, there are useful ideas to be taken from these improved principles. As well there are still gaps in understanding on what it means to apply agile to projects that cannot respond to the manifesto.

Here's some comments on the impact of this approach for traditional projects.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.
   • In the defense and space business and in enterprise IT a "Plan" defines the strategy for the successful delivery of the project's outcomes. The Integrated Master Plan / Integrated Master Schedule (IMP/IMS) paradigm serves us well in defining up front the order of delivery of "increasing maturity."
   • The definition of value and the units of measure of value are not stated in the manifesto. These need to be defined in units meaningful to the stakeholders. Without these definitions, the project has no way of measuring its performance or the actual value to the customer in a predefined way. "Progress to Plan," is a Key Performance Parameter.
2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the stakeholder’s competitive advantage.
   • This notion of change needs to have defined boundaries in many software domains. Can I change the requirements for the rendezvous and docking software system after the propulsion systems that implement it have been developed? Can I change the requirements for business functions of a 50 site ERP roll out, after the auditors have approved those processes?
   • Some context is needed, where the impact of the change is assessed and decisions made on the affordability, risk, and sustainability of this impact.
3. Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 
   • Turns out this process is critical to all projects, not just agile projects.
   • The intervals of two week to a couple of months are found into the Earned Value Management System Descriptions on government contracts subject to ANSI-748B.
   • Work Packages or Tasks (depending where you work) are limited to cross one accounting period.
   • Periodic assessments of progress to plan must take place at intervals short enough to allow corrective actions.
   • This question, How long are you willing to wait before you find out you're late? is answered by the duration of the progress assessment interval.
4. Stakeholders and developers must work together daily throughout the project.
   
   • If it is possible.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
   • This is good business management.
   • But in many environments, that trust is augmented by verification. Especially when systems integration outside the team is needed.
   • There is nothing wrong with verification, Toyota does it, NASA does it, you probably do it with your checking account balance.
6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.
   • This assumes that the delivery team can convey the information verbally and they are co-located.
   • If this information requires data, written reports, travel to a site for inspection of the concrete being pouring or the vehicle being assembled, then face-to-face may not be the best.
7. Working solutions are the primary measure of progress.
   • In the Earned Value Management world this is called Physical Percent Complete.
   • Physical Percent Complete means Quantifiable Backup Data (QBD) (see page 17 for the start of this discussion.) Also the notion of Deliverables Based Planning^® is presented here.
   • Deliverables are what the customer bought. Agile software deliverables or manned space flight deliverables, they still have the same impact on the customer - did you do what I asked for, at the time I need it, for the budget I have for that deliverable?
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
   • This is one of those statements that lacks evidence.
   • It sounds logical, but needs verification.
9. Continuous attention to technical excellence and good design enhances agility.
   • Yes attention to technical excellence is required for success.
   • Technical Performance Measures are a means of defining the units of technical excellence upfront, so we can recognize it when it arrives or fails to arrive.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
    • This is a principle of Systems Engineering.
    • But simple needs a unit of measure as well. What is "simple" in one domain may appear to be complex in another.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
    • There needs to be Quantifiable Backup Data to support this conjecture.
    • Here and example of an architecture that emerged from highly organized teams - not self organizing - The Constellation Architecture.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
    • This occurs on government programs at the Monthly Management Meeting.
13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.
    • This is another one of the statements that needs some units of measure.
14. Minimize work in progress and visualize workflow.
    • All good project plans minimize WIP for the simple reason it costs money to store things.
    • For software the "stored" modules "age" away from the requirements base.
15. The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams.
    • Yes, this is restating the obvious.
    • Team members change, subcontractors change, facilities evolve, tools, processes, externalities all change. The organization has to change as well.