Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A Decade of Agile Programming — Has It Delivered?

timothy posted more than 3 years ago | from the tell-you-at-the-next-scrum dept.

Programming 395

snydeq writes "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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


No (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34109830)


Re:No (0, Insightful)

Anonymous Coward | more than 3 years ago | (#34109936)


Re:No (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34110106)

Go gargle bees.

Re:No (1, Funny)

Anonymous Coward | more than 3 years ago | (#34110154)

You're just not doing it right then. ;)

Re:No (3, Interesting)

mcgrew (92797) | more than 3 years ago | (#34110208)

From languages I've seen, programming has regressed in the last decade. When Grace Hopper wrote the first compiler, her dream was an english-like language that computers and people could both understand easily with a minimum of training. She co-wrote COBOL as the second compiler.

Older languages, like the mainframe DBMS NOMAD and the PC DBMS dBase were IMO brilliant. They needed little documentation, and no curly braces or other such nonsense you find in modern languages like C or Java.

The "language" I hate most is MS Access. Convoluted and unintuitive, you don't really write anything, and what's produced is "visual basic" and the equally unreadable SQL.

I hate it. I'd rather program in assembly, so I can know what registers are being accessed, whether I pushed or popped a stack (and which stack), etc.

I hate programming in a language that doesn't let me feel the metal. Hell, I'd tale old fashioned 1980 BASIC over the newer languages; it doesn't take long to learn not to write spagetti.

Maybe they did it wrong... (5, Interesting)

TheFakeMcCoy (1485631) | more than 3 years ago | (#34109832)

A team in my the company I worked for was designing a new set of software and were utilizing Agile development. Well, seems they spent so much time going back and changing the software due to the changing demands that they never got anything finished to demonstrate so they wiped out the project team.

Re:Maybe they did it wrong... (5, Insightful)

MadKeithV (102058) | more than 3 years ago | (#34109860)

"You are doing it wrong" is the perpetual excuse of Agilists when you say that agile methods have not worked for you. They are hiding behind a certain impossible to define or explain "something" that you supposedly are not doing or not doing right that causes your project to fail, because if you were Doing Agile Right (tm) (whatever that means) your project would have been a resounding success.

In the end Fred Brooks got it right decades ago: "there is no silver bullet". Software development is just hard. Anything promising massive gains in success or effectiveness is snake oil.

Re:Maybe they did it wrong... (5, Insightful)

91degrees (207121) | more than 3 years ago | (#34109894)

Well, they are doing it wrong.

The something is possible to define and explain but is typically different in different cases.

In this case it seems that the problem is changing requirements. That will kill any project no matter what the methodology.

Re:Maybe they did it wrong... (5, Insightful)

MadKeithV (102058) | more than 3 years ago | (#34109958)

In this case it seems that the problem is changing requirements. That will kill any project no matter what the methodology.

This is exactly one of the key points that the Agile community keep trying to drill into us! The Agile Manifesto explicitly states "Responding to change over following a plan", which is translated into the principle "Welcome changing requirements, even late in development."

Re:Maybe they did it wrong... (4, Funny)

Jurily (900488) | more than 3 years ago | (#34110162)

Shhh, we're talking about Agile. Put your logic away and break out the Bib^Wmanifesto.

Re:Maybe they did it wrong... (5, Insightful)

gutnor (872759) | more than 3 years ago | (#34110340)

The change are welcome in Agile indeed. That does not mean that there is no consequence of that change. A lot of changed requirement means a later release and if you keep changing, you will never release anything. But there is no methodology that can prevent that.

To take a car analogy - using Agile is like using a GPS: it is a methodology that tells you were you are, and can adapt if you take a wrong turn or if you change the destination. Like the GPS, if you cannot make up your mind where you are going (or do follow the indication of the GPS gives - been there, ...) you will not get anywhere.

Re:Maybe they did it wrong... (1)

Eraesr (1629799) | more than 3 years ago | (#34110160)

No, really... no.
If using a methodology where you start off with a design which firmly sets the requirements of the software, then changing requirements is something that simply won't happen.
Granted, it's not a perfect world so new things are bound to slip through, but that's often more a case of a manager forcing it down your throat, forcing you to deviate from the methodology rather than the methodology being incorrect.

Re:Maybe they did it wrong... (5, Interesting)

JLangbridge (1613103) | more than 3 years ago | (#34110012)

I was fired from a job because of Agile... I'm a C developper, and one part of the server had Java development. Well, guess who had to take the post-it, because "that is the way things are done". So here I was doing Java, on a ticket that was supposed to take a day, I did it in 4. I had to take the ticket, because that is what Agile is about. During the scrum meetings, I said I had problems with it, but I couldn't ask for help, because I took the ticket, and "that is the way things are done". I was a 6-month trial period, so they sacked me with no warning, because I was crap at my job. Since then I've been working with multinationals, and the previous company has made one single iPhone App that has a rating of 1-star, their previous flagship application is now one-star too (and on the verge of a lawsuit because of a dodgy change of contract for the application). Since then, I've had real Agile training, and the trainer explained the way things were really done, and at least I know I wasn't in the wrong. Still, my first Agile experience cost me my job. That's what I remember.

Re:Maybe they did it wrong... (4, Insightful)

iangoldby (552781) | more than 3 years ago | (#34110182)

I was fired from a job because of Agile... Since then, I've had real Agile training... Still, my first Agile experience cost me my job.

I don't know enough about Agile to make a judgment myself, but you've practically said it yourself: your first experience wasn't Agile, it was just something that someone called 'Agile'.

Re:Maybe they did it wrong... (5, Insightful)

elrous0 (869638) | more than 3 years ago | (#34110460)

Your post reminds me of a Muslim friend who told me once (dead seriously) that Muslims didn't attack the World Trade Center. They weren't REAL Muslims, you see.

Re:Maybe they did it wrong... (0)

Anonymous Coward | more than 3 years ago | (#34110636)

Ah, the good old No Real Scotsman fallacy 3

Re:Maybe they did it wrong... (3, Insightful)

Anonymous Coward | more than 3 years ago | (#34110598)

Firstly, I think Agile has delivered. The real problem is that most companies (people) have used the term, "agile" to mean I don't really have to have discipline because I'm being so agile. In my experience, management loves the "code done in two weeks" part, but they hate that the rest of it has to be done in two week increments part. In my opinion, Agile methodologies have had the least affect on developers. Most of the rest of IT is used to a leisurely pace where they have meetings for six months to decide what programmers should do in two weeks. Using an agile methodology, these same folks are under the gun to deliver and, in my experience, they don't like it.

Re:Maybe they did it wrong... (1)

dropadrop (1057046) | more than 3 years ago | (#34110308)

Somehow I get a feeling that this was mainly a problem with the employer, or the way they implemented agile programming.

Re:Maybe they did it wrong... (1)

nschubach (922175) | more than 3 years ago | (#34110754)

My supervisor got the brilliant idea to implement Scrum ...

The only problem is that it's not Scrum. We meet every day and justify "yesterday." If you can't come up with arbitrary numbers to say you worked on something (not just your projects, you must include the 2 hours you spent helping someone with their project) for at least 6 hours you start getting questioned about what you did yesterday in front of the "team."

Re:Maybe they did it wrong... (3, Insightful)

jfanning (35979) | more than 3 years ago | (#34110414)

Uh, that's not Agile. Nearly everything you mentioned there is so anti-agile I can't even start breaking it down. Slapping an Agile tag on it doesn't make it agile. No mater what most companies think.

I have seen frequently referenced that the switch to agile takes up to 18 months to produce results. And even then there have been studies that find no significant enhancement in productivity.

As far as I can see there is no actual benefit in productivity at all moving to agile. It just gives greater clarity to the current state of development and should produce software with lower levels of faults through automated testing and continuous integration.

Re:Maybe they did it wrong... (4, Informative)

dkleinsc (563838) | more than 3 years ago | (#34110056)

Well, yes and no.

There have been some developments since Brooks wrote No Silver Bullet that have helped by attacking the accidental complexity of software development - widespread use of garbage collection, for instance. But Brooks is still absolutely correct that the complexities of software have a lot more to do with the complexities of the human mental modeling, heuristics, and decisions that software replaces than they do with the challenge of converting that to something the computer can understand.

Re:Maybe they did it wrong... (1)

MadKeithV (102058) | more than 3 years ago | (#34110082)

Well, yes and no.

There have been some developments since Brooks wrote No Silver Bullet that have helped by attacking the accidental complexity of software development - widespread use of garbage collection, for instance. But Brooks is still absolutely correct that the complexities of software have a lot more to do with the complexities of the human mental modeling, heuristics, and decisions that software replaces than they do with the challenge of converting that to something the computer can understand.

Oh man, wrong tree :)
I'm involved in a .NET to native wrapping project, and I'm NOT friends with the garbage collector right now.

I wasn't really referring to the detail of Brooks' essay, just the overall idea that there is no silver bullet to make solving hard problems easy. The "hard problems" are the things that have not been done before that our customers are asking us to develop.

Re:Maybe they did it wrong... (2, Interesting)

Anonymous Coward | more than 3 years ago | (#34110058)

+1 yes

Verily I say unto you, Agile is the development methodology of mystics. You don't fail or succeed on this basis alone. You also have to be not an idiot, and you must not have idiot managers and idiot customers. Agile doesn't prevent anybody from being these things. Nor does waterfall turn you into these things.

"You're doing it wrong" is a phrase you hear uttered by proponents of faith healing, psychics, homeopaths, practitioners of feng shui, gingers, etc when their particular brand of woowoo fails to deliver on its promises.

Now, that's not to say someone *isn't*, in fact, doing it wrong. But I am saying that you can't necessarily take next step and conclude that there is a *right* way.

Re:Maybe they did it wrong... (2, Insightful)

Anonymous Coward | more than 3 years ago | (#34110828)

You also have to be not an idiot, and you must not have idiot managers and idiot customers.

Therefore, it is always doomed to failure, since at least one of those will always be true.

The most successful model will be one that assumes all of those are going to be true.

Indeed, THERE IS NO SILVER BULLET (4, Insightful)

SmallFurryCreature (593017) | more than 3 years ago | (#34110376)

IT, or at least some people in IT suffer from what I call the "Oprah" syndrome. No, not the weight issue. The idea that a problem is just one problem and that it can be solved with a single solution. Or the silver bullet that will solve all your problems at once.

Software development is bloody hard, partly because it doesn't deal with a real product and testing a software product is extremely abstract.

If I design a better brake pad, I can test this fairly simply AND thorougly. We know exactly what it is supposed to do, how it does it and how we can compare performance. There is no magic, if the brakepad reaches 198 degrees on a sunday, the trunk will pop open. Also nobody will ask a brake pad engineer to add a christmas special to it, on the 25th of december, at 8 in the evening.

Web development especially suffers from the idea that if only we implement magic method number #45324521, all the hassle of web development will go away. Writing specs is long boring and not very sexy. So lets do agile and not write them anymore. Problem solved... eh no because spec writing is long boring and not very sexy because getting the requirements out of a user is like sucking cock. The user might enjoy it but you are just left with a bad taste in your mouth and a desire to throw up over the user. Or maybe that is just my dates.

"But if you do agile right", but if you do documentation driven development right! Any method, done right will most likely work. That is the definition of doing it right. Why is it so hard to do agile right? Why are there so many variants already?

I see a lot of "magic" solutions in web development.

Database abstraction, so we can magically switch database!!!

Question: When have you EVER switched database on a web application and HOW easy was it? Is there ANYONE out there who only use pure SQL that is 100% understood by all databases the same? Then go stand in the corner, because your code lacks any optimization. Real developers optimize their code for the specific environment they are using. This includes making use of database specific features. Don't use Mysql auto-increment and PDO and think you are database independent.

Frameworks take all the hardship out of writing code!!!

Question: How smart do you think it is to hire a coder who hates to code? It is like hating a singer who hates to sing, a spokeperson who doesn't like talking.

This is where a lot of the silver bullets come from, from people that don't actually want to be a developer but just cash the paycheck. You don't hire a cook who only knows how to nuke frozen meals do you? If you go to the supermarket and buy a microwave meal thinking wow, this makes cooking easy, then here is a hint: IT AIN'T COOKING. It is heating up food.

I see time after time some framework or tool promosing a complete working website without writing a line of code... EEK! That is my JOB! Luckily they are all wrong because what at most they do is create a straight CMS for your database, which is rarely what the customer wants. After all, there are already plenty of tools to graphically maintain your database content.

No, Agile hasn't delivered... for those looking for a silver bullet to the problems of development. For others, it is a valid method with its own problems that puts it along side more traditional models, not ahead of them.

We're ALWAYS doing it wrong (2, Insightful)

elrous0 (869638) | more than 3 years ago | (#34110384)

Reminds me of an old poster [globalnerdy.com] from my CS department. It features legendary crotchety old fart John McCarthy [wikipedia.org] angrily looking at the camera, with the caption "Programming: You're Doing It Completely Wrong."

Re:Maybe they did it wrong... (4, Interesting)

Superken7 (893292) | more than 3 years ago | (#34109976)

I fail to understand why that failing was related to the methodology?

"Due to changing demands"

It doesn't matter which methodology you use, if your goal is constantly changing you won't get anything finished, almost "by definition". If it wasn't that bad, maybe they weren't familiar enough with the methodology?

In fact, I'd say that agile software development methodologies work best for such projects, because they are aimed at constantly changing demands.
That's why almost all startups use agile software development, because *every* startup goes through a process like (very grossly, mind you):

1. search a business model
2. execute business model
3. realize 1) wasn't realistic, change it
4. goto 1

The transition process (usually referred to as pivoting) needs to occur *rapidly* and *continuously*, hence the agile software development.

Of course, if you keep changing the initial goal, you will never get finished, doesn't matter which methodology you use.

Re:Maybe they did it wrong... (5, Insightful)

Entrope (68843) | more than 3 years ago | (#34110044)

Agile principle #2 (from http://agilemanifesto.org/principles.html [agilemanifesto.org]): "Welcome changing requirements, even late in
development." Other methodologies typically draw a line in the sand to recognize the costs of changing requirements late in development. They don't often forbid crossing that line, but they encourage people to honestly evaluate the trade-offs involved in changing requirements.

Re:Maybe they did it wrong... (0)

Anonymous Coward | more than 3 years ago | (#34110590)

it's because as purists as they were, they forgot an important addition to that principle; it should be stated as follow:

"welcome changing requirements, even late in development, but do not forget of charging it up front"

Re:Maybe they did it wrong... (1)

AnonymousClown (1788472) | more than 3 years ago | (#34110336)

The transition process (usually referred to as pivoting) needs to occur *rapidly* and *continuously*, hence the agile software development.

We called that "Cluster Fuck" development in my day.

Re:Maybe they did it wrong... (1)

TrueKonrads (580974) | more than 3 years ago | (#34110706)

The key message behind that principle is: "Don't deliver working software that has no more purpose for business". If you can deliver a well QA'd and developed software that is obsolete by the time it is shipped then that is money wasted. If the development overall objective is always slipping, but along the way useful software modules are delivered to the users and they make money, then it is a success.

Re:Maybe they did it wrong... (0)

Anonymous Coward | more than 3 years ago | (#34110500)

you don't need agile, you need git. git makes it easy to branch and merge, trying out radically new features (or total rewrites) with no pain. git.

Re:Maybe they did it wrong... (1)

mkawick (190367) | more than 3 years ago | (#34110836)

Welcome change...but every two weeks. I do see this too often.. every day the manager comes in with a new idea and the team jumps on it. This is called a sprint hijack and can destroy morale and productivity. After a sprint begins, the team should be 'locked down' and any new ideas should be added to the backlog. When you do your sprint planning, then you go through the backlog and decide what's important.

You would never deliver if you had new requirements every day. Scrum is meant to always deliver and you should deliver something every two weeks.

Re:Maybe they did it wrong... (3, Insightful)

William Robinson (875390) | more than 3 years ago | (#34109986)

Software development requires Creativity, Discipline and many more things apart from Agile, and the process goes through lot of iterations, training, discussions and confidence building among developers to motivate them to follow process in the company. Also, the process to be adapted should be close to the type of Software company is focused on and what developers are comfortable with. Many process designers/implementers forget this fact and blindly throw something at them and expect results overnight and get surprised when it ends up disastrous.

It takes time to show them the processes are here to improve quality. Agile or any other Software Engineering process is not bad. The process of process implementation could be bad.

Also, process implementation is a difficult task if upper management believes that it is job of juniors.

So yes, I agree with you that Maybe they did it wrong way. If somebody believes Agile is going to work like a switch, they are mistaken.

My 2 cents.

Re:Maybe they did it wrong... (2, Interesting)

mkawick (190367) | more than 3 years ago | (#34110750)

Alright, I'll bite. What do you mean that you're doing it wrong. Agile is supposed to be many things but as long as you follow a few key ideas, it'll work better than waterfall.

1) Continuous delivery. Deliver something every two weeks.
2) Quickly fail. If a problem is found in a design or a project, find it early and save tons of money.
3) Small teams. No 80-person teams here.
4) Small tasks that you should accomplish quickly helping with visibility
5) Highly visible tasks and burndowns to help with "buy in" from upper mgmt
6) Open communication meaning that the team has the responsibility of fixing things, identifying poor performers, and helping people to succeed.

No manager... just scrum masters.

Just these few key points make a world of difference and can be key to success. I haven't seen it fail but maybe you were in a company of design-by-personality...

A point of view (0)

Anonymous Coward | more than 3 years ago | (#34109836)

As a developer I find it to be a pain in the ass. Maybe in wasn't done correctly in the projects I worked, but this is my view.
And scrum is really offending to people that actually have a tad of self respect: I mean, really, pigs and chickens ?!

Re:A point of view (4, Insightful)

drewhk (1744562) | more than 3 years ago | (#34109846)

The original manifesto's key message was "people over processes" which I still agree with. On the other hand the word "Agile" now means just as many processes as waterfall or RUP meant in the past. Shame.

Re:A point of view (3, Insightful)

JaredOfEuropa (526365) | more than 3 years ago | (#34110374)

"People over process" is an important tenet in more ways than one, and not only in IT. Often, this message is taken to mean that teams and individuals are given more freedom to organise their own work, and are managed on outcome rather than activities. This is true in some ways, but it's more than that.

"People over process" to me also means acknowledging the value of each individual's skills and abilities. That starts with resourcing: instead of posting jobs for "2 junior programmers, 1 senior programmer, 1 encryption specialist (part time) and 1 PM", one would think "Together, Alice and Bob are up to the task of writing this module, Alice knows enough about encryption to cover that part of the job, and Bob is a good team lead". No two people are alike, and if you value people, that means that you account for their differences as well. Yes, it also means that if Alice calls in sick, you have a problem on your hand, but it's by no means an insurmountable problem.

And it goes beyond that. "People over process" to me also means that you let people do what they are good at beyond the call of their assignment. (as long as it benefits the company). As an individual, it means that you sometimes take responsibility for stuff that is not strictly your job. If someone contacts me with a problem I can solve, I do not answer with "Contact the helpdesk"... if it's likely the problem will get kicked down 3 layers, taking 2 weeks to come up with a non-answer. Instead I will take an hour off my regular work to provide a helpful answer (of course with the suggestion that they contact the helpdesk, and copying in support as well). This helps everyone, including the company.

Yes, accounting for individual differences makes budgeting, resourcing, managing continuity, and people management a lot harder. That's why managers hate "people over process" and why Agile IT gets loaded down with more process: resources are so much easier to manage than people.

Re:A point of view (1)

mcgrew (92797) | more than 3 years ago | (#34110482)

The original manifesto's key message was "people over processes" which I still agree with.

I read the summary's links and never saw anything concrete, just marketing buzzwords. But "people over processes?" That makes no sense at all on the programming end; in the end it's all processes.

"People over process" makes sense from a design point of view, but not the nuts and bolts of programming itself, any more than "people over processes" makes sence when engineering an automobile engine.

Re:A point of view (0)

Anonymous Coward | more than 3 years ago | (#34110522)

process is important. it insures that critical information is available in a standard easy to find way. this is why all methodologies have it in some way or another.

Captain Obvious (4, Insightful)

MadKeithV (102058) | more than 3 years ago | (#34109838)

Quoth TFA: "Despite potential pitfalls, experts in the agile space agree that implementation of agile practices has benefited software development overall."
And in other news, despite potential pitfalls, the pope agrees that Catholicism has benefited religion overall.

It's all I've ever known (1)

Faraday's Sloth (720456) | more than 3 years ago | (#34109850)

I've been working in the sofwtare industry since 2007 in a small team (individual projects ranging from 1 to 10 persons). We've always used scrum. Mind you, not by the book but heavily modified to fit our style. Seems to work if all participants are even a bit motivated and not totally clueless about the tasks at hand.

"Agile", no -- "agile", yes (4, Interesting)

CyberDong (137370) | more than 3 years ago | (#34109854)

I've worked in 100% waterfall, and in good agile environments, and I've found the key is to keep things small-a "agile", not to concentrate on capital-a Agile. Some places embrace Agile as a process, and fill binders with process documentation around their Agile process - at which point it's no better than any other.

I think the key to success is summed up in this line from T3FA:

"Most teams are not adopting scrum, extreme programming, or another specific Agile approach, but are embracing agile as an ethos or philosophy and cherry-picking the best bits from many different process models to develop a formula unique to their own situation," according to the report.

Re:"Agile", no -- "agile", yes (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34109884)

Basically it means they are not using any specific methodology but doing things as they think it's better in specific circumstances. The question is then if we shouldn't just drop all the crap about methodologies and just go ahead and do things the best way we can.

Re:"Agile", no -- "agile", yes (4, Insightful)

drewhk (1744562) | more than 3 years ago | (#34109916)

The original Manifesto:

"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more."

I think it is hard to disagree with the original statement. What is frustrating now, is that "Agile" degraded to a bunch of buzzwords and processes (SCRUM, XP, TDD, BDD, etc.) which it was going against originally. Of course it is more business in selling these (by consulting companies) than the vague "do what fits you best" statement.

Also, the problem is not with particular practices, or processes but the mindless, inflexible application of them to every project and team on earth. Teams are different, software are different, why should we all use the same processes then?

Re:"Agile", no -- "agile", yes (1)

plastick (1607981) | more than 3 years ago | (#34110594)

Not only that, but how many organizations use Post-it notes to write down requirements and call it SCRUM?

And if you ask them if they are using the other parts of these methodologies, they will say they "invented their own version" to suit their business.

Re:"Agile", no -- "agile", yes (1)

MobyDisk (75490) | more than 3 years ago | (#34110670)

What is frustrating now, is that "Agile" degraded to a bunch of buzzwords and processes (SCRUM, XP, TDD, BDD, etc.) which it was going against originally.

Realistically, the original authors were never against buzzwords and processes. They were against the buzzwords and processes of the time. With experience, their new approach also yielded repeatable processes that needed their own new vocabulary. And that vocabulary gets called "buzzwords" by the next generation, and the cycle repeats forever.

Words are not evil. We assign names to things so that we can clearly communicate those concepts to other people. You can't be a professional in something and not have a vocabulary assigned to it. Anthropologically speaking, you can't even think about something without having a vocabulary for it. So we need to stop making these approaches that boil down to "My approach is whatever approach has no vocabulary or well-defined concepts in it. I want to be unique! I don't have a number!"

Agile is different from Waterfall. Agile approaches include things like SCRUM, XP, TDD, BDD, etc. Those are words describing agile approaches. Don't lament that we now have well-defined ways to be agile. Giving them names doesn't make us less agile, it just means we can talk to someone else and know that we are talking about the same thing. I've worked on teams that claimed to be "agile" which really meant that they didn't have any process, and didn't understand the SDLC, and were always late and buggy.

Re:"Agile", no -- "agile", yes (1)

mcgrew (92797) | more than 3 years ago | (#34110676)

I think it is hard to disagree with the original statement.

I think it's idiotic. "Working software over comprehensive documentation"? Yeah, good luck debugging your undocumented code. And I hope your help desk personnel have fun if there is no FM to R.

"Individuals and interactions over processes and tools"? Any carpenter, electrician, or anyone else who makes things would laugh their asses off at that. Software about nothing BUT processes and tools.

For a software design aspect it makes sense, but not from a programming standpoint.

Re:"Agile", no -- "agile", yes (1)

MadKeithV (102058) | more than 3 years ago | (#34109924)

If you drill down, the original quote basically means that Agilists (big-A) are defining "their process" as "whatever you're doing that is actually working, THAT's Agile man, keep doing it! I'll take my consultancy fee now.".

Meanwhile the rest of the world is just trying to get the job done, trying not to waste time in "methodologies", but us old fogeys keep having to explain to the new guys that we've *tried* all this stuff, and what we are already doing is what works for us.

Re:"Agile", no -- "agile", yes (0)

Anonymous Coward | more than 3 years ago | (#34109886)

Agile's main downfall is that it makes it look like you can go faster than you really can. Waterfall looks slow and it is; Agile looks really fast, but if you actually move as fast as it looks like you could, skipping testing and documentation, you will be screwed. Fast, cheap, minimal bugs; I don't care what method you use, you will only achieve two of those at any given time. Agile also doesn't solve the scheduling baby problem, i.e. just because it takes 1 woman 9 months to have a baby, doesn't mean that you can put 9 women on the project and produce a baby in one month.

Re:"Agile", no -- "agile", yes (2, Interesting)

arth1 (260657) | more than 3 years ago | (#34110128)

A related problem is that you don't look ahead and don't see the showstoppers until it's too late to avoid them. When you do, you often end up having to rewrite large parts of the code or implement major kludges.
At least with a traditional methodology, everything is reviewed for feasibility and risks before you invest too much time driving down the wrong path. And a change in scope means a forced review of how this affects everything else too.

But there are benefits to agile too, not the least of which is that it shows progress, which gets management off the developers' backs, which in turn increases productivity.

My preferred method is parallel programming, where two or more units are set to design and do the same task, and halfway through, you present both solutions, axe one of them, and merge it with the remaining unit, with focus on doing QA They don't know the other unit's code, but will know many of the inherent problems, and see ones that the "winning" team are blind to.
Your initial velocity will be slower, but you'll end up with both a solid product, and one that management has actually picked themselves, and thus feel obligated to stand behind.
And no, the hours when you work double aren't wasted -- any more than the hours spent on scrum, six sigma or other "necessary overhead" are wasted. The competitiveness ensures a better product, and you even have fallback code and coders, whereas for administrative overhead the hours spent has zilch value later in the game.

If you speak overmuch of the Way (1)

jellyfrog (1645619) | more than 3 years ago | (#34110366)

you will not attain it?

The primary thing when you take a sword in your hands is your intention to cut the enemy, whatever the means. Whenever you parry, hit, spring, strike or touch the enemy's cutting sword, you must cut the enemy in the same movement. It is essential to attain this. If you think only of hitting, springing, striking or touching the enemy, you will not be able actually to cut him.

— Miyamoto Musashi (The Book of Five Rings)

the circle is complete. again. (0)

Anonymous Coward | more than 3 years ago | (#34109856)

I remember when we wrote video games for Atari and Amiga. and we just hacked away with quickly agreeing on things we had to achieve and who had to to what while we went along. So we were very agile without knowing the term. but this is over 20 years ago. and here we are again.... the full circle.

I love seeing liberals wallow in misery! (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34109866)

Ahhh, it's such a glorious new day! Al Gore can take his carbon trading self-enrichment shell game and shove it up his fat ass. And the 2 years of unemployment payments are about to expire, so all you bums will be forced to readjust your career expectations, look for work, and realize that most art history majors are not destined for $50k+ jobs. Suck it, fools!

Why don't they ask (3, Insightful)

JamesP (688957) | more than 3 years ago | (#34109880)

if waterfall has delivered?!

It seems most projects work in spite of waterfall, not because of it.

I'm not saying it doesn't work. That is for small/medium projects with a very tight scope it does.

What's the name of that FBI project again?! Virtual case file?! Oh well...

Re:Why don't they ask (1)

Shados (741919) | more than 3 years ago | (#34110300)

Ironically, Ive done agile in small companies with small projects, and in huge companies with multi-hundred millions projects and thousands of people involved (using Scrum of Scrums for scaling), both software and non-software project... the multi-hundred million dollar non-software projects in many cases worked better than the software ones in Agile.

Kind of counter intuitive.

Re:Why don't they ask (1)

elrous0 (869638) | more than 3 years ago | (#34110554)

Every day, your life is effected directly by thousands (if not hundreds of thousands) of pieces of software written during the waterfall era. So it must not have stagnated the programming field *too* much.

Personally, I always thought "agile" sounds like a dodge--suspiciously like a bunch of business doublespeak being hawked by con men who are selling managers on the bullshit idea that they can have fast, quality programming on the cheap. At the end of the day, quality work still takes time, someone still has to do the coding, and there are no free rides. "Agile" newspeak doesn't change the truth of the old axiom "Fast, cheap, or good: Pick any two."

Re:Why don't they ask (1)

arth1 (260657) | more than 3 years ago | (#34110556)

if waterfall has delivered?!

It seems most projects work in spite of waterfall, not because of it.

I'm not saying it doesn't work. That is for small/medium projects with a very tight scope it does.

You can substitute "waterfall" with "Agile" in the above, and it still makes exactly the same amount of sense.

A good measure of success is to look at what's actually out there. Discounting meta-products (like Agile developed systems to support Agile processes), I don't see Agile-developed software gaining a lot of ground. After 10 years or so, one would think that if it really was a lot better, at least half of all products out there would be Agile-based by now?
Of course, many successful products have been developed with "Agile-like" methods, including the bazaar.

Work's for us (1)

IronWilliamCash (1078065) | more than 3 years ago | (#34109882)

I work for a company that uses the scrum variant. It's been working for a while now and the company hasn't stopped growing because of it. The trick is to know when to say no to a change request for the current version of your software. You can always develop a functionnality for the next version, which in Agile is always in a short time. (We work with four iterations per year). All in all it works great for the time being.

Re:Work's for us (1)

jfanning (35979) | more than 3 years ago | (#34110430)

Iterations should be on the order of a week or two, not 3 months.

Re:Work's for us (1)

IronWilliamCash (1078065) | more than 3 years ago | (#34110568)

Unfortunately a week or two doesn't get enough done. Some things do fit in that time period, but some things don't so it's adapted a bit, but still works fine.

Re:Work's for us (1)

IronWilliamCash (1078065) | more than 3 years ago | (#34110592)

I'd like to specify also that the software developped is not available as a download, it's a dvd distributed version for large companies, changing the whole supply line every 2 weeks wouldn't be very nice for the budget.

First decade? Not likely (5, Interesting)

netsavior (627338) | more than 3 years ago | (#34109888)

In my experience, software development methodologies are more of a way of describing how teams already work. Sure you can put a name to it, polish it a bit, and other people can work toward that name, but there were tons of "Agile" projects and "Agile" groups before the manifesto. Maybe "Software companies" didn't do it before 2001 I don't know... but "software departments" of other companies have pretty much doing this since I have been around, which is a lot more than a decade.

The truth is that electronic delivery created agile development, at least for software companies. Internal departments have had the connectiviety for 2+ decades to deploy new releases often, but it wasn't till the late 1990s or early 2000s that a "boxed" software company could provide regular working releases to their customers (who wants to mail a CD or a stack of floppies every 3 weeks, and what customer would actually apply them?) Web-based apps and self-updating software just brought dedicated software development in line with corporate development practices, and then it was given a name.

Re:First decade? Not likely (1)

Rubinstien (6077) | more than 3 years ago | (#34110424)

I was a beta tester for Multi-Ad Services in 1988/89, when they were first developing Multi-Ad Creator. I had a telephone number that I could call that let me talk directly to one of the engineers. Our Ad department was running this on Mac II's, under MacOS 6.x. We'd find repeatable ways of crashing things, or think of a nifty feature that we wanted, make a phone call, and usually would have a disk in the mail within a few *days* with the changes available for testing. There were a ton of features put into that product based on the direct recommendation of our small group, and we could almost immediately try out the changes and give feedback. Years later, I was at another location where they were using Ad Creator (an ancient version by this time), and they were having an issue that would only be addressable by adding a feature in the software. I called the number on the back of the box, on a whim. The person on the phone could not answer my question about whether newer versions had the feature I needed. I eventually got transferred to an engineering manager, described the feature, and was told that it did not exist, but he thought it was a great idea. He asked for contact information, and in a couple of weeks we had a set of disks with a beta version of the newest software, complete with the new feature. They gave me a new license and everything (the existing software was like 8 years old). The feature worked great.

Frame Technologies was very much the same sort of company, before Adobe consumed them, and I had similar experiences with them. I have two full versions of Frame that were sent to me in order to answer questions that their tech support didn't know how to answer, and their demo would not allow me to find out.

This ability was always there, for teams willing to pursue it. I could never say enough good things about working with those guys. Looks like the Ad Creator guys are still at it, you can download betas and provide feedback right from their web page.

Prove it works in terms of ROI and... (1)

gestalt_n_pepper (991155) | more than 3 years ago | (#34109896)

only then will I take it seriously. It's different from waterfall, but the results don't look different to me, and I have yet to see a decently designed independent study comparing the two (If you have some, please send links).

Re:Prove it works in terms of ROI and... (0)

Anonymous Coward | more than 3 years ago | (#34110228)

So your new shiny product you are working on you want to show it at a trade show. Scheduled a demo...

Waterfall OH CRAP we need to rearrange everything 10 features are not there yet and do not go in for 2 months. Crash and burn right up until the demo date. The demo goes 'ok'.
'Agile' pull the 10 features forward schedule it down and figure out we only really needed 8 of those and have a demo on each all the way. The demo goes 'ok'.

Result SAME.

However, with the first one you stressed everyone out your grand plan is all shot to hell and you did Agile like things anyway. After the demo everyone feels 'burned out' and takes a few weeks off. Especially after the end where everyone was burning on weekends and 60-80 hour weeks. Your crew is probably burned out and will never 'recover' properly.

Second one no one is stressed out. Change is part of the norm. You hear things like 'yes we can hit the demo however you will not get feature X Y and Z unless you drop feature Q weeks before. You can then as a business decision decide what sells better. With waterfall you wouldnt find that out until the day before the demo and then everyone is scrambling to decide what to show. Remember Agile guys are used to fiddling the schedule around, waterfall its not part of their job that is the program managers problem. After the demo everyone keeps going as its just norm. They were not burning 60-80s (unless something is wrong in your agile process). You still have a productive crew.

One way you burned your guys out the other they keep coming in and the demo was just another delivery point.

I have no studies. But that is what I have seen in the few dozen different projects I have worked on.

Of the two Agile and Waterfall produce the same things. Agile however is better at scoping the project (cost and time) and finding out what is really needed.

The trick with *ANY* of them is to stick to the process. Do not short cut them for 'time'. That always costs you time later on. In my first example you had to shortcut the process. It totally wacked it out of shape. In my second example that type of shortcut is PART of the process.

I have also see Agile done badly (all processes can be perverted). Typically it happens if you see people getting myopic on the process with it instead of letting people work and hit their deliveries. It can also get out of control with 'meeting hell'. You need to keep them short and stay on it, as some people like to showoff and blab. Notice at no point did I say 'skip planning'. It is just as important in all processes. If you have no plan what are you doing? With Agile the plan is a bit more swag, with waterfall you are trying to figure out what you are going to do a year and a half from now (when was the last time that worked for you?). Or as one old guy I used to work with would say 'that looks good but it will not be what we deliver'. Everyone would chuckle and do it anyway.

I think.. (2, Insightful)

Anrego (830717) | more than 3 years ago | (#34109902)

Bits and pieces of agile are good. I think if you take the spirit of agile.. that is doing things because it's a good idea, not because you have a compulsive need to fill binders with documentation.. it can work well.

I like unit tests for regression testing (that is, verifying that the software still does what it used to).. but I think test driven development is more hassle and riskier than it's worth (now instead of just changing code when the requirements do a 180, you have to change code _and_ unit tests, ($cost + $time) * 2).

I like eliminating "because we need documentation" documentation.. but I think there is great value in documenting stuff that is complicated or weird. Having a binder full of "the UserAccount class represents a user account. It is comprised of a username representing.." is useless. The same goes with diagrams.

The worst is when agile is implemented as a buzzword. "We are agile! We have a binder full of documentation describing the rigid agile process we follow!" (not saying agile or processes in general shouldn't be documented, but in my opinion the whole point of agile is to be flexible).

I Pass On Any Job Asking for Agile, Scrum, XP (0)

Anonymous Coward | more than 3 years ago | (#34109910)

I'll usually pass on any job asking for agile, scrum, xp, etc. Any company asking for those 'skillz' is sure to be a nightmare to actually work in. I've been a consultant for over 20 years and every single project I've seen where they emphasize this mode of working has delivered extremely sub-standard results and I've worked in everything from banks to startups.

Look! Boxes of software falling from the sky!!!! (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34109938)

Sweet, more supposed justification for the cargo-cult bullshit that passes itself off as modern software engineering practices. "Yes, someone said that every morning we must huddle and Scrum and the Scrum must take place like this or it won't work right! If you let someone sit down it won't work right !! Now make sure you don't do anything until you've jumped up and down together and given a handy to the dude to your left or it won't work right !!!"

Where it works and where it does not. (2, Interesting)

140Mandak262Jamuna (970587) | more than 3 years ago | (#34109964)

1. It definitely tells the management what they want to hear. Timely delivery, early notification of slippage etc.

2. It at least notionally asks the management to consider resources while committing to features.

3. It allows some kinds of software project to managed better. Things like merging products when companies merge, or when porting software to a new platform etc.

4. It works when the project has a large number of people with identical or largely similar skill sets. If the project has large number of specialists (like "Frank here is the only one who can even touch the turbulence modeling code") development will be slow, agile or not. At least the management should know not to commit to too many turbulence modeling features.

5. Rally proponents broad brush all skeptics as "people not willing to change".

6 Too many Rally concepts come from manufacturing and some of the examples and analogies don't even translate correctly. Take the famous, "burnt toast" example. A company decides to burn all the slices, and then scrape off the charred crumbs to get the color desired by each customer. Supposedly Rally will toast them right in the first try saving all the efforts that go into scraping off charred crumbs. Well, in software it does not cost me any money to char a toast and scrape the crumbs. Often times it is perfectly ok to render all the pixels of each body, even if another body is going to come back and override a lot or most the pixel later. You waste time trying to predict the final pixel value to render it just once.

7 Some times it is funny to see the Rally proponents not using Rally methods to develop their presentations, not using Rally for their own internal websites! Too many of them recite from a text book or a holy book instead of using actual code/project examples.

Management Bullshit (0)

Anonymous Coward | more than 3 years ago | (#34109966)

"Agile Programming", is a trick to get programmers satisfy management lies in schedule.
Once schedule is satisfied, they look good; they move on to the next lie.
Whatever happens after that (bugs, code reuse, maintenance, adherence to standards, scalability, interoperability) is not their problem.

Scrum is *not* a replacement for good management (5, Interesting)

Gopal.V (532678) | more than 3 years ago | (#34109996)

I appreciate good management. I can live with no management, but I can't handle bad management.

SCRUM has sort of become a device for a manager to avoid managing. The human in the picture is replaced with a sprint chart and backlog tracker. It lets bad managers get by, while good managers are really thrown out of the picture.

I hated scrum in my old job. But the new job just throws out a list of features to implement, ranks it and throws it at one of us. There are no punishments for missing a day, no tracker to guilt-trip you and most importantly, the stand-up meetings are just before lunch. And mostly, serves to keep our communication channels open across the team.

I hated the time-keeping TPS report style scrum, but I'm cool with the new approach. I love the idea of sprints and taking a week out of a month to hammer something out. But this system only works with motivated teams with a fair scrum-master.

But I repeat, it is not a replacement for good management. It is as good as a way of letting me manage my tasks,but please (for the love of God, please) do not use it to manage me.

Re:Scrum is *not* a replacement for good managemen (1)

jfanning (35979) | more than 3 years ago | (#34110560)

Still not quite SCRUM (and I have done a scrum-masters course).

The goal of agile is to deliver the greatest benefit to the customer. Their representative in your team is the product owner. They don't just "throw the requirements at you". They should be making a backlog of implementable features (user stories) initially ranked by priority. You are then supposed to be estimating the complexity of those in order for the product owner to decide which is the most important given the resources and difficulty (this is a periodic backlog grooming session).

At the start of each sprint you select some stories and once you have estimated the tasks and effort for those stories you, as a team, commit to delivering those features. The daily standup meetings are for you to share you progress with each other (and update the burn-down chart). Peer pressure among the team is what gives the guilt-trip if you miss a day. The burn-down chart is what gives the product owner the state of the current sprint.

SCRUM has a very strict process. It is very light, but it still has rules and roles to follow. Anyone who tells you otherwise doesn't know what they are doing.

And there is no such thing as a "fair scrum master". The scrum masters role is just to assist the team to organize itself and keep the wolves away. They are not your boss.

Those are not agile offshoot at all (0)

Anonymous Coward | more than 3 years ago | (#34110016)

They all existed before the agile manifesto was written.

Scrum was described and named like this in a 1995 (https://secure.wikimedia.org/wikipedia/en/wiki/Scrum_%28development%29).
Books on Extreme Programming were written in 1999 (https://secure.wikimedia.org/wikipedia/en/wiki/Extreme_programming).
Kanban was used in the 1950s (https://secure.wikimedia.org/wikipedia/en/wiki/Kanban).

Get your history straight.

Paired programming might get you cut! (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34110048)

I post anonymously for a reason. But the next person that decides they want to sit down and "pair program" with me might just get stabbed. Yay almost 1/2 the productivity!!! 1 person sitting the other thinking:

- You smell.
- God I can't type while someone watches.
- Fucking sip that coffee one more time bitch!!
- I have to fart.
- I don't want to hear about your kids.

and the biggest..

- Touch my screen one more time!!! daaare you. :-(

I swear, the ones that are the most interested in this programming paradigm feature are the ones that can't code and want to feel part of the process while still acting in their typical ineffective fashion all the while flying under the radar.

Re:Paired programming might get you cut! (1)

indeterminator (1829904) | more than 3 years ago | (#34110400)

- Touch my screen one more time!!! daaare you. :-(

Keep a pencil nearby. Explain that you don't enjoy fingerprints on your screen the first time someone does it. The next time he tries to finger the screen, slap that finger with a pencil.

You'll find out most people are quick learners.

Re:Paired programming might get you cut! (1)

wrook (134116) | more than 3 years ago | (#34110476)

I don't want to pair program with you either. See, we're all happy :-)

Some people can't pair program. Sometimes they are intimidated by having someone seeing what they are doing. Sometimes they don't understand how to do it effectively and are so caught up in their preconceived notions that it is impossible to teach them. Sometimes they are just nasty people that nobody wants to work with.

When I ran teams with pair programming I never forced people to do it. But our shop had a strict policy of no code ownership. You took the top story on the list no matter what area it was in. Our stories took on average 1-2 days (which is important when your iterations are 2 weeks long or less). It doesn't give you a lot of time to get up to speed especially when you refuse help from others. Habitual solo programmers were usually late and their code didn't fit with the others.

I know lack of communication and a desire to hide in your fortress of impenetrable code is cool in programming circles, but it does tend to lead to the degradation of the code base. Very occasionally there was a guy who just plain worked better on his own. Everybody is different. But in my experience, the ones who ran away to code by themselves every day were the guys that weren't worth having.

Maybe your shop is different. Maybe...

Re:Paired programming might get you cut! (1)

rob_osx (851996) | more than 3 years ago | (#34110520)

I wholeheartedly agree! I tend to find new college grads want to pair up and code together. What's that about?!? It's not like they produce more code sitting hip to hip. When one of them sat down to "help" me, my production went down, because my thoughts kept getting interrupted by, "you need to do this..." "place a brace over there..." etc. I enjoy teaching newbies, but there is a time for training, and a time for me to get my work done. I don't like someone else looking at my screen, thinking and TALKING about the small piece of code, while I'm busy thinking about the big picture design and API.

Agile can work ... (2, Insightful)

tgd (2822) | more than 3 years ago | (#34110116)

In my experience, Agile works for two things:

1) Maintennance and support development
2) Extremely strong engineering teams

Formal processes with more up-front planning and review like waterfall allow you to turn out high quality product with average teams. You can't use the typical Agile processes with average teams and do substantial new development, but I've seen it work well enough for incremental development or support engineering/bug fixing.

A good manager will know his or her team and use the methods appropriate for success with that team, and not chase buzzwords.

In my experience, though, these days there are a LOT of bad managers.

Re:Agile can work ... (1)

wrook (134116) | more than 3 years ago | (#34110764)

I've run XP projects with average teams with great success. And my best successes were with new code. In fact I wouldn't run XP on a maintenance project initially because you usually don't have good test coverage. It takes forever to build up an environment where XP's advantages are visible. If you are trying to do it with an untrained team it's a recipe for disaster.

Now, I don't really think XP is "agile" in the way most people view "agile". XP is a highly structured discipline which requires an understanding of the practices and a commitment to following them. Usually people think "We'll use common sense and keep the process lightweight" when they think "agile". They are often thinking that they have the freedom to pick and choose what they will do at any given time. They also rely heavily on individual contributions to make success. In that way it's pretty dissimilar from XP.

On the other hand, after having run several XP projects I am struck by the idea that the ability of XP projects to get good productivity comes from what isn't done more than what is. For instance allowing (demanding?) requirements to change midstream means that we don't build functionality that isn't needed at the end. Keeping the code base as simple as possible (especially reducing code duplication) means that we don't have to build the same thing over and over again. By enforcing continuous communication through pair programming, continuous integration, acceptance testing, etc we don't build things that we don't need by accident. I could go on forever.

I once estimated that my XP team could deliver functionality 6 times as fast as the other teams in the company. And we had a completely ordinary team of 6 programmers (including 2 coops). In fact we weren't programming 6 times as fast. In many cases we were writing code slower because we had to write tests and we were doing a lot of refactoring. But we were delivering functionality that the customer wanted much, much faster. It really helps when you don't have "emergencies" that cancel your project, or cause you to completely revamp a subsystem, or whatever. We were "agile" because we could deliver quickly and we could change what we were doing quickly. But we were bloody strict about how we did it.

hrmmm (1)

Charliemopps (1157495) | more than 3 years ago | (#34110234)

What model is it when people tell you they want something, you say "I can sorta do that" a while later you give them something, they say "I guess that'll work" and you're done? Cause that's the environment I'm in. Occasionally people come to my desk to say stuff and I just yell "SCOPE CREEP" really loudly and they walk away.

Works for us (2, Informative)

Charles Dodgeson (248492) | more than 3 years ago | (#34110266)

I work in customer support for Agile Web Solutions [agile.ws], the makers of 1Password (a password management system) for Mac, Windows, iOS and Android. Agile development seems to work well for us.

I think that there are two reasons why this has worked well for us while not for others.

  • Our managers and our coders are the same people. So this isn't some management fad that is used to place unwanted demands on our coders.
  • We are not rigid in our adherence to agile principles. We plan ahead where it makes sense to.

There are drawbacks, of course. What we like to think of as "surprising and delighting" and delighting our customers usually works, but sometimes we have to take steps back from something visible which we've tried. I think that over all this still is a "win" for us and our customers, but it can sometimes be disappointing.

A perceived (but imaginary) drawback is "wasted effort". We put a great deal of effort into getting data syncing among machines and devices to work via webDAV (and in particular, MobileMe). For a variety of reasons we had to abandon that approach and go with Dropbox (with which we are very very happy). To some this might seem like wasted effort, switching to a different approach after a great deal of effort has gone into the first one. But in fact, agile principles in this case simply mean that we don't fall victim to the sunk cost bias [wikipedia.org].

long live documentation (0)

Anonymous Coward | more than 3 years ago | (#34110286)

i find that agile is used alot as an excuse to just go ahead and code. real agile, and test driven development is hard so most agile teams i have worked with have just used the word agile to skip the stuff they dont like (documentation) and go strait to coding. this leaves you with out important pieces that you are going to need later a year down the road when you want to add features, but everyone forgot were they left off. real requirements and documentation are important, but time consuming. there is reason why they have survived for this long and people still use them today.

As compared to other programming techniques? (1)

khchung (462899) | more than 3 years ago | (#34110306)

How much did Object Oriented Programming deliver on its first decade? How pervasive it is now?

If nothing else, just considering the promotion of good practices like unit tests and refactoring - look at JUnit and all the refactoring functions in Eclipse, I would say Agile Programming has already delivered a lot of value to programming.

It probably won't be replacing waterfall for a long long while, but considering that almost no development house really follows waterfall (anyone really has a complete set of requirements before they start development?), that's not really a meaningful metric.

Yes (1)

nurbles (801091) | more than 3 years ago | (#34110314)

Agile programming works when performed by agile minds. Not all programmers are able to adapt to constantly changing requirements, but some are and they are the ones who succeed with agile programming.

Re:Yes (1)

mrjb (547783) | more than 3 years ago | (#34110686)

Not all programmers are able to adapt to constantly changing requirements, but some are and they are the ones who succeed with agile programming.

I bet those programmers would typically be the ones that get their Information Analysis right from the start. This allows systems to be flexible enough to change. As a result, these same programmers would be successful regardless of the presence of agile.

Likewise, there are developers that don't know how to design data structures/databases that are flexible to changes. No amount of so-called agile practices will save them, as bad data structure design *will* have a SEVERE impact on maintenance. And this maintenance will only increase as the system evolves from a quick hack into legacy software.

Worked for my previous project (1)

khr (708262) | more than 3 years ago | (#34110330)

Agile / XP worked great for the last project I was on for a few years. Before that I was on a few different ones using something approximating waterfall (small company, no named processes) but then I quit there and got on an XP project, with half the team in the U.K. and half in India (I was in India).

Overall, we developed software better and faster than anything I'd done before. I think the key to the agility was the whole team bought into it, with the business analysts doing their part to break requirements down into small enough chunks that the developers could develop them top to bottom in a single iteration. That gave them a good idea how the project was progressing and whether we, as a team, were creating software that would be usable by the end users. It was quick to change things if something was developed that ended up not being very usable (i.e. looked good with static screen designs, but sucked when actually used).

In general it worked best when the team was weighted with more senior developers than junior developers, as the senior ones had a lot more "let's get it done" attitude instead of "tell me how to do it" and "tell me what to do next".

Pair programming? Unit testing? Stand-ups? They all helped contribute, but I didn't see them as the core parts of what made the team function well. That was basically breaking down requirements into small chunks for easy changes.

Sure, it wasn't perfect, but it was a hell of a lot better than any other project I worked on before that.

Yes (1)

PmanAce (1679902) | more than 3 years ago | (#34110412)

I work for a very large video game company, and agile works for us. My team has a twin-team, one that uses 3 week iterations while ours has adapted to 1 week iterations and it works great. We release often and early thanks to various automated processes we employ, making life easier for everyone. Managers stay happy since they can actually see progress and measure team velocity which results in an actual accurate sprint/accurate planning. Planning for our iterations doesn't take that long also with smaller iteration cycles. I am happy with it.

Agile as a manifesto is a mistake. (1)

pcraven (191172) | more than 3 years ago | (#34110544)

I like agile when people use it to learn the how and why of managing software projects. It can provide a great platform to debate, discuss, and learn.

I hate agile when people use it as a manifesto or religion, assuming it works best in all aspects of all projects at all stages and with all people. And like religion, they use it as a means to gain power over those who would use reason and logic instead.

And dude, this is wrong on so many levels:

"One of my guys keeps telling me that he would like to have more specified requirements. I keep telling him we're going faster because we don't have specified requirements," Weston says. A hardcore requirements document is a "waste of time," he adds.

Agile, scrum , extreme etc , its for managers... (1)

Viol8 (599362) | more than 3 years ago | (#34110564)

...not coders. Any coder who needs one of these silly methodology to help them work properly is probably in the wrong career.
In the time I've spend in stand-ups and other waste of time situations like that - that only exist so project managers can look like
they're doing something when the directors come calling - I could have fixed half a dozen bugs.

And the idiotic names don't help as well. "Extreme" programming? Give a frigging break. Extreme programming would be trying
to fix the code to a nuclear power station when you've got 2 minutes before it goes critical, not just making frequent code
releases for customer review. Agile? Whats that, programming while holding onto a rope upside down and typing with one
hand? Scrum? Are all the coders expected to line up and push against each other out in a field?

FFS , talk about making the profession look like a load of wannabe's who don't actually do anything macho but like to
pretend they do by giving bog standard office work names from the 101-kool-adjectives book.

Agile - The fad (2, Insightful)

Aceticon (140883) | more than 3 years ago | (#34110584)

In my experience plenty of teams "do Agile" without understanding what it's supposed to achieve. People just cherry-pick and adopt well known bits of some Agile methodology or other (for example the stand-up meeting) but then don't do it properly or miss the feed-in practices that are necessary to make it work.

It's all about "Being Agile" (i.e. fashionable) instead of "Having a way of developing software that can consistently cope with fast-changing requirements minimizing wastage, chaos and cross-team overhead".

Just as an example, in the last 7 or 8 years since Agile became fashionable, having been in and out of multiple teams/companies that use Agile to a smaller or greater degree (I'm a freelancer), I have yet to see a proper Use Case which describes in a consistent and well defined way a feature that the system being designed must provide, including handling of error conditions. In fact, 9 out of 10 times, people forget to account for errors (even user errors). Use Cases are the basis for each development cycle, the point of communications with those defining the requirements and the basis for prioritization of work and yet most teams can't even get those right.

Then there's the flaws in analysing the requirements to do make sure the system has all the data that it needs (if for example one Use Case says "The user will select one value out of a list of options for field X" you need to have those options coming from somewhere, potentially ending up with a whole bunch of other Use Cases dealing with maintaining those options).

Agile doesn't solve the essential problem in IT which is a lack of understanding of the software development process, lack of preparation and lack of method - it just provides cover for those developers which do everything in an ad-hoc, reactive way and will then excuse themselves as being "Agile".

There are simply not enough people around that try to understand the process by which people create a software system or application from a "not so well defined set of needs from the users" but lots of people focusing on the quasi-aestetic details of some language or other - too many people asking "How?" not enough asking "Why?"

I'm a tech writer and ... (0)

Anonymous Coward | more than 3 years ago | (#34110638)

I actually refuse to work on Agile/Scrum projects.


In my experience, and hey, maybe it's just me, but I never would work harder at producing less at worse quality then when on an Agile/Scrum project.

It's Documentation Silly (1)

mattwrock (1630159) | more than 3 years ago | (#34110684)

The problem is not Agile versus Waterfall, Its the lack of documentation early in the process and knowing the business needs during the project. It should be that management approves the project, business analysts get the business needs and create requirements, and IT reviews the requirements and builds the software. The reality is that management used to be IT, so they *KNOW* what the issue is and writes the requirements, system analysts are used in place of business analysts to write the requirements, and IT just has to "get er done!". By the way most companies aren't software houses, so why the hard deadlines? Oh yea bonuses are attached to the projects. As I deliver my project on time I get my bonus. It doesn't matter that is a feature starved,half-assed implementation that make everyones job just that more difficult.

Predictabel Comments (1)

Alistair Hutton (889794) | more than 3 years ago | (#34110732)

I haven't read the comments but I'm going to make a predicition about them:

Someone will say agile methodologies are just a collection of best practices organised together in a cohesive whole and they don't see the value in that.
Someone will say they did XP and didn't see what was so revolutionary about it, in response to questions it will turn out they didn't do the planning game, didn't do TDD and didn't pair program
Someone will obsess about a detail of an agile methodology, say stand up meetings, and use it as a strawman to attack all agile process, they'll also completely miss the point of what that detail is trying to achieve.

Agile is almost meaningless (1, Interesting)

Anonymous Coward | more than 3 years ago | (#34110776)

Agile has had the misfortune of being a buzzword that anybody can write about and sell books for. Lots of places then use it as the buzzword process that they are following when in reality the only thing that has changed is what they are calling it.

Other places genuinely try to implement it and find that by getting some things slightly wrong they cause themselves more problems than by sticking with what is familiar to them. This naturally sours everybody involved to agile.

TDD and XP are hard to get right.

However, TDD - Test Driven Development - is something that if your not doing then you probably should looking at implementing it. It raises the very valid question that if you don't know how your going to test something then how are you going to know when you've got it working. It encourages modular code, well factored code because otherwise writing the tests is going to be a pain the ass. Hint - if your finding writing your tests difficult then it probably has something to do with the design of your code, and that is why writing the test first works to improve design.

XP is even harder because it's a superset of TDD. Not only do you need to be getting TDD right but now the process also covers project management and client interaction.

In my mind, the most important part of agile, the part that makes it agile is not any of the above. XP and TDD may be good things but the essential part of Agile is the weekly retrospective where the team sits down and spends an hour on discussing what's going well, going badly or is just worrying and then comes up with ideas for how to improve what they are doing at that point in time.

The idea that the process that your team is working by is not fixed but is evolving is the most important idea of agile.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account