Enterprise teams often call themselves ‘agile’, but fall into chaos and confusion. Where’s the problem? Contrary to what the experts tell you…
If you are a software developer you’ve probably heard these words, “We use the Agile Methodology.” Then as the project goes along you start to wonder, “Hey, there’s nothing agile about this at all.”
In fact, you start to feel as though everything is slow and bureaucratic. You’re stuck in meetings all day with 12 people from all over trying to decide one feature. You may even witness flared tempers and politicking that results in parties getting involved in a pissing contest and intentionally sitting on work.
PS: This article was meant to be personal observations; and I’m not a techie. Interestingly, many who are and have spent decades in big projects have echoed my sentiments. Some of these reader responses are at the end.
So what the hell is ‘Agile’ Methodology?
AngelList has an excellent primer on Agile Methodology. What makes this article different is: it focuses on the human aspect, not the framework and tools.
To understand what this means, we fall back on the values proposed by the source; the great Manifesto for Agile Software Development.
👥 Individuals and interactions over processes and tools
💻 Working software over comprehensive documentation
🤝 Customer collaboration over contract negotiation
🔁 Responding to change over following a plan
Quite simply, Agile Methodology is about people, interaction and flexibility.
71% of organizations use Agile today for project management, as opposed to the traditional Waterfall approach.
What happened to the Waterfall?
The Waterfall methodology is a logical flow of cascading events in the process of software development.
So if the traditional Waterfall method is so logical, how did Agile gain dominance?
Because the world of technology and the businesses using it have become super fast paced and competitive due to computing power, knowledge and market access becoming easily available.
What works today may not work tomorrow. What sells today may not sell tomorrow.
Most of all, speed to market and efficiency has become more important than tried and tested in today’s world of instant gratification and global competition. (But please don’t confuse this with putting out lousy and ‘buggy’ products which does irreparable reputation damage...)
The agile trap that project teams inevitably fall into
Unfortunately, in the real world, especially in enterprise software development, what started off as Agile often becomes Waterfall in the end — people waiting for tasks and detailed requirements to be given to them.
Sometimes it becomes a confused mix of both. A developer sent this to me, written by a blogger and echoed by her followers. She describes this confusion as ‘AgileFall’ — “a software development model where you are trying to be agile, but keep falling into waterfall habits”.
The author must have worked at IBM, going by her disclaimer…
But why does this happen, especially in a big organisation?
In theory this works…
You will often hear this from consultants or ‘gurus’.
“My job is to give you a framework to work with. With it you can arrive at the solutions. With it you will achieve great results.”
Wrong. Frameworks help to organize thoughts and processes. They don’t accomplish anything else.
Let me state this upfront. I’m not against intellectual strategizing or brainstorming. I’ve written books on it in my younger days.
However, I’ve come to realize good frameworks require strong leadership with brains and execution experience to follow through; especially within a big organization.
Implementation is more a matter of leadership and coordination than great team structures and project management tools. And that’s where the Agile Methodology, great in theory, starts to fail in practice.
Leadership and culture, not expensive software and tools
Massive enterprise software development teams fall apart using Agile because of the lack of human coordination and cooperation. They’ve relied too much on cold, unfeeling frameworks, tools and processes.
Implementing changes quickly and flexibly requires collaborative understanding and team harmony.
This is where I disagree with one of the principles proposed by the Agile Manifesto: The best architectures, requirements, and designs
emerge from self-organizing teams.
For self-organizing teams to work, the company culture and rewards system must advocate hiring self-motivated, proactive individuals. In the startup world where the founders are often developers themselves and early employees are given stock options, relying on initiative and self-motivation can work. But in big corporations with rules and politics, leaving it to the team to self-organize often results in a headless snake.
So the point of failure in enterprise software development is often the lack of a strong leader who can coordinate tightly, make decisions perceptively, and motivate with empathy. That stems from sound logic and judgment, as well as good communication and interpersonal skills.
This leader could be the product owner or project manager; someone who understands the end user and the project objectives well. Someone in charge of the ‘big picture’ and can see how the parts all fit together.
At the end of the day, Agile is all about reacting to changing needs and technical constraints.
To do that, people must talk to each other and not just follow task assignments and written documentation flying around coldly on tools like Jira.
Don’t waste too much time on writing detailed requirements and technical documentation. It’s hard to think of all the details and scenarios until you’re actually designing and coding and encountering practical issues. Document it thoroughly only after it is tested and proven to work.
Most of all, keep this in mind.
Machines and methods don’t build software. Humans do.
PS: Shortly after publishing, readers responded and shared from all over the world, to my surprise.