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.