2001 Snowbird Resort Utah Original Pictures

Emphasis on "Being Done" in Agile - 90% Syndrome (Mike Cohn)

Courtesy - Mike Cohn

• We often fail to gauge the magnitude of an effort until we are well into that effort. 
• For this reason, conventional estimations are not quite accurate.
• Ask a developer how "Done" something is and you get to hear "90% complete". A week later ask him again, and you get the same reply "almost 90% complete". This happens because the developer has gauged the scope of work incorrectly. He fails to anticipate all that is needed to complete the work.
• The 90% syndrome means the developer is certainly making progress, however is progressing at exactly the same rate as his understanding of the problem's scope.

Example

=======

Microsoft's development of MS Word began in September 1984 and was estimated to take 12 months. Nine months later, the team realized it will take another 13 months to complete, and an year later the team estimated 11 months. 

For three years, MS Word was estimated to be an year away. The product was ultimately shipped 5 years and 3 months later. 

NBUFD for Agile Change

• The concept of No Big Up Front Design is applicable to Agile change management (Design) as well. 

• One view is to have every piece of organizational change in place before the transformation can be initiated / continued. Another and more rational view is to work along the way in each initiative, identify the non value adds and remove them.

• The intent to deploy agile coaches is to ensure changes happen across teams that will meaningfully contribute to and transform the organization in their quest for enterprise agility. The notion along this journey that having a x number of coaches, each with their own view of what Agility means will lead to "Agile Fragmentation" may be ill-conceived because the intent is not to have a centralized control over the experience, rather it is to organically grow the abilities of team and in this the agile coaches support and help in clearing the obstacles via NVA removals.

ZBB Essentials - Mckinsey

• ZBB or Zero Based Budgeting is a a budgeting process where on a very granular level, you go through a company's spending and determine what resources various business units require. That means looking at individual cost categories across all business units. The process puts the burden of proof on the manager who's asking for resources. He or she must demonstrate almost on a continual basis the reasons the resources are in fact still required to achieve business objectives. 
• ZBB is fundamentally different from Cost Cutting initiatives. Standard cost cutting programs typically start with a directive to reduce the previous year's spending levels. As a result, executives naturally focus on the largest expense categories -- the tallest trees in the forest. ZBB instead asks everyone to rebuild their budgets from the bottom up, with no carryover from the preceding years. This process identifies many small pockets of waste that add up to big savings.
• ZBB shifts the burden of proof from those tasked with driving cost reductions (finance team or productivity program management office) to the business leaders and front-line organizations which must contribute to both identifying unproductive costs and eliminating them in practice.
•  The whole intent of ZBB is to ensure that right money is behind the right projects.

Skunk Works - Lockheed Martin built (the fighter jet) in 143 Days (courtesy Lockheed Martin and red-gate.com)

Quote this example for Agile / Rapid Delivery

• In 1943, the U.S. Army’s Air Tactical Service Command (ATSC) met with Lockheed Aircraft Corporation to express its dire need for a jet fighter to counter a rapidly growing German jet threat. 
• Engineer Kelly Johnson and his team designed and built the XP-80 Shooting Star in only 143 days, seven less than was required.
• Kelly's 14 Rules & Practices (some of the 14 rules and practices reflect upon the close analogy to agile practices).

• The Skunk Works® manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher. -->> AUTONOMY

• The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems). -->> SMALL TEAMS

• A very simple drawing and drawing release system with great flexibility for making changes must be provided. --> NO BIG UPFRONT DESIGN / SMALL 

• There must be a minimum number of reports required, but important work must be recorded thoroughly -->> NO OR MINIMAL DOCUMENTATION

• There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. // Funding a program must be timely so that the contractor doesn't have to keep running to the bak to support government projects -->> INCREMENTAL FUNDING (and Review).

• The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones -->> COLLABORATION OVER CONTRACT NEGOTIATION

• There must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum. -- >> TRUST / OPENNESS / RESPECT, etc.

Bottomline: This only proves that the Agile principles are indeed tried and tested and not just philosophies of good craftsmanship.