I don't believe that agile is really going away, but it is definitely not really the hot thing anymore, at this point, many years since it first became a trend.
And probably a growing number of people are going to be put off by their experiences with "agile", if they are anything like mine have been.
Managers love the idea of releasing more often and understand that. And that part can be an improvement.
However, quite a few people seem to think that means you can fit that many more features in, which is false.
This is the big challenge for agile in my opinion: automated testing or even testing at all, is hard for many development teams for a number of reasons. Not to say that the actual skills or knowledge are particularly difficult to acquire. But practically speaking, putting into place a good testing and release system are challenging for many teams.
And doing "agile" (read: code and release more features faster) without solid automated testing or at least one real QA analyst who is busy, will guarantee that you have a ton of regressions and broken deployments. Now, since you are releasing much more often, you will still gain from getting much more feedback from customers, but there will be loud drone of bug fixing conflicting with the "agile" manager's push to release more features.
If your implementation of "agile" actually includes frequent refactoring and you don't have unit or at least integration tests, you are definitely going to be sorry.
Test-driven development requires a little bit more discipline, sometimes more up-front design, and sometimes investment in developer training. If TDD or the like is off the table or only partially implemented but you are still going ahead with "agile", then you still might survive, if you have a real QA analyst and solid process. My perception and experience is that most managers will decide that hiring an additional person "just for testing" is "not in the budget" and if they do bring someone onto the project for QA they will think they can use just any person rather than hiring a single QA professional.
That has been my experience with agile. Several years in, I am still working on trying to discipline myself and with my latest project I am having a bit of success with vows-bdd integration tests. But TDD/BDD etc. is a skillset that takes time to develop and a discipline that I believe young developers will greatly benefit from if it is part of their early training and experience.
And probably a growing number of people are going to be put off by their experiences with "agile", if they are anything like mine have been.
Managers love the idea of releasing more often and understand that. And that part can be an improvement.
However, quite a few people seem to think that means you can fit that many more features in, which is false.
This is the big challenge for agile in my opinion: automated testing or even testing at all, is hard for many development teams for a number of reasons. Not to say that the actual skills or knowledge are particularly difficult to acquire. But practically speaking, putting into place a good testing and release system are challenging for many teams.
And doing "agile" (read: code and release more features faster) without solid automated testing or at least one real QA analyst who is busy, will guarantee that you have a ton of regressions and broken deployments. Now, since you are releasing much more often, you will still gain from getting much more feedback from customers, but there will be loud drone of bug fixing conflicting with the "agile" manager's push to release more features.
If your implementation of "agile" actually includes frequent refactoring and you don't have unit or at least integration tests, you are definitely going to be sorry.
Test-driven development requires a little bit more discipline, sometimes more up-front design, and sometimes investment in developer training. If TDD or the like is off the table or only partially implemented but you are still going ahead with "agile", then you still might survive, if you have a real QA analyst and solid process. My perception and experience is that most managers will decide that hiring an additional person "just for testing" is "not in the budget" and if they do bring someone onto the project for QA they will think they can use just any person rather than hiring a single QA professional.
That has been my experience with agile. Several years in, I am still working on trying to discipline myself and with my latest project I am having a bit of success with vows-bdd integration tests. But TDD/BDD etc. is a skillset that takes time to develop and a discipline that I believe young developers will greatly benefit from if it is part of their early training and experience.