Agile change management needs management change

Change management relies on change support across a host of needs. Organization change has no success without people change. Rare is a single department or job function successful when separated from other responsibility.

Success relies on people, process, and technology, yes, but practice needs review to surround and support the shape of things to come, both as inputs to add value and outputs of value add. People, process, and practice includes behaviors that need change.

This post presents an Agile change management method to identify network team and scale Agility transformation with step-by-step assessment and engagement methods along with building plans.

Today, many organizations want to scale Agile. The shallow view Agile in development or engineering only, independent from upstream product management and downstream implementation. No system theory and organization connection involved?

Bizarre. Obviously, an organization that does not value their human resource business partners, but, I have heard, in far away lands, that this happens.

Agile is a whole system transformation support: vertical, horizontal, pole to pole. Bigger enterprises that hope Agile and Lean concepts scale, but hope has little strategic role adoption for the genuine opportunity with:

• Product management,
• Marketing,
• Human resources,
• Information technology development and operations,
• Supply chain, and
• Accounts payable,
• Corporate risk,
• Learning and development,
• Project Management Office, and
• Partnerships

Big is Not Small

Small companies need cash. Startups need cash flow to live or die. To small companies Agile is survival.

In small companies minimum viable products are released to both validate learning through very real incremental revenue or investment proof points.

Clearly product management input as well as the development, engineering, and architecture throughout required maximum flow, delay was death.

Fine for that small company of 25 people.

Good for companies of 150 people.

Practical even for companies with hundreds of people.

Scale Agile to thousands or tens of thousands?

Yes, it is practical.

Very possible.

Agile change requires management change. Agile at enterprise scale requires executives to adopt, live, breath, and champion Agile values and principles.

1.	Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.	7.	Working software is the primary measure of progress.
2.	Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.	8.	Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
3.	Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	9.	Continuous attention to technical excellence and good design enhances agility.
4.	Business people and developers must work together daily throughout the project.	10.	Simplicity–the art of maximizing the amount of work not done–is essential.
5.	Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.	11.	The best architectures, requirements, and designs emerge from self-organizing teams.
6.	The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.	12.	At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
			Download free copy of the Manifesto.

The above guide the practice that support teams to implement and execute agility through the Manifesto for Agile Software Development.

There is very little a team, within an enterprise of 7,000, can change without management and executive support. The brick wall will always limit possibility.

Agile Change, Meet Management Change

The enterprise that grows to thousands of people often needs great risk management. One way to manage risk is delay. These companies felt a need for layers of governance and hierarchy of approvals to assure a plodding accountable trace of decision and authority.

The negative cultural result of of risk mitigation at Fortune 500 companies, multi-nationals, and global conglomerates is too often seen through the intractable middle manager. These are paid to (micro) manage people their silo and seemingly exist to damn customer workflow.

With the customer at the heart of all, Toyota led the way in the 1950s for change. Toyota showed relentless dedication to a culture of continuous improvement with all eyes on customer value.

Agile’s Grand Parents are Lean management. Lean management DNA is inescapable to Agile development.

The deck reviews:

• Training impact on change,
• Adult learning styles and why classroom training is the worst return on effort,
• Transformation models,
• Agile Fluency model,
• Scaled Agile Framework Implementation Roadmap,
• Introduction to Agile Change Management:
  • Develop
  • Enable
  • Adapt
  • Own

I will split this review over a couple posts. This post will guide the current-state training with a clear fit-for-purpose gap.

Agile transformation improves when policy, collaboration, and decision-making guidance has direct Agile experience. Within the deck, represents a transformation start that covers:

1. Develop
2. Enable
3. Adapt
4. Own

I propose the above to reinforce an adoption cycle through inspect and adapt, ruthless, kaizen values.

Agile is a mindset.

DevOps is a cultural shift.

Lean software development rely on practice principles.

Continuous integration and continuous delivery or deployment (CI/CD) is never divorced from values.

But they are. And sadly some wonder why things do no work.

1. Develop – what can we do
2. Enable – how do we support change
3. Adapt – what will we change
4. Own – new competence needs