Showing posts with label Agile Change. Show all posts
Showing posts with label Agile Change. Show all posts

Thursday, January 31, 2019

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.

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. 

Tuesday, December 25, 2018

Why Organizational Change is Difficult...


Adapted from Phillipe Silberzahneng's write up.

"When an organization’s capabilities reside in its resources (initial stage of startup), change is easy: the founders decide to change, and the organization can pivot. It is the strength of startups to change very easily when the founders are aware of the need to change their model. But when, at a later stage, an organization’s abilities reside in its processes, and even more so when they reside in its values, change becomes extremely difficult."

Changing values is difficult -- for e.g. most of us don't exercise regularly or eat balanced diet despite knowing its benefits. It's a deep change in lifestyle that affect the present commitments. It's the same for companies affected by disruption.

Changing values of an organization is titanic because it entails undermining the legacy long before it allows the birth of new one.

A solution to this is create an Autonomous Entity that takes care of this disruption.

If we already have automation, what's the need for Agents?

“Automation” and “agent” sound similar — but they solve very different classes of problems. Automation = Fixed Instruction → Fixed Outcome ...