Become a fan of Slashdot on Facebook


Forgot your password?
Programming IT

A Decade of Agile Programming — Has It Delivered? 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."
This discussion has been archived. No new comments can be posted.

A Decade of Agile Programming — Has It Delivered?

Comments Filter:
  • by TheFakeMcCoy ( 1485631 ) on Wednesday November 03, 2010 @08:25AM (#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.
    • by MadKeithV ( 102058 ) on Wednesday November 03, 2010 @08:33AM (#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.
      • by 91degrees ( 207121 ) on Wednesday November 03, 2010 @08:40AM (#34109894) Journal
        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.
        • by MadKeithV ( 102058 ) on Wednesday November 03, 2010 @08:48AM (#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."

          • by Jurily ( 900488 ) <> on Wednesday November 03, 2010 @09:11AM (#34110162)

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

          • by gutnor ( 872759 ) on Wednesday November 03, 2010 @09:28AM (#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: (Score:3, Interesting)

              by Thuktun ( 221615 )

              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

              If you constantly take wrongs turns, maybe you need a better driver. If you can't decide where you want to go, nothing can give you directions on how to get there. None of this relates to the effectiveness of the GPS device.

              Translating this back out of the car analogy is left as an exercise to the reader.

              • Re: (Score:3, Insightful)

                by AmiMoJo ( 196126 )

                Straining the analogy to the limits you can mitigate a changing destination if you plan your route well. Most changes will not be of the "make a legal U-turn" variety, but rather "let's go to that other shop/restaurant in the same city." If you planned your route well and stick to major roads like motorways then these changes can be incorporated without massively disrupting the journey.

                In programming terms that means building in flexibility where possible, normalising your databases and so on. If you are wr

        • by Eraesr ( 1629799 )
          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.
          • 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.

            Considering the developers are rarely the ones setting requirements, I don't see how you can say this. Even if you ask for a specific set of requirements, the actual end users' requirements may change during the time that it takes to write the app.

            For example my current job is to replace a bunch of spreadsheets with a web app to keep track of various contracts that our sales team are working on, but they have several times added in some new sections to the spreadsheets which I then have to duplicate in the

      • by JLangbridge ( 1613103 ) on Wednesday November 03, 2010 @08:53AM (#34110012) Homepage
        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.
        • by iangoldby ( 552781 ) on Wednesday November 03, 2010 @09:13AM (#34110182) Homepage

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

          • by elrous0 ( 869638 ) * on Wednesday November 03, 2010 @09:38AM (#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: (Score:3, Insightful)

            by Anonymous Coward

            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 mont

          • by blair1q ( 305137 ) on Wednesday November 03, 2010 @03:34PM (#34115876) Journal

            Well, there's a consistency there, then.

            One of the basic tenets of Agile is that you don't use inexperienced people.

            Much of the agility comes from the fact that your team consists of pros who don't have to hack so much as lay down code and keep going.

            If you give someone a task for which they aren't trained, you're shoving logs under the bogies of your train. The whole thing will stop, but not all at once, and the spot where it starts stopping will be the least happy about it.

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

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

        • by jfanning ( 35979 ) on Wednesday November 03, 2010 @09:34AM (#34110414) Homepage

          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.

        • Geez, they weren't particularly agile. I feel for you. :/

          I might not know much about Agile methodology, but I do know one needs an agile approach.
      • by dkleinsc ( 563838 ) on Wednesday November 03, 2010 @08:57AM (#34110056) Homepage

        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: (Score:2, Interesting)

        by Anonymous Coward

        +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

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          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.

        • Re: (Score:3, Interesting)

          by qwijibo ( 101731 )

          The reason it looks like magic is because it requires at least one person who Truly Gets It. It's easy to get business people to buy flash, because they cannot measure substance, nor can they differentiate between skill and luck with past experience.

          For Agile methods to work, you need at least one person who sees the whole big picture, and given enough time and/or other good people to work with, could implement everything from scratch. Once you have that person and a commitment to make the project work, y

      • by SmallFurryCreature ( 593017 ) on Wednesday November 03, 2010 @09:31AM (#34110376) Journal

        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.

        • Just to make the point that while there is no silver bullet you can get slight improvements.
          Higher level languages help with complex tasks but in practice the complexity of the tasks just gets scaled up to the maximum possible, picking the right language for the job can mean the difference between development hell and a merely hard project.
          Good planning and good organisation with some expereienced project managers probably has even more effect.

          The thing is that no matter the improvements development will r

        • In a training document I'm writing, I have a footnote along the lines of: "using any sort of automatically generated code is bad practice". You get mediocre results - maybe better than what a poor programmer would create on his/her own. However, the good programmers write all their own code. In the end, the bit of time they would save using a framework would be more than lost fighting with and fixing the results. And most likely they use abstraction, so that they can easily re-use large portions of their co

        • Re: (Score:3, Funny)

          by CarpetShark ( 865376 )

          "getting the requirements out of a user is like sucking cock"

          Your users must be a lot more fun than ours.

        • by Xest ( 935314 ) on Wednesday November 03, 2010 @11:46AM (#34112682)

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

          • by SmallFurryCreature ( 593017 ) on Wednesday November 03, 2010 @12:12PM (#34113140) Journal
            But you knew during all your development that you had to switch databases. AND you didn't have to worry about speed. Often you don't have that luxury.

            While you have a valid example of why database abstraction CAN be useful, you have not actually proven that it must be done every time just in case you might switch sometime in the future.

            Seen to many developments throw speed out of the door for a migration that will never happen.

        • Re: (Score:3, Insightful)

          by e4g4 ( 533831 )

          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.

          There are no silver bullets, but there are lots of wheels out there - they don't need to be reinvented for every project. Question: How smart do you think it is to hire a coder who hates to use frameworks, and loves to roll his own for every new project?

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

    • by Superken7 ( 893292 ) on Wednesday November 03, 2010 @08:50AM (#34109976) Journal

      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.

      • by Entrope ( 68843 ) on Wednesday November 03, 2010 @08:56AM (#34110044) Homepage

        Agile principle #2 (from []): "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.

        • I think maybe what some people are misunderstanding is that there is cost, explained to the customer as part of the process, for such changes. You see sometimes you absolutely need to change the requirements late in the development process; otherwise you finish the project but it doesn't do what the customer needs it to. Seriously, if you have a project and right near the end the customer tells you they were purchased and by fiat need to switch the networking protocol on which the app relies to comply with

        • Re: (Score:3, Interesting)

          by rwven ( 663186 )

          It all depends on the level of change as well. Agile, by design, is supposed to have constant product demos throughout the development process. The customers should always know what is being built, and the changes should come in little bits after each demo instead of a massive turnaround near the end.

          I've done nothing but proper agile for years now, and even when it's done perfectly a massive about face on a project will kill pretty much anything....agile or not.

          Agile tends to avoid game-changing changes at

    • Re: (Score:3, Insightful)

      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

    • so they wiped out the project team.

      Wow, that's a little harsh. ;-)

    • Re: (Score:2, Interesting)

      by mkawick ( 190367 )

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

  • Captain Obvious (Score:4, Insightful)

    by MadKeithV ( 102058 ) on Wednesday November 03, 2010 @08:28AM (#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.
  • by CyberDong ( 137370 ) on Wednesday November 03, 2010 @08:31AM (#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.

  • Why don't they ask (Score:4, Insightful)

    by JamesP ( 688957 ) on Wednesday November 03, 2010 @08:36AM (#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...

    • by Shados ( 741919 )

      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.

    • by elrous0 ( 869638 ) *

      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 ha

    • by arth1 ( 260657 )

      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 bee

  • by netsavior ( 627338 ) on Wednesday November 03, 2010 @08:37AM (#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.
  • 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).

  • I think.. (Score:3, Insightful)

    by Anrego ( 830717 ) * on Wednesday November 03, 2010 @08:41AM (#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).

    • Re: (Score:3, Insightful)

      by mcgrew ( 92797 ) *

      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.

      Documentation is like code -- it doesn't work unless you do it right. An example is kubuntu's documentation. Pages and pages about how to customise the K menu, but not a single word about how to start the editing program. I had to have someone on slashdot to tell me you left click the K menu.


    • There's a picture on one of our cubical walls called something like the "sine wave of test automation" (can't find an online copy ATM). You start with heaps of manual testing, automate it and become more productive. But then a small change breaks heaps of tests, you end up with an aversion to change because of all the tests that would break.

      The best documentation for what the application currently does, is the source code. Of course not everyone can read it. If you find yourself answering the same question

    • unittests also serve as documentation - show how stuff is used.
  • by 140Mandak262Jamuna ( 970587 ) on Wednesday November 03, 2010 @08:49AM (#34109964) Journal
    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.

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

      One should note that for pair programming environments and most Agile methodologies, this should never happen because there should have been many different people that developed each part of the code. If only one guy knows how something works, you probably did not follow an Agile development method.

  • by Gopal.V ( 532678 ) on Wednesday November 03, 2010 @08:53AM (#34109996) Homepage Journal

    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.

    • by jfanning ( 35979 )

      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 (thi

    • "SCRUM has sort of become a device for a manager to avoid managing."

      Bingo. Yet another buzzword system to allow marginally competent middle managers to report something to marginally competent upper-middle managers. For good teams, with good managers, you will succeed with - or without - SCRUM. For poor teams and/or poor managers, it doesn't keep your project from sinking, but does give you the good of moving the deck chairs around.

  • Agile can work ... (Score:3, Insightful)

    by tgd ( 2822 ) on Wednesday November 03, 2010 @09:07AM (#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.

    • by wrook ( 134116 )

      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 under

  • 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 (Score:3, Informative)

    by Charles Dodgeson ( 248492 ) <> on Wednesday November 03, 2010 @09:22AM (#34110266) Homepage Journal

    I work in customer support for Agile Web Solutions [], 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 [].

  • 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

  • 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

  • ...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 s

    • Re: (Score:2, Informative)

      I think that you spent your time in a wrong kind of stand-ups.

      You see, if you have up to 10 people on your team, and each one gives precise answers to those three scrum questions, you are gonna spend no more than 15 minutes in that meeting. After that, you know what all other people are busy with, so should any issue pop up, you know who to ask. This is less time to spend than if each one were asking another one by one.

      Scrum done wrong: 1) a half an hour stand up; 2) scrum done in teams with more than 10 pe

      • by Viol8 ( 599362 )

        Anyone who works in a team of less than about 20 people already knows what the other team members are doing generally , and they'll know specifically if they work with them on a day to day basis. You don't need a meeting every day to find this information out.

        "This is less time to spend than if each one were asking another one by one."

        Or you could just ask the team in one go. I don't know where you work but where I work I sit within 20 foot of my entire team.

  • Agile - The fad (Score:3, Insightful)

    by Aceticon ( 140883 ) on Wednesday November 03, 2010 @09:49AM (#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?"

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

      I do some work in an Agile shop and usability is a huge concern. It is very often that we tell the customer "we don't know what this should do, schedule our usability experts to go conduct some interviews with users and find out". In some cases they do just that. In others they decide it is too expensive so they just declare what they just take a guess at what users need and we build it. But you can be sure the customer knows they're making a tradeoff and reducing quality for the reduced cost.

  • 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

  • by hsoftdev17 ( 1701106 ) on Wednesday November 03, 2010 @10:33AM (#34111312)
    Absolutely not. Never before have I experienced a method of programming that can be more aggressively mismanaged than agile. Many developers think agile is a means to produce better code, faster, and with better specs. Most management sees it as an excuse to provide no specs, to change their minds on what they want every 5 minutes, and call all of that "agile" development. These things ruin the name of agile development and provide such a bad experience for anyone stuck working with it, that it simply can't have managed to do anything but fail utterly to deliver. People have been fired over misinterpretations of what agile is. Others have left because of a misinterpretation that was shoved down their throats by management. And that's just all where I work... Perhaps it's better in other places, but I've never heard a story of it going well.
  • by Junta ( 36770 )

    Issues around software development are, in my experience, about the people, not about the process so much.

    Give a group any process and it will be contorted in whatever way required to make it act the way they want, but with new buzzword compliance. Frequently with misguided attempts to adopt one hard line rule or another without really appreciating the meaning of it and just ending up with arbitrary stupid things.

    The best projects I've seen are ones that didn't fret overmuch about being able to rubber-stam

  • My experience is that quite a few software development organizations cover up a what is essentially a "death march" by using agile terminology. They don't follow any recognized agile development methodology nor is the effort a proper waterfall development. There is just enough agile terminology to make it sound like an agile development. The effort usually fails and of course management would rather blame the methodology or the developers rather than admit they couldn't do what they said they would.


  • No; I do - let's say try to do Agile and I'm a CSM, since its inception and on different locations and cultures; in the last 5 years, when I did it mostly in North America I never seen it succeeding; mostly the reason was hijacking the Agile and masquerading waterfall or chaotic processes under the Agile terminology/dictionary. As always, human greed and immorality overtook the basics of the Agile manifesto and lead to disastrous mini-waterfalling with dire consequences as accumulation of huge technical deb
  • by cdrguru ( 88047 ) on Wednesday November 03, 2010 @11:23AM (#34112186) Homepage

    Yes, anyone adhereing to a strict waterfall model today is probably being silly.

    If you are doing internal-only development you can get away with constant change. When there are real outside users there is real, external documentation and marketing materials. There is a real date for a product launch, and things have to be stable for it.

    Marketing materials need to be prepared and printed. If they take a bunch of screen shots and sent stuff to the printer Marketing will not be happy with the announcement that those are the "old" screens and the "new" ones are much better now.

    An really funny scenario is some marketing type is going to give a demo of the product to some big customers (prospects, really) and no longer understands how the "new" product works after the latest round of changes.

    Yes, I have seen that happen. The result is there are some new developers working on the product and the launch is delayed. Sometimes for a year. Sometimes the original developers have a hard time finding a new job.

    Change is good, stability is good. The intersection of these two is really great. Anything that is too far away from the intersection tends to be bad, especially at the outer edges of either.

When you are working hard, get up and retch every so often.