back to article Don't go chasing waterfalls, please stick... Hang on. They're back

Since the publication of the Agile Manifesto, there’s been a steady acceptance that Agile is the way to go when it comes to software development. The old waterfall method was seen as something rather quaint and old-fashioned, the equivalent of hanging onto your vinyl LPs when the rest of the world was downloading onto their …

Page:

  1. Wilco
    Holmes

    Oldies can still function

    Can I just say that I am in my 50s and I'm doing Agile Scala development on Spark.

    1. Anonymous Coward
      Anonymous Coward

      Re: Oldies can still function

      May I interest you in a little Haskell, you like quite the gentleman/woman able to appreciate elegance...

  2. IrishFella

    cambam boards [sic]

    We have them everywhere

    1. Anonymous Coward
      Anonymous Coward

      Re: cambam boards [sic]

      Yeah Lizzy Hotsy was pretty good in the last one...

    2. Tim 11

      Re: cambam boards [sic]

      Normally I would report a genuine typo using the "tips and corrections" link. Unfortunately this mistake would seem to indicate that the author of the article is just playing buzzword bingo and has no idea what he's talking about.

    3. Doctor Syntax Silver badge

      Re: cambam boards [sic]

      Isn't that the stuff you nail to a wooden framework and then skim over with finishing plaster?

      1. Gene Cash Silver badge

        Re: cambam boards [sic]

        https://twitter.com/sadoperator/status/707387215819591684

        To better reflect our workflow the kan ban board now only has two columns:

        - Stalled

        - On Fire

  3. Destroy All Monsters Silver badge
    Holmes

    Organizational microsoervices?

    I have seen a COBOL guy in his 50s and he was a non-talking curmudgeon, practically impossible to work with, a danger to the company.

    Maybe the "guys in their 50s doing COBOL" who quit when hearing "agile" were like that, in which case they deserve the job market they will encounter. Otherwise there should be ways to accommodate that particular development section which more likely wants some steadiness instead crazy youngsters re-discovering sexthe ropes making them confused and angry. Put a communicating "project manager" in front of their door to perform proper I/O.

    project managers can become a rare breed and can become scrum-masters

    The scrum master is just the scrum master. The propels the scrum cycle. The project manager is the guy on the phone, in contact with the guy with the money and doing the Gantt chart. Both job descriptions are not comparable at all. Once project managers think they are scrum masters or the converse, problems beckon.

    JP Morgan Australia senior managers have installed cambam boards for themselves.

    I think this is written "Kanban". It is a nice communication device, especially to give some visual input to PHB dropping by to "ask for a little project on the side", but it's orthogonal to agilism...

    1. LionelB Silver badge

      Re: Organizational microsoervices?

      He, he. I worked for a global telecoms company (now mercifully defunct) back in the 90's. The entire call routing software infrastructure was maintained by one guy. He was far from curmudgeonly (he was a very affable middle-aged Dutch hippie), but he had the management by the balls, and by god did he know it. He was on an extremely lucrative contract and had basically lived in 5 star hotels around the world for the past decade - strange life, but it seemed to suit him.

      At the time I was keen on getting in on some of that myself. Of course he wasn't having any of it, but I eventually managed (with no backup from management, who were complete pussies) to get my hands on the source - a huge C/Unix real-time system, completely undocumented and void of a single comment. Turns out that the guy's weak point was that he was such an elegant programmer - the code was beautifully structured - that I was starting to get on top of it. Then the company imploded, I was out of a job and your man (I'm guessing) retired in style.

      1. Tom 38

        Re: Organizational microsoervices?

        MCI/Worldcom by any chance?

        1. LionelB Silver badge

          Re: Organizational microsoervices?

          No... I'd rather not name and shame...

    2. admiraljkb
      Coat

      Re: Organizational microsoervices?

      "Maybe the "guys in their 50s doing COBOL" who quit when hearing "agile" were like that, in which case they deserve the job market they will encounter"

      @DAM - actually - the COBOL guys have been making BANK for a while (since before Y2K), so at this point unless they did something foolish with their money, they can just retire and be done with it. If they quit when they heard Agile, I suspect they could have left at any time and were just there for "fun". Let that be a lesson for anyone with legacy systems where the only folks that can *properly* develop on it are in their 50's. Its time to do a crash program migration (or get fresh blood that likes COBOL ha), since many folks in their 50's can just up and walk at any time if they so choose, and those two did so choose. I've seen well positioned guys in their 40's do that as well.

  4. Potemkine Silver badge

    Church of Agile and Evangelists

    When a metholodogy becomes a religion, then something is rotten in the State of Denmark.

    1. Blank Reg

      Re: Church of Agile and Evangelists

      Zealots are almost always wrong. They get so narrow minded that they fail to consider alternate viewpoints and dismiss any criticisms,

      Sure Agile can be great,just don't force it's use where it doesn't belong. And that's not just because of culture. The nature of certain projects just may not work well with Agile, or at least not pure Agile as the true Agile nuts would have you believe is the only path to software enlightenment.

      1. admiraljkb

        Re: Church of Agile and Evangelists

        I follow the religion of Pragmatism, pragmatically of course.

    2. allthecoolshortnamesweretaken

      Re: Church of Agile and Evangelists

      Amen to that, brother!

    3. Anonymous Coward
      Anonymous Coward

      Re: Church of Agile and Evangelists

      The Church of Agile is so welcoming and all encompassing that anyone, in any role, can join and become a believer and even an expert without any real credentials. Talk the talk with supreme confidence and enthusiasm and it doesn't matter whether you are right or wrong. Agile in marketing - who needs a marketing plan, just use Agile. Agile in upper management - change your company culture and reap the benefits ( with no ROI proof mind you). Everything can be Agilized. It's your destiny, if you will only beeeelieeeeeve.

      I walked out of that sermon and haven't been back to that realm for a while. Certified Scrum Master from 2006.

      Love the cambam. Seems like El Reg is hiring people with fewer clues as time goes on. Unless, of course, they are actually brilliant and the writers/editors are inserting typos in key places so us commenters will call them on it ( TB, MB, PB, millions, billions, etc that the writers and editors can't seem to get a handle on) and that way, they can tell the advertisers that they have an active comments environment with an average of X number of posts per article, so they are assured to make people talk about their products if they write an article about them and throw some advertising dollars their way. Genius. Must be Agile.

    4. Derek Clarke

      Re: Church of Agile and Evangelists

      Hear hear brother!!

  5. caffeine addict

    Agile seems like Communism - it would be the perfect system if only we had perfect people.

    In reality, Agile seems to all too frequently result in developers getting jerked around by people who don't know what they want, resulting in code that's over budget, underspec, and buggy. I always know when I've had enough of a project - I start wishing we'd had a tightly nailed down waterfall spec.

    1. gv

      When most coding is either off-shored or handed off to junior bods, it's not surprising project delivery objectives are not met or are late. Methodologies or the latest buzzwords are not going to fix that. There's a reason why open source development is inherently better and less buggy.

      1. Sgt_Oddball

        Except...

        When no-body bothers to fully peer review the software, or the lone developer pulls the code from a repository because everyone's messing him about, or hell.. even just gets downright abusive, then I can't help but feel compelled to disagree.

        There's also how many projects using GNU licences that don't reciprocate or make said code closed source, or just get plain lazy and leave default configurations/plugins that are open to abuse.

        I'm not saying closed source is inherently better, or that smaller teams work better but the reality is much more complex.

        1. gv

          Re: Except...

          "I'm not saying closed source is inherently better, or that smaller teams work better but the reality is much more complex."

          I'm sure the same types of things go on in any non-trivial commercial project -- it's just you don't get to hear the juicy details.

          1. allthecoolshortnamesweretaken

            Re: Except...

            I'm sure the same types of things go on in any non-trivial commercial project -- it's just you don't get to hear the juicy details.

            You betcha. Hint: ever been involved in a big building project?

        2. Tom 38

          Re: Except...

          When no-body bothers to fully peer review the software, or the lone developer pulls the code from a repository because everyone's messing him about, or hell.. even just gets downright abusive, then I can't help but feel compelled to disagree.

          The biggest "except" is that none of your three listed projects (OpenSSL, lpad and Linux) are remotely developed using the Agile methodology.

          1. Sgt_Oddball

            Re: Except...

            True, but if you read the comment I responded to, that had nothing to do with agile development either. Just the bashing of closed source projects.

            1. gv

              Re: Except...

              I wasn't "bashing closed source projects" - just making the point that open source software development generally leads to better code.

    2. breakfast Silver badge
      Boffin

      Agile is pretty great in certain environments - if I was in a start-up combining design and development on a growing product that needed to have it usable by users as soon as possible and needed it to stay usable by users as the product grew and added new features, I would probably be looking at a full Agile methodology.

      That isn't where most businesses are, though. It might look cool because it is what start-ups do, but those requirements are quite different from what most development work seems to be about, which is getting a project to a specific "finished" state within a timespan and a budget that makes it viable for the organisation who are sponsoring it. If you are doing Agile by the book, then you cannot offer any guide for when "finished" is likely to happen and consequently how much it is likely to cost.

      Also it seems as though businesses often want to see results fast, which means the first thing they skimp on is the requirements gathering. That is super-important regardless of development methodology, but most of the time they seem determined to get code working from day one rather than figuring out what code would actually be helpful.

      In fact, the more I think about it the more I think that if you can set up your starting variables correctly - a solid and well researched requirement, some prototypes and wireframes that people like, an agreement about what goes in and what doesn't from the start - then you have a fair chance of success regardless of methodology. Often you're going to end up with some kind of bastardised sprinterfall or kanbince type approach anyways.

      Perhaps I should sell this as "foundationalism" or somesuch and set up as a consultant...

    3. veti Silver badge

      Yep, and waterfall would be great if only we could have a tightly nailed down and comprehensive spec.

      Sadly, not one developer in a hundred - no, make that one in ten thousand - has ever seen one of those, or would recognise it if they did. So the other 9,999 will end up delivering shit.

  6. Aristotles slow and dimwitted horse

    Elmer FUD!!!

    Yes the answer is always hybrid. But of course it depends on the scope and scale of the project. By all means use an Agile sprint method or scrum organisation structure to deliver key and core work packages, but on large multi stage development projects and programmes, these need to sit under a waterfall stage driven structure because it gives the Sponsors, Programme board, PEs and other steering group rerpresentatives the comfort that the programme has a clearly defined structure and approach, and because looking at a large project in high level stages, and being able to track key milestones against those stages is how it works for those seniors whose necks are on the blocks to influence and deliver.

    Let the PM manage the project, and let the scrum-master or whichever unfortunate has been nominated to make it work, manage the work package driven sprints. All of which sits beneath the key stage plan.

    The guy in the article claiming some mutual exclusivity of methods obviously isn't delivering change projects to the size and scale that a lot of PMs do (or maybe he just has a lumberjack shirt and a beard and makes it all up as he goes along?)

    If you have staff that treat your corporate systems as their own, and refuse to adapt to new methods - then they need to be released. You will feel some pain but in the long term that issue should have been identified, and be actively managed with a contingency plan.

    It's not rocket science. It's really really isn't.

    1. no-one in particular

      Re: Elmer FUD!!!

      > then they need to be released

      Oh how I loathe that kind of weasel wording.

  7. Hans Neeson-Bumpsadese Silver badge

    RE: Rocket science

    It's not rocket science. It's really really isn't.

    Rocket scientists use DevOps

    1. VinceH
      Coat

      Re: RE: Rocket science

      And if they're using hyper-converged DevOps, they're probably working on hyperspace rockets.

      Or something.

    2. kmac499

      Re: RE: Rocket science

      Rocket Science Easy F = ma

      Rocket Engineering now that's difficult. makig something that doesn't explode, melt go sideways etc.. and still lofts several tons to a pre-determined point in space

      Same with software, easy to comprehend the approach bloody hard to do it well.

      1. Anonymous Coward
        Anonymous Coward

        Rocket Science Easy F = ma

        Yes, in basic physics books, where everything is a point in an uni-dimensional world and forces are nice arrows, without atmosphere, etc. Bring it into the real world and it becomes a little more complex.

        The there's the internal physics - hypercooled propellants and their effects on materials they touch, how them and exhaust gas behave along the engine, how to make a rocket lighter but still structurally sound using new materials, and so on.

        Even firing from a cannon was complex enough one of the first computer was designed to compute more accurate firing tables....

      2. Anonymous Coward
        Anonymous Coward

        Re: RE: Rocket science

        yeah making things go "bang" is usually not that difficult.

        controlled power safely delivered in useful ways is much more challenging.

        see the history of nuclear power , rockets, various forms of transport and their power units.

  8. LHGFLICOD

    Round here.

    Agile seems to be interpreted as waterfall without the testing...

    1. Vic

      Re: Round here.

      Agile seems to be interpreted as waterfall without the testing...

      Think yourself lucky.

      Round here, Agiile seems to be interpreted as waterfall without the testing or requirements capture.

      Vic.

  9. Anonymous Coward
    Anonymous Coward

    Game of Thrones methodology?

    Sorry, we can't throw in some nude women/sex scene every time our software doesn't work. It would simplify development a lot, mostly no customers complains, I guess. Imagine an exception handler designed such a way... guess helldesk would receive calls like "I don't see any errors, how could I obtain one, please??!!"

    The bottom line is Game of Thrones is exactly designed to give "users" what they ask for. Sex and violence. Software, unluckily, can't.

    1. Hans Neeson-Bumpsadese Silver badge
      Coat

      Re: Sex and violence

      I don't know...I've been fairly brutally f***ed by badly-designed software quite a few times over the years

    2. Dan 55 Silver badge

      Re: Game of Thrones methodology?

      - A girl is not ready to become agile, but she's ready to try another development methodology...

      - A girl must wait.

      ... later...

      - A girl does not use waterfall any more. A girl uses no development methodology.

      - A girl is finally ready to become agile. A girl must drink the kool aid. If a girl really believes, there is nothing to fear.

      ... later...

      - A project was a failure.

      - A girl had doubts. A girl was not agile.

      1. Ralph B

        Re: Game of Thrones methodology?

        You really should have posted that anonymously.

        1. MonkeyCee

          Re: Game of Thrones methodology?

          It was quite clearly an AC person wearing Dan 55's face.

          All yes-men must die

      2. Ken 16 Silver badge
        Trollface

        Re: Game of Thrones methodology?

        Working blind and getting the crap beaten out of you on a daily basis? Sounds familiar

  10. Anonymous Coward
    Anonymous Coward

    In my experience, methodology is the stuff that gets in the way of work.

    There is no substitute for having a group of good developers who understand what needs to be done and then leaving them alone to get on with it.

    1. Mellipop

      You've described Scrum. Minimal ceremony, self organising team.

      1. Dagg Silver badge
        Devil

        You've described Scrum. Minimal ceremony, self organising team.

        No! Scrum IS a ceremony, it is the prayer at the altar of the church of agile

  11. John Lilburne

    No True Scotsman

    Problem is that Agile doesn't work. So Agilators profess that all failed Agile projects weren't Agile. Its a bit "No true Scotsman".

    1. zebthecat

      Re: Problem is that Agile doesn't work

      Disagree completely - I have worked in three places that did Agile well and it worked very well indeed. As far as I can tell the main thrust of the article is creect in that you really need everyone (especially the business sponsors) to buy into it too. If they don't understand the process then you might as well not bother..

      1. Justicesays

        Re: Problem is that Agile doesn't work

        So, Waterfall project fails, blame waterfall methodology, but agile project fails because "not everyone bought into agile enough?".

        Point proven I think...

      2. Dagg Silver badge
        Flame

        Re: Problem is that Agile doesn't work

        Totally disagree with your disagreement.

        Never worked in an Agile project that actually worked.

        Currently working on project, seen two attempts to deliver, now on the third and still no delivery. Agile is an excuse for having no idea how to do something and just starting and attempting to learn on the job.

        In the real world when you have a multi million dollar project with a fixed functionality, fixed time frame and fixed budget agile doesn't work.

        The agile approach is to start with an undefined idea, no requirements, stuff around for ages, waste a lot of money then deliver some flaky stuff that does something. This might be ok for a startup where the stuff delivered becomes hipster and takes off for a couple of months. But if you are a real world bricks and mortar place with real stuff to do with people and suppliers to pay then build your software using the same techniques as you would build a building, dam etc. Start with a set of solid requirements functional and NON-functional, plan it cost it then start building. At least you will have a chance of getting it built on time and on schedule.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like