Case Against Agile: It’s Too Damn Hard
This article has been beaten to death by many, including this blog. Still, I wanted to talk about several reasons why some organizations have difficulties adopting Agile. And if what I have to say is controversial, oh well, so be it.
It is not uncommon for large companies to have more managers than developers. (What on Earth could they be managing?..) With Agile, or Scrum in particular, there is basically just the Scrum Master and the Scrum team itself, and up from there we have the Product Owner and the business. Entire layers of management become, ehr, less necessary. So while top management often can get excited and inspired by Agile because of the promise of improved efficiency, the middle management has much less to get excited about. In fact, they get nervous. So it’s no wonder that sometimes it is quite hard for a large company to move classical projects to Agile: there is this whole layer of stakeholders who may sabotage this process directly or indirectly, trying to keep control and protect their jobs.
Next point: Agile places a strong and self-organizing development team in the center. In the industry, it is well known that competent software developers, who often have fiercely independent (some might even say difficult) personalities, are quite difficult to keep under control even under “normal” circumstances. With the introduction of Agile, controlling those developers becomes even more challenging for the middle managers. It is far easier to keep things (really, people) in check under waterfall and the more traditional bureaucratic management structure.
I’m actually going to agree – with a caveat – with one of the points made in the “case against Agile”, namely that “Agile is only for the stars”. I wouldn’t quite put it that way, but there is a kernel of truth there. Working on an Agile team is often more stressful and more intense for developers, mainly because of heightened transparency and accountability: your contribution is clearly visible, and you must deliver tangible results each and every day. Which is why solid professionals actually prefer Agile: this way of work brings much higher satisfaction. However, a less secure developer may prefer the safety of a “normal” company where your job is safe as long as you show up and follow the formal company rules (as opposed to producing valuable results).
Notice that I’m not saying that any of these “objections” are good reasons not to do Agile. I’m just pointing out that human nature being what it is, some people find it too hard to go this route. To quote Lt. Col. Frank Slade played by Al Pacino in Scent of a Woman: “I always knew what the right path was. Without exception, I knew, but I never took it. You know why? It was too damn hard.”
Here at First Line, we are staunch advocates of Agile. However, at the end of the day, we are a service provider, and no matter how much we love Agile, if the customer says that they want waterfall, then waterfall it will be. At least for a while. Hopefully, once we have demonstrated that we can deliver quality code with good productivity, we can begin to suggest practices that will gradually move the relationship onto a more Agile footing.