I’ve read a few articles of late that have declared the end of Agile development. They are interesting reads for the most part, and they make some interesting arguments, but I see none of them as compelling. I do, however hope that this is the beginning of applying “Right Tool for the Job” to how projects are handled in development/DevOps.
Agile officially kicked off in 2001, but comes from 90s concepts such as Extreme Programming. That makes it old. But, age isn’t in and of itself a problem. Adaptability beats age every time, and there have been movements that update parts of Agile to keep up with the times/changing environment. My issue is that “We’re an Agile shop” becomes a mantra that implies “Everything is an Agile project” which is absolutely untrue. You can do any development you can consider in Agile. You can also ride your bike from Main to California. Doesn’t make either one the best option.
As with any methodology, we’ve also had a couple decades for a burgeoning oversight function that interferes with the goals of Agile. The point was to rapidly iterate to get features out the door, low-hanging fruit first. But the weakness of any high-speed development effort is quality, and as fingers have gotten burned from too much change causing problems, oversight has been built in to temper the volume of change. That oversight inevitably becomes rigid and slowing.
As others have repeatedly pointed out, Agile works best for small teams with shared focus and geographic proximity. That hasn’t changed much. The opposite problem—a project with large, geographically dispersed teams having divergent foci—are a terrible use case for Agile, no matter the flavor of Agile you are implementing. Incremental development is also not the best answer to all problems.
Indeed, contrary to popular belief, large initial implementations do best if using traditional development methodologies with an Agile approach to feature inclusion. That is because what undermines large projects is growing the size of the project by throwing every requirement and the kitchen sink into Minimum Viable Product, or whatever you call the actual must-have features for your application. Using Agile mindset as a filtering tool, and development methodologies that get a base level of functionality up and running (rather than incrementally implemented) allows more time for testing complete features and limits the number of features dumped into the must-have bucket.
I’m happy to see this conversation starting to happen more seriously. Agile is a powerful tool that is the silver bullet for some development efforts. But it is only a tool, not a lifestyle. Using the Agile tool does not preclude choosing other methodologies (even waterfall, though it is currently passe’ to suggest its use) when the project is best suited to it. Most large organizations do some amount of this already, but it should be standard practice to choose methodology based upon project and suitability to task. Hopefully this is the first step toward doing so.
