A few years ago everyone wanted to know how to convince their executives to go agile. Today's executives are asking their teams how they'll get them there. While we have made significant progress changing the hearts and minds of senior leadership, executives have a fiduciary responsibility to the performance of their organizations. They demand a greater level of assurance that what you plan to do is actually going to work. Executives are sick and tired of being told to trust the team and that everything will be okay. Better than anyone, executives see the dysfunction in their organizations. They want line of sight to how agile is going to help them make things better.

This talk is going to explore a safe, pragmatic, and repeatable formula for leading change in large organizations. The holy grail for an executive, is to tie dollars spent and activities performed, to internal improvement metrics and ultimately improved business performance. We'll start by discussing the elements of an agile transformation business case and how to identify a meaningful value proposition for change. Next we'll consider how to assess the organization and build an agile transformation strategy and roadmap that encourages an iterative and incremental approach to change. Finally we'll explore the metrics and controls that help you know if you're on the right track.

Throughout the presentation, we'll explore the change management and engagement techniques necessary to make sure you are building meaningful organizational support as you engage the enterprise. We'll discuss how to build and execute a change management strategy to keep everyone safe and informed throughout the transformation. We'll show how to sustain and improve the changes over time, ultimately creating an organizational ecosystem where business agility is part of the fundamental DNA of the company. The goal of this talk is to take the magic out of agile transformation and show you how to systematically and planfully introduce agile into your organization.

• Content rating (0-no new ideas, 5 - a new ideas/approach, 9-new ideas): 3
• Style rating (0-average presentation, 5 - my level, 9-I learned something about presenting): 5

Interesting. But idea is to apply agile to system problem of transformation, so I think this what we already know.

Also uses more my style - grey background and words.

• “Even if we believe in self org, many executives will not by into an unplanned emergent style of transformation”

http://www.leadingagile.com/2016/07/executives-step-step-guide-leading-large-scale-agile-transformation-agile2016

How to pragmatically lead a transformation Responsible from a business perspective

What is the work of the transformation How do we organize plan and track that work

Executives care But don't know how They need line of sight to how the transformation unfold Have to continuously justify the economics to key stakeholders (don't expose the execs to unjustifiable spend)

“Even if we believe in self org, many executives will not by into an unplanned emergent style of transformation”

Need to approach from a systems perspective Not just culture, not just practices

If culture - belief is that it will drive emergent system If practice - belief is that practice will make the change

If systems Focus on forming teams, governing flow Focus on alignment to start

So start systems.

What do I mean by systems?

Not negotiable:

Teams Backlog Working tested software

Backlog - invest, CCC, small enough to do Team - everything and everyone necessary to deliver (if not then not accountable) Working Tested Software - acceptance criteria, no known defects, no technical debt

All failure modes derive for one of these not being met

Agile is a business architecture problem Until this addressed, nothing else will really help Around

Backlog - governance (way to make economic trade offs) Team - Structure (collaboration) Working tested software - metrics and tools

It's a alignment issues

Team - problems include Matrices To much WIP Large diverse technology Technical debt etc

Not empowered to solve them Plus need to deliver the product while we are fixing the problems

Theory Agile transportation Formal teams, building backlogs, producing software

At scale Governance, structure, metrics

Organizational refactoring Service oriented Low dependency

Solid agile practices will help, culture emerges overtime

Organizing the work of the transformation

At scale see networks of teams Organized around core services Also more feature oriented teams that consume core services

Mature services Independant of features

Start orchestrate dependencies to start with But want to break then the dependencies over time

Safe assume encapsulation for value stream Scrum assume encapsulation of teams If dependencies then need to orchestrate these

Have to orchestrate before we have encapsulate

It's not agile but it is necessary

Teams at all levels

Scrum is a governance model for a team

Program construct above that. Now more Kanban Continuously planning

Punctuate with a release planning event - safe

Governance Coordinate flow the value

“Dependencies are what is breaking agile”

Metrics Different levels Kanban - cycle time etc

Kanban to explicitly govern

Incremental transformation (expeditions)

Vertical slice of all of the teams, program, portfolio - performing at some level of maturity Reasonably encapsulated Agile pilot - increment 1 - increment of value of in a transformation Clear balanced dependency aware

Training is a task, not value

Some degree of better performance

Progress incremental

Iterative transformation (base camps)

Progress iterative

Organization gets better fast. Bring to market faster Break dependency means can deprecate structure that supports this

This is iterative improvement over time

Different pieces of organization at different levels of maturity

Get everyone up to basecamp 1 And then iterate to improve

Somewhat plan driven

The executive guides

1 Build a leadership coalition

Why - have to be fun participants How - Exec leadership team, transformation team What - hold org accountable, remove impediments, review progress, plan work, inspect and adapt

Have to engagement them to do it Can't do it to them

2 Define an end state vision

Why - some idea of where we are going, accept change

How - create working hypothesis for structure, governance, and metrics. Plan to progressively elaborate

What

3 Build a transformation roadmap

Expeditions and base camps Sequenced in time

What teams are going to form What training these need What coaching do we need When will it happen

Expect it to change

4 Maintain a rolling 90 day plan

Transformation team meets proactively to plan forward Week by week training teams Detailed resource plan Expected activities and outcomes

5 Conduct 30 day checkpoints

Inspect and adapt Did we learn anything new New hypothesis

Review metrics Review planning artifacts

6 Connect activity to outcome

create hypotheses / experiment demonstrate outcomes

7 Connect outcomes to business outcomes

Business metrics More efficient Cycle time Etc

Assessment outcomes Transformation metrics Business metrics

8 Incorporate feedback

Reassess end state vision based on evolving understanding Refine roadmap

Our understanding will evolve

This creates safety for the organization Huge line of sight

Linear on top of the hairball that is the system

9 Manage communication

Communicating the progress From leadership From success

Executive round tables Signage etc

Hyper communicate

10 Create Safety for Everyone Involved

Clarity Accountability Measure progress

Team assignments Staffing plan Job descriptions Job aids CoP

Summary

It's a systems problem, especially at scale.

Performing organizations are the unit of value Training etc is activities Value is better organization

Change can be planned, measured and controlled

Execs think it can go faster because they think it is a training issues. It's not Reshaping the conversation What they should be asking