Have you noticed that the word “Agile” sometimes scares people? It could be that their perception is that “going Agile” will eliminate their role or mess with their routine. Maybe they think they’ll be forced to develop faster or test less, or that they’ll have to learn all those crazy new words like “retrospective”, “sprint”, and “Scrum Master”. There may be valid reasons people cringe when agility is introduced: your work outcomes will be made more visible, your mindset may need to shift away from a “me” attitude to a “team” attitude, and (gulp…) you will likely have to talk to people more – you know, that collaboration thing.
So, how can you help introduce agility without freaking everyone out? How can you move toward iterative development when there is perceived reluctance, or outright animosity regarding Agile? Years ago, as a software engineer and later as a project manager, I naturally embraced many of the thought processes that the Agile Principles promote today. I liked simplicity, I developed software in iterations so I could get frequent feedback and make quick course corrections, I preferred communicating face-to-face, and I put my customers and developers in the same room often so they could collaborate and ensure we were on the right path. I didn’t call it “Agile”, I just thought those were good things to do.
Unfortunately, many companies still see agility as an “I.T. thing”, not something for the whole enterprise. When I coach organizations today on transforming to a more Agile environment, I almost always work with teams who interact with non-Agile teams or departments on a regular basis. In order to soften the negative perception those non-Agile groups have toward change, we often focus more on implementing mindset changes – the soft skills that are really the core of Agile – and not as much, initially, on the “practices” or “methods” of Scrum or other Agile frameworks.
We start collaborating more frequently with our teammates and business counterparts. We communicate face-to-face as much as possible. We develop, test, and deliver smaller chunks of working software more frequently. We work on making our work and outcomes more transparent to stakeholders. And, we pause every couple weeks to reflect on what’s working well and what we need to improve on (it’s OK to have retrospectives without calling them retrospectives). If people are averse to “doing that Agile thing”, then introduce it without calling it “Agile” or using Agile terminology.
The principles of Agile are what make it successful – not just a particular set of practices, and certainly not the words we use. We’ve all read somewhere that we need to “Be Agile, not just Do Agile”. “Being” is about mindset and attitude, “Doing” is about practices and terminology. The Agile principles are proven, and they work no matter what framework or methodology is in place. Once your organization sees the positive outcomes of these principles in action, it will be easier to break the bad news to them – they’re becoming Agile – yikes!
To learn more on Mindtree's Agile operations, click here