Agile isn’t the problem. Understanding it is.
Agile has definitely replaced the Waterfall methodology. Good Agile is about constantly delivering actual tangible and incremental business value in every Sprint. Which is why the biggest strength of Agile is the ability to get feedback earlier, change plans (if required) earlier, continuously and immediately reduce the surface risk to deadline ratio, and hence incrementally and iteratively either fix the problem or else at the very least evaluate the priority and deliverable. With Waterfall, one tends to have grandiose plans and documentation on paper. However, most projects slip the target date and fail to deliver on commitment. And the realization inevitably occurs very late in the process, with the inability of doing anything about it.
Agile is a vastly superior development methodology. It is not a buzzword.
However, getting it right is difficult. Like Agile itself, there will be an iterative process before one gets productive and begins to hit a cadence. Agile, by itself is not a silver bullet. There are a lot of ways one can set oneself up for failure. One almost certainly needs to be trained or have experienced Agile resources to guide you. But most of all, it needs Management buy-in in actual terms – training, support, clearing roadblocks, getting stakeholders involved in PI (Program Increment) planning, and syncing different modules in the same Sprint/PI cycle. Some of it is challenging, both in cost and communication, because of the nature of software development in myriad geographies. But most of all, Agile fails when Management keeps tinkering around, shuffles people around between teams, and lacks focus.
A lot of Agile has been inspired by the Auto Industry and Japanese processes. As a consumer, one can learn to drive any car because the controls are mostly similar irrespective of the make, model or year. That’s because the Auto industry is now mature and change is mostly evolutionary. The software industry is still nascent and turbulent, so standardization hasn’t yet been established. In fact, the irony is that the software industry wrote excellent architecture software, but we still don’t have a common Architectural notation. An electrical engineer, for instance will immediately pick out resistors or capacitors from a diagram based on size, color and markings. There is nothing quite like that for Software Architecture. In terms of development, one needs specialized knowledge to design and build cars and one needs the same kind of skills to build software. But the process, because of the maturity is much more stable in the former than in the latter. Agile is the right approach to get us there at some point in the future!
To sum up, the Agile methodology is terrific! If someone can’t articulate it, then they haven’t had the right training or have worked in failed Agile projects. Self-organizing teams truly work. It is the Managers that are redundant from a team-contribution perspective, unlike the Product Owner, Scrum Master and Developers (including QA).
In a follow-up blog, we will expand on how to maintain the Agile discipline and balance.