When looking at the catalog of agile change patterns together, they form a pattern language that helps you focus, where you're learning should be depending on the progress your organization is made in adopting agile.
When starting to adopt agile or lean in your organization it makes the most sense to focus change on enabling Quick Wins. Rather than trying to validate whether you have the exact right set of target options for your exact context, focus on helping a small portion of the organization adopt a set of lightweight agile methods like Kanban or Scrum. This will identify major obstacles to change, some examples of these obstacles include an uninvolved executive, inattentive business owners, overly specialized organizational structure, or extremely poor morale. With quick wins you are -trying to determine if the organization is ready to adopt "any" amount of agile. And if not, what are the major obstacles, and countermeasures that can be put in place.
Once learning increases through a successive of quick wins set of quick Win, you can start experimenting with introducing a more fulsome representation of your candidate target state. Introducing a Kernel Pilot involves introducing the set of organizational target state options representing the vision for the overall enterprise. This can include a number of agile methods, changes to organizational structure, and modifications to roles and responsibilities. While this change is bigger than the Quick Win, the focus here is still on learning. Focus has now changed from learning about resistance to learning about whether assumptions behind the solution is correct.
As one or more kernel pilot's are introduced into the organization, the change initiative switches from piloting to adopting. A change based on the Kernel Adoption pattern is focused on introducing the future state using successive, rolling waves. As we uncover more and more understanding of how the organization accepts change, and what approach is ideal for the organizational context, we can gradually switch learning from "what" is the target state, to "how" we can best facilitate adoption. This can be a subtle, and permeable distinction. The main point here is that it is okay to spend more time working with people and really understanding what's getting in the way of facilitating learning when starting down the road. At some point, we want to understand how to scale out our efforts to support a sustainable change plan.
Changes based on the Self-Serve pattern is another step in this direction. At this point, we should have enough understanding about what works in the organization, where we can standardize, where we can't. We should also understand what parts of our target state are relatively stable, and which parts continue to change rapidly. This allows us to start figuring out how to publish our knowledge in a way that the organization can consume on their own with minimal support from agile coaches are agile consultants. Many change management consultants recommend starting with defining some type of delivery model and method publishing it out, and getting adoption going. It's really only at this point, but I found it useful to get thoughts around "how" the organization is meant to work. At this point in the transformation, a lot of learning has taken place based on on the ground adoption, we now want to switch our learning to understand how we can push change out to the edges of the organization, supporting it in a way that creates a self learning environment.
Changes based on the Capability Modernization pattern are really about cementing the change and ingraining it into the supporting structures of the organization. New specializations and competencies are modeled as appropriate using a combination of career ladders, capability models, job specifications, and incentives. Functions like Human Resources, Finance, and even Legal play a role, making sure that employees are on board, educated, and compensated according to the new "normal (if there is such a thing as normal for an agile organization).