Linked by snydeq on Tue 2nd Nov 2010 23:08 UTC
General Development InfoWorld offers a look back at the first decade of agile programming. Forged in February 2001 when a group of developers convened in Utah to find an alternative to documentation-driven, 'heavyweight' software development practices, The Manifesto for Agile Software Development sought to promote processes that accommodate changing requirements, collaboration with customers, and delivery of software in short iterations. Fast-forward a decade, and agile software development is becoming increasingly commonplace, with software firms adopting agile offshoots such as Scrum, Extreme Programming, and Kanban - a trend some see benefiting software development overall
Thread beginning with comment 448311
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: terrible article
by Gunderwo on Wed 3rd Nov 2010 05:05 UTC in reply to "RE: terrible article"
Gunderwo
Member since:
2006-01-03

In my experience there are a lot of companies that say they use Agile methodologies and do TDD when all they're doing is paying lip service to the buzz words that make them feel better.

In order for agile methods to work the developers and managers need to actually understand the how, and why of each step and do it right otherwise it's just adding extra overhead.

I've worked at several places that will SCRUM but then never do burndowns and calculate velocities. Or think that because they didn't get everything done in a sprint they can just add the missed tasks to the next sprint and end up in the same place at the end of the next one.

Bad management is bad management no matter what the buzzword methodology being used. And bad developers will always be bad developers if they don't try and learn how to become better.

Edited 2010-11-03 05:06 UTC

Reply Parent Score: 8

RE[3]: terrible article
by Tuishimi on Wed 3rd Nov 2010 06:52 in reply to "RE[2]: terrible article"
Tuishimi Member since:
2005-07-06

I would have voted this up but I already commented...

I can see that agile has benefits but only if it is done right and if everyone involved in a project knows and understands the process and tools well.

I come from the "old school" ways... it has been difficult but not impossible for me to latch onto this, but even I, with my minimal knowledge, see the process totally abused on a day to day basis... And let me tell you... a project run under the "agile" moniker but not REALLY is PAINFUL. I am in one of those right now.

Scrums break down into technical discussions, sprint planning becomes "this is what you all need to have done for this sprint"... etc.

I'd much rather do it the old way, spend time up front to use the old input-output requirements, functional specs/flow charts and design specs BEFORE we start coding so that it is clear as to what needs to be done.

No fancy terminology, meetings circumscribed by their purpose as they always were, development cycles demarked simply by deliverables, etc.

Now, I KNOW the agile process defines these things, but unless a company commits 100% to learn and implement it, it's useless.

Reply Parent Score: 5

RE[3]: terrible article
by Troels on Wed 3rd Nov 2010 09:43 in reply to "RE[2]: terrible article"
Troels Member since:
2005-07-11

Sure the methods can be abused and lead to horrible results, but i don't believe focussing on the burndown or velocity is really all that important.

Sure it is nice to know if you are on track or not, but what really matters IMO is breaking the projects into more mangeable sprints in the first place, dividing the developers into smaller groups that can have rapid communication, and the daily scrums that help catch problems before they get big, and of course the ability to quickly react when conditions change. Communication is the key word.

Reply Parent Score: 1