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

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

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

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

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