Continuous Change

Last week’s #changechat question raised an interesting comment from Jen Frahm:

“When I read [the last post]  I think about the concept of “flux” – continuous change, and movement. I think where we fall down as a profession is getting stuck thinking about change as current state and future state
(being also the end state). If we could some-how rethink change as continuous, “flow” if you will, we rethink all of the concepts associated with and create more realistic expectations of what to achieve…at least that’s what I am thinking right now!! “

Agile software development has brought with it a practice called continuous delivery. That is a practice teams use to delivery valuable software continually and it allows teams to respond to change faster.

Why not take a similar approach to change?

Why spend months creating a beautiful plan that we know isn’t likely to work. We know we’ll run into resistance, we know the plan will change and we know the increase in globalization has forced organizations into changing more frequently.

In order to enable continuous change, a few things need to, um, change:

  1. Stop treating change initiatives like projects with a start date, end date and budget
    This is not without it’s problems. The question I hear the most in response to this point is: Who will pay for the change? OpEx? CapEx? Shouldn’t the department who is affected by the change pay for it? My opinion, it’s an operational expense.  The barrier to stopping this dysfunction sits with your CFO.
  2. Start focusing more on building change capability with middle management
    If the consultants you hired are the face of your change, your change is doomed! Trickling down change from the top or building it from the bottom up won’t work. Like it or not, middle management controls the levers that propels the change or kills it. Have your consultants lead from behind the scenes and get them focused on developing change and facilitation capability with middle managers.
  3. Look to Agile practices, such as Kanban as a way to execute changes
    This is the easy part! Make changes visible and limit the number of changes in progress at a time. The point isn’t to keep the change team busy, the point is to pick the most important change to work on, decide how to validate it, finish it and then move onto the next change. Here’s a sneek peek from my upcoming book at an example of a visualization that will help you manage continuous change:

continuous change

Here’s this week’s #ChangeChat question:

What needs to be done to enable continuous change?

[button link=”” type=”big” color=”green” newwindow=”yes”] Get a FREE Sample Chapter[/button]

(Visited 7 times, 1 visits today)
Share This