Resistence of change to Agile

I don’t believe that software practitioners resist change rather they want it. If there were resistance this would be due to inappropriate approach for implementing  Agile. In this post I describe few human related issues.

Let me state first that the only reason we want to change which is to solve real business problem. It’s insanity to try solving a chronic problem by repeating the same practices over and over again. Change is not comfortable to all except the coach and the executive who hired her. Change is translated in people mind as opportunity or threat. Things will not be the same and people’s very reason of existence would be questioned.

Existing project manager resists the implementation of ceremonies. Many of the PMs want ample space to move. This is the first motivation principle of being self-directed as advocated by Dan Pink. PMs expect from the coach high value-add in very short-engagement. Also, it is better to give the PM a clear document of what you expect and convince him about the value. Many PMs taking the path from command & control to Agile experience double-mindedness. Also, PMs like to be creative and put the process themselves. Tell her the expectations and leave her alone to decide the process. Also, sometimes the Agile ceremonies tend to be lightly implemented which might not yield the desired benefits. As coach you  should step-in to fill the gap.

Engineering manager can exhibit resistance because at the end its his team and you as coach intervening in vital aspects, for example introducing self-organization. We promote democracy but within a process framework. For example, during retrospective we ensure that every team member’s voice is heard and we agree on improvement actions. Those actions should be understandable by the Engineering manager.

Building trust with both the project manager and engineering manager can be critical. Also, as coach we should avoid multiple management roles. Being in process improvement for so long, I learned that repeating simple acts for so long will ultimately lead to benefits. For example, people might discount the importance of the daily stand-up, as you keep showing for the team and demonstrating respect and appreciation to the process; team members will follow. Key aspect is “team members should believe that you stand for the process with no personal attribution”. They should believe in you as a coach. They know that even if you have executive sponsorship you are not here to expose their weaknesses.

The product manager would need assistance in the technical practices. Balancing the relationship between the PM, product manager and engineering manager can result key benefits. For example,  Engineering manager blames product manager on poor requirements. Talking on this example, the biggest benefit in Agile is that it allows us to start development even when requirements are unclear. It increases transparency by helping the product owner to say, I am not sure yet, then the team steps up to prove the concept by setting appropriate sprint goal. Injecting this understanding helps the product manager to arrive at the real requirements, instead of having clear requirements but with low business-value. This collaboration increases the trust  among these three main players.

Finally, Senior managers resistance is decided by the feedback they receive from engineering manager, product manager and PM. If you follow top-down approach, we can probably arrive at compliance, which is an anti motivator and can be useful for non-innovative setups.

2 thoughts on “Resistence of change to Agile

  1. What if the change is not worth it and the only reason for the change is to line the pockets of the Scrum Money Machine that makes money when people adopt Scrum?

    Next year they’ll want you to change to something else….

    Software Maestro

    • I suggested in this post that the purpose of change is to solve business problem which otherwise we can’t using existing mode of operation. If we are bought in to become Agile, Scrum is only one way towards that.

      I understand that sometimes we over-commercialize the implementation and missing the real value and objectives. I have seen this first hand in CMM and CMMI implementations.

      I guess there will always be state-of-art thoughts. Please follow this link for patterns of adoption of ideas. From my view when we passed early majority, everyone else wanted to adopt the new technology or practices; at this point we might start adoption in a cargo cult mode while not achieving the desired outcomes.



Leave a Reply

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

You are commenting using your 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