Is Agile Dying?

What a craze: Agile.  Are there signs it is dying?
I remember the tail end of the Structured Analysis/Design craze.  Its hay-day was before my time, but I got to watch it die.
Structured Analysis was the way of the future.  The be-all, end-all of how to reign in software projects – basically by specing the hell out of everything using functional decomposition.  So much time was spent on spec, that the only things actually achieved, were achieved in spite of the system.
Be that as it may, the decline came as everyone said they were Structured-this and Structured-that.  Gee, that sounds a lot like Agile-this and Agile-that.  Using a ubiquitous buzz word is a great way to promote your pet process or cover up your lack of clear thinking.  “I know my plan appears to be waterfall, but it’s really agile in its own way.”  What?
Hypothesis: When a popular term starts getting applied to anything, it’s about to die.  I hate to see that happen to Agile, but the signs are there.
Perhaps we can keep the concept alive by returning to its roots.
Let’s distill Agile into its purest form.  We can do that with 2 promises:
Manager: “I promise to leave you engineers alone for 2 weeks – no priority changes, no spec changes, no context switching.”
Engineer: “I promise to deliver the following functionality in 2 weeks.”
That’s it. Every successful ‘agile’ element hangs on those 2 promises.  Story writing, Chicken and Pigs, scrum meetings, etc.  To understand the environment those promises thrive in, read the original Agile manifesto.  It describes a culture and value system – not a process.  It’s a great worldview that includes open communication, respect, trust, and a “let’s go” attitude.
Agile does not apply to every system in an organization.  Agile is not fit for requirements management.  Agile is a crappy way to manage the design process.  It is not how you organize your sales team.  It is not a management style.  It is not waterfall with 2 week milestones.
If you are ‘Agile-ing’ your company, maybe you should take look at the manifesto once again.  Perhaps you are missing point and contributing to buzzword abuse.

About Author


Steve works with successful software startups and tech companies throughout Silicon Valley. Most recently he has been developing content migration tools for large websites. He has a deep passion for all things software engineering, from design concepts, to team management, to final delivery.

1 Comment

  1. However, in practice the process alone is not able to provide change-resilience . A software development team will only be able to address changing system requirements if the system was designed to be flexible and adaptable . If the original design did not take in consideration the issues of maintainability and extensibility, the developers will not succeed in incorporating changes, not matter how Agile is the development process.