The biggest problem with Agile is that development teams might embrace Agile, but management continues on the same path as before. How many times did we want to change product and process, but figured that the change is so massive that we need management buy in. After inqurying again and again what the management decision is it eventually was put on a meeting agenda months later. I don't recall that we ever got a response. The entire organisation needs to be agile and focus on quick, simple results. Any process that takes longer than a few days needs to be tossed out, that includes getting new hardware, spinning up virtual servers for product deployment, and getting other decisions made.
What strikes me odd in all that Agile discussion and also mentioned in the article here is the focus on testing and quality. Since I am working in an Agile team the interest in fixing bugs went down a lot. The product owner is more interested in getting new features in than getting existing features properly working. There was barely any feature that truly was done as in design and code completed, fully tested, and patched to a high quality level. The argument is that we want to get feedback first before making any design changes. I have yet to see any feedback or any convincing reason other than wanting to stuff more features in than keeping quality high. Agile is nothing but pure frustration for someone working in QA. Developers love it because they can do whatever they want and call it quick iterations and on the go design. And we also lack some detailed requirements most of the time, so developers build something that in QA's mind does not meet the requests and the product owner as decision maker asks for new features, wants to keep clearly dysfunctional design in place...and we all wait for the feedback to come.
There really is no point in delivering features ready to ship when the industry does not expect or want releases every few weeks. We did two releases a year in the past and many customers complained about that to be too frequent. Most of them skipped one release and did the upgrade only once a year. I can see a benefit for sales to have something new to show every other week. For that reason I suggest adopting a continuous delivery model where features get pushed out when they are done. That means that sometimes it will take a month or longer to get a big feature in place. Often there is no point in delivering it piece by piece. A set of database tables and an empty form do not add any value.
Lastly, the artificial time boxing especially with Scrum is a major obstacle. Three weeks is just not enough to do design, development, and testing. QA might get the test plans in place going by vague requirements, but then ends up changing the plans to match what the rogue developers cooked up leaving the last four hours of a sprint to do some testing. Any bugs found will not get fixed because that was part of the old sprint and now we do new features. It is a quality nightmare and the overabundance of mediocre software clearly shows this. Scrum in particular is nothing else than mini waterfall with the QA phase lopped off. If a team is lucky it gets to do a hardening sprint where the worst of the accumulated technological debt might be mitigated, but often enough so much undone stuff piled up that most of it gets scratched or postponed to be never done.
Agile is the death of quality....but maybe we are just doing it wrong.