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

10 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 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.
    5. 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.

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

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

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