The shift to Agile is a cultural shift. Culture is built from shared beliefs, knowledge, and values. So implementing Agile requires a reframing of the beliefs that have been engrained in a company from the beginning, most of them unconsciously accepted and reinforced. Any time that the values, knowledge, and beliefs of a group are put under scrutiny, the members of the group can get defensive - they’ll resist the changes being made.
In the ongoing process of implementing Agile, there are lots of different hurdles to jump. The specific hurdles depend on your practice’s needs, but resistance to change is a constant. The Agile MSP struggles with resistance every time we start making changes. It makes sense: if a behavior is being altered, that must mean that it’s being interpreted as bad. That’s not the case with all business practices: traditional management, for example, allows granular control of resources and can help shed light on how time is being spent within a company. Agile gets micromanagement out of the way - not because it’s bad, but because the self-forming team is a better way to iterate quickly and produce creative solutions to problems. That’s a valuable asset in the MSP space because of the rapidly evolving nature of the problems we help our clients cope with.
So how do you address resistance to change? We like the direct approach. When you sense that someone is having an issue with an Agile process, simply ask for their opinion. Misconceptions about Agile as a management fad or a fresh coat of paint on old business practices are symptoms of the real issue: a misunderstanding of what Agile is about and what can be accomplished with a change of company culture.
Misunderstandings like those are often reinforced by over-explanation of Agile concepts. Agile is more than the sum of its practical components. For example, if you say “this is how Kanban is done” you’ll get less benefit than from generally describing what a Kanban is and letting the team make a few initial tweaks to suit their working style (Kanban is meant to evolve into something unique over time with input from everyone on the team). The frustrating part of Agile for most traditionally minded workers and managers is the lack of a hard set of rules, so it’s important to make the shift a conversation - a real, face-to-face conversation - rather than a prescription.
We can say that because all the success we’ve seen in implementing Agile has come about when the change was championed by one of our team members working independently of management. When your employees are able to mull over an Agile concept and define it for themselves, they connect to it much more closely than when they’re handed an edict that tells them to change a process that already works for them. Teammates notice the change in their work. Their conceptualization spreads and evolves, and soon everyone has an interpretation that works for them.
Knowing how to pitch Agile concepts (not too abstract, not too concrete), when to clarify a concept for a team member, and when to step back and let them wrestle with the concept until they understand and take ownership of it are key to bringing lasting, ground-up Agile implementation to your own practice.
Contact us for more information or consulting services
120 E Taylor Street
Griffin, GA 30223