In February 2001, 17 software developers met in Utah to discuss "lightweight development methods." By the end of the meeting, the group had published the "Manifesto for Agile Software Development."
Among other things, the manifesto declared that by "uncovering better ways of developing software by doing it and helping others do it," they had come to value individuals and interactions over processes and tools; working software over comprehensive documentation; and customer collaboration over contract negotiation.
For years, Agile was all the rage. But lately, a number of industry experts have declared the methodology officially dead.
Dave Thomas, one of the original developers who proposed Agile Software Development, recently published a blog on the topic in which he declared that the word "Agile" has been subverted to the point where it is effectively meaningless.
Once the manifesto became popular, Thomas said, the word "Agile" became a magnet for anyone with points to espouse, hours to bill or products to sell.
"It became a marketing term, co-opted to improve sales in the same way that words such as eco and natural are," wrote Thomas. "A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand."
Agile's death is due to the fact that it simply did not match enterprise needs well, wrote Matthew Kern in a recent article on LinkedIn about the death of Agile.
For example, it did not support strategic goals and attempts to scale Agile to reach strategy fell short, Kern wrote. There was also no mechanism for alignment.
In other words, the Agile methodologies that typically surround software were never adopted into mainstream enterprise environments, according to Kern.
In addition, Agile had "an inherent problem with fiduciary responsibility," said Kern. "You do not know what the software will do before you build it, and you cannot estimate its effect on operations. Therefore you cannot calculate ROI before you start. You are writing a blank check for an uncertain return."
Too soon to call it
Not everyone agrees that Agile is dead quite yet.
"Agile development may not be completely dead in the enterprise, but it is certainly on life support," said Formation Data Systems CEO Mark Lewis.
"The problem comes down to the rapid release cycles associated with it—shorter development and test cycles don't fit core infrastructure solutions," Lewis said. "Infrastructure solutions, especially IT and data center infrastructure technology, once deployed, typically need to remain in a steady state in order to deliver a consistent and reliable experience."
Saar Shwartz, vice president of strategy at BMC, said he doesn't believe that Agile is dead either, only that it's evolving.
"Today's organizations are challenged to become more digital, use the cloud more, be more secure," said Shwartz. "Agile applications enable users to consume digital services and are the foundations for growth and new frontiers of value."
"Speed to reaction is now more critical than ever—requiring organizations to prepare for incidents before they happen through automation," Shwartz said.
Dipankar Ganguly, chief engineer at Ness, said he believes the role of Agile has become even more important in the "digitally connected" world where rapid development, stronger team collaboration and constantly changing requirements make software development a more exciting and challenging game.
"Agile is no longer a 'good to have' but it's now a 'must have' for large enterprises that need to transform traditional development practices in a world where on the fly releases, test and learn paradigms, rapid prototyping, continuous delivery and DevOps are becoming mainstream development practices," said Ganguly. "Organizations of the future will be more self-organized with teams focused on shared purpose and responsibility with less division and hierarchy. Agile will make this a reality."
Agile’s potential successor
If Agile is indeed dead, or at least dying, then what comes next?
Kern believes DevOps is the "heir apparent."
"If you buy software development services at a medium or large scale then someone will be in your office selling you DevOps this year," Kern said.
But Agile methods—whether they are called that or something else—will remain a key piece of the puzzle.
"As infrastructure becomes code, we'll see more Agile and DevOps processes be adopted into traditional waterfall development cycles, but it is going to be a long, bumpy transition," said Lewis. "For infrastructure solutions, consumers of IT technology simply cannot take on updates more than once or twice a year because of the disruption that is typically associated with these updates."
Lewis also said that while Agile development methodologies don't work for infrastructure (yet), these processes do still have a place in IT, such as supporting mobile application deployments.
"This is why Gartner has been preaching a concept called Bi-Modal IT, stating that enterprises must embrace both modern Agile processes and traditional development methodologies," said Lewis.
"Mobile applications become good candidates for Agile methodologies because these smaller, lightweight apps typically support newer mobile and social processes that are extremely competitive and rapidly changing," Lewis said. "Mobile app developers can release software updates more frequently, receive feedback almost instantly and the users benefit because they get frequent updates in order to meet changing expectations and demands."
This Agile methodology also benefits the development teams because they can push new releases to customers more frequently, taking advantage of the short development cycles that allow organizations to be more competitive.
"In order for organizations to be competitive in the modern world, they will need to embrace the agility of rapid release processes with the stability of traditional approaches," added Lewis. "Organizations will need to make sure when they do this, that they apply the proper technique to the appropriate piece of the business, making sure to not force Agile into the wrong application types."
