Emergent Improvements over managed changes


Changes towards better is what most of organization are seeking for.

We often hear that Scrum Masters and Agile Coaches are referred as “change agents”. It is important to understand it is much more challenging and required for those “shoes” to master change management than e.g. change managed by supervisor.

I like word “Improvement” more, however…. Maybe this post helps to explain why…

There is difference in the way change is accepted by teams in case it is:

  • Originated / introduced by management – these changes are often seen as “enforced” rather than owned. When communicated fully, transparently and explained these changes are followed / implemented usually
  • Emerged from self-organizing teams – these are changes that are owned by teams. Therefore, level of involvement, contribution and ownership to the success is much higher.

So, what are the magic ingredients to make improvement happen? And what is required for it to have positive effect?

Set the Goal

In terms of Agile this means understanding the lack of fit of something. This is essential. Without exploring lack and creating shared understanding and contribution towards Goal nothing will happen.

After exploring the lack convert problem into goal. Keep in mind this is pivotal point as goals usually seen as something positive (unlike problems).

Clarity about goal is essential. When this is unclear people best case not “buying in” and worst case confronting change or acting ”passive-aggressive”.
Key question here is: and what do we want to achieve instead?


This is very delicate one. Language and transparency is very important. Humans do not like changes. Do not communicate problems or that “we are changing”, communicate goals or that “we are improving X” instead. You will be facing much more resistance otherwise.

Reason is problem sends out “we are bad” and creates frustration, while goal sends out “we are improving gradually” and creates motivation.

Example: there are people that do not like to “play according to the rules”. Proven by practice that you will face huge resistance from those “Mavericks” if you will name your change, let’s say “switching to Scrum” because this could be interpreted as “what you had here is bad”, vs. “Improve the way we work” with post-factum acknowledging that aha, btw it looks pretty much like Scrum.

At the same time communication is important as when changes are implemented subtly you will face much more resistance, resulting from lack of transparency and comfort leading to many false assumptions.


No changes are done forever. We do series of experiments to see what works, what works better… We inspect and Adapt and practice constantly. It is important to cultivate mindset of constant experimenting and improvement. Then change will not be something negative, rather permanent positive state (Kaizen).

Constant experimentation also requires measurement and validation. This is another important aspect that is sometimes neglected.


Get opinion of people that will stand with you when improvement is being implemented. Present it in terms of their benefit. Get them on your side.

At the same time, you will unavoidably face some resistance. It usually comes from the fact that some team members either afraid of change (they think to “loose” something or end up with less comfort, etc.…). You need to manage this resistance.

According to studies resistance is consequence of brain that protects us against dangers and tries to maximize our satisfaction (Minimize Danger and Maximize Reward). One should therefore take this into consideration to manage these basic social needs (known as SCARF model


This is fundamental. Not just rely on ally, … Involve. People embrace changes much easier when they contributed towards ideas, participated, asked for opinions and feel part of. Easiest way to convert potential opponents into allies is to involve them into getting it done.

But most important is that involvement creates empowerment that not only reduces resistance but raises awareness, creates feeling of a team, improves collaboration and as result amplifies possible success of the change.

Act small

Change requires energy, think of it as of a ladder that needs to be “climbed”. No one likes changing for changing. “Prize” must be bigger than “price” to pay for “climbing up”. Therefore, it is more likely you will succeed with smaller and singular changes at a time.

Start with small/local experiments. This way you will be able to prove your theories better and get more motivation for scaling up.

And scope changes the way teams are capable to achieve. In other words, meet people and teams where they are, not where you want them to be. Take into account things such as: business constraints, people capabilities, current situation, motivation of people, etc..

Think of short-term wins, those are indispensable to “feed” motivation for changing further…

I have summarized all above in Agile-like Lean Improvement Manifesto:

Lean Improvement Manifesto:

  • Emergent Improvement over change as a goal
  • Small Creative Experiments over “big bang” theories
  • Getting Involved Early over following change late
  • Empowered Co-Ideation over top-down pushed decision


  • David Rock, SCARF Model – Influencing Others with Dr David Rock, 8. Aug 2010.
    see: http://www.youtube.com/watch?v=isiSOeMVJQk (8 min:16 sec)
  • David Rock, Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long, HarperBusiness, Okt 2009.
  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: