New Analyst Report Calls Agile a Scam, Says It's An Easy Out For Lazy Devs 491
msmoriarty writes "We recently got a copy of a new Voke analyst report on Agile, and the firm basically blasts the movement from top to bottom. Some highlights: 'The Agile movement is designed to sell services. ... Out of over 200 survey participants, we received only four detailed comments describing success with Agile.' 'Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance. ... Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.' So did the analysts just talk to the wrong 200 people?"
It's a myth that agile is undisciplined (Score:2, Informative)
We have to practice planning and create documentation like everyone else, we just do it on rapid iterations. Agile done right will force discipline on developers and they will hold each other accountable for deliverables.
In our company there's really no alternative to agile, because our customers never know what they want. We've tried various "waterfall" methods over and over, with the same results each time--the initial requirements are vague and/or poorly understood, leading to a lot of wasteful development and missed expectations that cause the project to be late, sometimes cancelled, or if it ships it doesn't work the way the customer wants it to.
Re:Requirements do change (Score:4, Informative)
Thank you for describing Agile so I could understand it better, however I try to see The Point, aside from causing me deadline stress with regularity.
I always try to point folks to this wikipedia page that describes RUP; especially the graphic. In fact I have found on every single project whenever I have any say on the matter, all the stakeholders adore planning based off of this instructional page-as-a-plan. I wish I could say this happened to me a lot.
Usually discussing the graphic in an important stage is enough to set the pace of the project, in my experience on more informal projects.
https://en.wikipedia.org/wiki/IBM_Rational_Unified_Process [wikipedia.org]
Re:Agreed and... (Score:5, Informative)
One of the main things you should be doing when practicing agile is continuous integration. The point is that you should be able to release at the drop of a hat. It has been a long time since I have had to worry about long-delayed integration woes.
Re:Right people, right results (Score:4, Informative)
Where's the tests?
The article also goes on about that there's no documentation, no process etc. From my experience agile projects are better documented via tests than other projects via "documentation". And because of this maintenance is easier in the long run.
Agile is not an excuse to lower quality and neglect software engineering.
Exactly right. Tests are requirements are documentation.
Want a new feature? Add a test.
Want to report a bug? Add a test.
Want to understand the system? Read the tests.
My current project has >1K devs, and >1M LOC. The doc is under a hundred pages, and that is mostly "how-to" stuff. There are also hours of "why we did X" videos to explain the design. Almost no comments in the code: if the code is unclear or poor, we just reject it: no one is allowed to use comments to explain how something works.
One critical module (approx 20K LOC) has >1K tests. Its release cycle is essentially daily, numerous devs in various teams have contributed to it, and it almost never breaks. The test pack is what allows it to be agile and replace >1M LOC of legacy system code.
Took the words (Score:5, Informative)
Right out of my mouth. You're NOT DOING AGILE if you have to integrate components at the end.
Also, the idea is not "we can just recode everything at the end", the idea is "only code now what you need right now", so yes, you will refactor, but that refactoring is an ongoing part of the process that is informed by 2 things, continuous integration and user acceptance testing.
IMHO one of the MAIN reasons why people will fail with Agile is that they ignore the requirement to have the customer/stake-holders right there in the process. If you actually PAY ATTENTION to the things that Agile is telling you to do (personally I find XP type process to be the most effective) then you can make it work. Everyone needs to understand the value of the parts, and as any Agile expert will tell you ALL the pieces are important. It is not at all interesting news for someone to tell me that if you fuck up and ignore half the pieces of the process that the other half don't magically just work.
No one development methodology is a panacea of course, but this report seems to be meaningless criticism based on not actually understanding how and why to use Agile.
This finding does not match my experience (Score:4, Informative)
Agile is not a product. It is a mindset. Each team needs to workout what that means for them. I have been in teams for two companies that used Agile methods heavily and it has worked out very well for business units (predictable deliveries), developers (predictable work hours) and customers (higher quality releases).
I am positive Agile is not a silver bullet for every project. Software engineering is still a hard problem to generalize.
Re:You get what you pay/wait for (Score:4, Informative)
Re:You get what you pay/wait for (Score:2, Informative)
Really? Because I find that our internal tools would be a bad choice. First, for internal tools, we typically aren't trying to manage customer expectations, and we all know pretty well at the start what the tools objective is. Meeting about it daily is usually a waste of time. But then again, that's our place, yours may be different.