Slashdot Mirror

← Back to Stories (view on slashdot.org)

A Decade of Agile Programming — Has It Delivered?

Posted by timothy on from the tell-you-at-the-next-scrum dept.

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

21 of 395 comments (clear)

  1. Maybe they did it wrong... by TheFakeMcCoy · · Score: 5, Interesting

    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.

    1. Re:Maybe they did it wrong... by MadKeithV · · Score: 5, Insightful

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

    2. Re:Maybe they did it wrong... by 91degrees · · Score: 5, Insightful

      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.

    3. Re:Maybe they did it wrong... by MadKeithV · · Score: 5, Insightful

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

    4. Re:Maybe they did it wrong... by Superken7 · · Score: 4, Interesting

      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.

    5. Re:Maybe they did it wrong... by JLangbridge · · Score: 5, Interesting

      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.

      --
      The urgent is done, the impossible is on the way, for miracles expect a small delay.
    6. Re:Maybe they did it wrong... by Entrope · · Score: 5, Insightful

      Agile principle #2 (from http://agilemanifesto.org/principles.html): "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.

    7. Re:Maybe they did it wrong... by dkleinsc · · Score: 4, Informative

      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.

      --
      I am officially gone from /. Long live http://www.soylentnews.com/
    8. Re:Maybe they did it wrong... by Jurily · · Score: 4, Funny

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

    9. Re:Maybe they did it wrong... by iangoldby · · Score: 4, Insightful

      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'.

    10. Re:Maybe they did it wrong... by gutnor · · Score: 5, Insightful
      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.

    11. Re:Maybe they did it wrong... by elrous0 · · Score: 5, Insightful

      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.

      --
      SJW: Someone who has run out of real oppression, and has to fake it.
    12. Re:Maybe they did it wrong... by Barlo_Mung_42 · · Score: 4, Informative

      No true Scotsman fallacy:
      http://en.wikipedia.org/wiki/No_true_Scotsman

  2. Captain Obvious by MadKeithV · · Score: 4, Insightful

    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.

  3. Re:A point of view by drewhk · · Score: 4, Insightful

    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.

  4. "Agile", no -- "agile", yes by CyberDong · · Score: 4, Interesting

    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.

    1. Re:"Agile", no -- "agile", yes by drewhk · · Score: 4, Insightful

      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?

  5. First decade? Not likely by netsavior · · Score: 5, Interesting

    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.

  6. Scrum is *not* a replacement for good management by Gopal.V · · Score: 5, Interesting

    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.

    --
    Quidquid latine dictum sit, altum videtur
  7. Indeed, THERE IS NO SILVER BULLET by SmallFurryCreature · · Score: 4, Insightful

    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.

    --

    MMO Quests are like orgasms:

    You may solo them, I prefer them in a group.

    1. Re:Indeed, THERE IS NO SILVER BULLET by Xest · · Score: 4, Interesting

      "Question: When have you EVER switched database on a web application"

      Earlier this year, because expenditure needed to be kept to a minimum during the recession starting in 2008 so the initial build used MySQL with the goal of moving to MS SQL Server when profit forecasts were a lot safer and more stable, which they were (and still are!) earlier this year.

      "HOW easy was it?"

      Effortless, precisely because I'd used database abstraction. It was done and tested in around 20 minutes thanks to the well written unit tests accompanying our abstraction layer demonstrating that the switch worked as required.

      "Is there ANYONE out there who only use pure SQL that is 100% understood by all databases the same?"

      Yes, I did, for this particular project, for precisely this reason.

      "Then go stand in the corner, because your code lacks any optimization."

      That's a rather broad statement, there's plenty of optimisation you can do even with just standard SQL, whilst you may lose some additional DBMS specific optimisation features, you may still be able to reach suitable levels of optimisation with ease-

      "Real developers optimize their code for the specific environment they are using."

      What was that about magic solutions? Optimisation is something you prioritise like everything else. If your application runs at no more than 10% CPU usage and the load isn't going to increase because the userbase is fairly static and this provides plenty of room for increases your application would be expected to see then it's far better to ensure your code is maintainble, than it is to sacrifice maintainability for unnecessary and time consuming optimisation and save the company money by focussing on the priority that best suits the task at hand. "Real developers" should recognise that they simply don't need to optimise at all if in the specific case they are considering it is an unnecesary task.

      To use a typical Slashdot car analogy, even the car industry gets this, this is why not every car is in a fight to be the fastest in the world, car manufacturers understand that when a lot of people are limited to a set speed limit anyway, there's no point optimising the car beyond that point and ensuring other things, like having enough room for children to sit in the back, are a priority. The speed of the car just has to be good enough to fulfil the end user's needs not be able to reach speeds which the vehicle will never ever be pushed to in practice at an unnecessary and possibly unaffordable level of cost to the end user.

      I actually agree with pretty much everything else you said, but your viewpoint seems a bit contradictory- on one hand you seem to be arguing the basic principle that it's all about using the right tool for the job, but on the other you then seem to be arguing against ways of doing things that are perfectly valid in some scenarios. If you hadn't taken a pop at database abstraction and insisted that all "real programmers" optimise their code then I find little fault with everything else you said. As it stands it sounds like you're saying "You should use the best tool for the job, except in a few cases where I don't like that tool". Sometimes database abstraction has value, sometimes optimisation doesn't.