Is rigidly following agile methodologies getting in the way of agility?
I am often poised with the question of how we manage teams and projects at work. Which agile methodology do we use? How do we run our stand-up meetings? And how do I measure the performance of developers and designers? Clients who’ve decided to use “the agile methodology” are taken aback when they learn we don’t have daily stand-ups. How could we claim to be agile if we don’t follow the methodologies?
Agility is an attitude not a methodology. It’s the ability to adapt; you and your team are either agile or not. You can’t turn it on or off. If someone truly is agile, you can’t ask them to stop being agile. It’s in their nature.
Agile software development methods naturally evolved from observation and iteratively tweaking the application of traditional manufacturing habits to a completely different, evolving industry. Over time people have formalised the notion of agility, written books about it, delivered lecture and training and applied marketable terminology.
If you aren’t adaptive, learning about agile methods would be a revelation and if you are, then it would come as second nature. The problems arise when you deem these methodologies as gospel, or if you conclude that rigidly following these rules makes your process agile.
Not a lot happens in a day, especially if you’re building something substantial. Reporting on what you did yesterday and what you’re going to do today is insane. An obstruction might come your way that requires you to take a detour to work around something you never expected. If there’s an obstruction and you need to wait until your next meeting to overcome a hurdle, your communication channels are jammed. We simply avoid meetings altogether. I recommend listening to Jason Fried’s TED talk and learn to stop bothering people, letting them just do their work. Be approachable and leave capable people alone.
I know our engineers and designers are hard at work because software is being produced and released into the wild, and customers are using and appreciating what we’ve built. There’s version control and source code collaboration platforms to keep track of what needs to be done.
At the heart of agility is the assumption that the person in charge understands the task at hand and, second, trusts the delegated people to do their job. True agility means being able to make and manage a decision to work around the problems that present themselves through the process to achieve the ultimate goal.
Project managers who’ve never been in the position of the people who are going to do the work are an obstruction. They don’t understand how it works. A project manager’s understanding of agility is smaller chunks of a linear (or waterfall) approach. It’s top down, but small enough to let the damage go unnoticed.
Agility is leaving the dogma behind and exercising the freedom to invent your way out of the problem with the resources available.