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 …

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

    2. Vic

      Re: No True Scotsman

      Problem is that Agile doesn't work

      Agile *can* work.

      The problem is that far too many "agile" developments are simply bullshit dressed up as Agile.

      If anyone ever tell you that you don't need requirement capture - that's not Agile.

      If anyone tells you that you don't need a spec - again, not Agile.

      Documentation? Agile requires it.

      In fact, there is really only one difference between Waterfall[1] and Agile - and that is that Agile expects the spec to change during the lifetime of the project. That's it - all this bullshit about not testing or documenting are nothing whatsoever to do with Agile. But someone will still pretend it is...

      Vic.

      [1] This is not true; the original Benington paper describing the Waterfall process had feedback loops in it - meaning *real* Waterfall and *real* Agile are essentially identical. But the Waterfall process is frequently misrepresented as well...

      1. Hollerithevo

        Re: No True Scotsman

        Vic you are spot on. Both methods, if done clearly, deliver. I've seen waterfalls work well (early days), but I have also seen the team plough ahead regardless of the billowing fires of fail around them, because That's What You Do. I have also seen an Agile project fail because the team was so sure it could handle changes to the specs that they lost sight of the Great Big Deliverable.

        And I have seen every kind of project fail because project management was so dire, so disorganised, so pathetic, that finally it killed either the will to live or (in one instance) actually killed the project, mostly by spending all the money on business analysts who sliced and diced the requirements into shards.

  12. disgruntled yank Silver badge

    What happened to DevOps?

    I'm used to this sort of article explaining to me that DevOps is in fact a panacea. That is, it has more or less random anecdotes (COBOL guys quitting), sweeping unsupported assertions, and a tin ear for language.

    "There is a way that Prince can work with Agile, said the evangelist: either the Prince methodology can change or project managers can become a rare breed and can become scrum-masters,” says Harris.

    How does one become a rare breed? Refuse to reproduce? But I do like

    "drift back to Waterfall"--a staple of many cartoons, no?

    "waterfall clinging on tenaciously". S'ok, the spring thaw will take care of that.

    "show by example". (Well, OK, that is said to have been uttered by a "business guy".)

    agile antibodies in the permafrost.

    1. Anonymous Coward
      Anonymous Coward

      Re: What happened to DevOps?

      I'm not a programmer, so I just skimmed the article to see if the word "DevOps" got used.

  13. Anonymous Coward
    Anonymous Coward

    FSS. Agile? Waterfall? Fag packet? Just do what works in your organisation to get the job done.

  14. Anonymous Coward
    Anonymous Coward

    Waterfall is not the only alternate method

    We are doomed to have this stupid argument forever: Waterfall vs Agile, as if no other methods exsit. Waterfall is always put up as a strawman. There are, and have been, other methods besides Waterfall. Some are very good robust methods. As for Agile, you cannot do better than read St Bertrand's wonderul assessment.

    1. Doctor Syntax Silver badge

      Re: Waterfall is not the only alternate method

      "Waterfall is always put up as a strawman."

      For a very good reason: that's what it was invented for. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

      PHBs looked at it and thought it was a good idea.

  15. Anonymous Coward
    Anonymous Coward

    "Translation: middle management, which is like permafrost – something that’s hard to penetrate."

    A better analogy for middle management is one I heard many years ago. Just before he left - the CEO was addressing the coalface workers who were enthusiastically in tune with his ideas for the way the company should progress.

    "Middle management is a blancmange - whatever you do it just wobbles then stays the same".

  16. John Smith 19 Gold badge
    Unhappy

    "to the CICS, DB2 and COBOL applications and that’s where it all breaks down,”

    That's likely where all that twentysomething enthusiasm is going to come to a complete halt.

    It's 2016 and somewhere out there a bunch of people are writing Accounts Receivable packages.

    And at least one of them is failing.

  17. Erlang Lacod

    Methodology

    I find the best method of delivery is just get on with it. Do a proper job, be organised, put the hours in, hold people to account and get it delivered. Every PM needs a keyboard with a JFDI button and be prepared to press that button rather than dice with the death of endless detail and waste time playing methodology bingo.

  18. I am the liquor

    Why is agile hard to report on? Don't you just go to your ALM tool of choice and download the charts? It'll tell you how many story points have been done and how many are still to do; extrapolate how far down the backlog you'll get by the end of the project;show you who's working on what tasks and whether they have time to complete them before the end of the sprint; there's all sorts of reporting. My experience is that you have far better visibility of progress on agile projects than waterfall ones.

    Certainly you can improve waterfall by using some of the tools and methods developed for agile, to give yourself some of that visibility in a waterfall project. But unless the developers are actually delivering something on a regular basis, then you're still pretty much taking their word for it that everything is fine and on target.

    1. Anonymous Coward
      Anonymous Coward

      Why is agile hard to report on?

      (ignoring possible sarcasm, and adding my own :-) ).

      Let me see - because middle management found story points too confusing, so they insisted on story point is defined as a 1 hour estimate. But then not enough points were getting done, so they officially declared the sprint velocity to be 50% - you accomplish 4 story points per day. Then they decided that the "other 4 hours" (a phrase I have grown to really hate) encompasses all non-sprint work, so that has to include everything other than visible progress.

      When the main branch has code checked in that won't compile, fetching the latest source and getting it to compile and be usable on your machine is part of the other 4 hours (and yes, branches are too hard to manage, so all work occurs on the main branch - branches are reserved for prototypes). Grooming future work is part of the other 4 hours. Your machine needs to be re-imaged because of buggy IT sw (from a large remote company that does all support) means your encrypted disk won't boot (and no-one on this continent is allowed to decrypt and recover data) - you guessed it - just part of your other 4 hours.

      But - upper management says we have to be agile, so we are agile (sprint length = 1 month). Perhaps a third of the developers have done agile at other companies, and sort of try - let's see, I would have given this a 5, which tended to be around a week, which has 20 official hours, so I give it a 20.

      But yes, agile isn't that hard to report on - I get the emails every day with the pretty charts from the official tools to prove that.

  19. Terrance Brennan

    Agile is simply going back to the bad old days

    The reality of the Agile deployments I have had the pain of having to deal with is that it is nothing more than an excuse for developers to go back to the bad old days of no planning, no designing, and no testing. Just throw some crap code into production and then fix it as you go along. I agree with the comments above that the best method is to have good developers do a conscientious job in test and dev and then when the code is stable move it into production. Not sexy but nothing breaks as a result.

  20. Anonymous Coward
    Anonymous Coward

    The anti-methodology methodology

    http://www.programming-motherfucker.com

  21. joejack

    One thing I've noticed

    Agile tends to foster good communication WITHIN a team and makes it easier for everyone to engage with the project; Waterfall forces better communication BETWEEN teams, but often leads to lack of ownership ("that's the PM's job - I've got my queue.")

    1. Dagg Silver badge
      Mushroom

      Re: One thing I've noticed

      Agile tends to foster good communication WITHIN a team and makes it easier for everyone to engage with the project;

      Pure double speak bullsh*t, this is just another way that agile is used to blame the development team.

      What! it failed!!!!! You devs must have failed to communicate!!!! BAD DEVS

  22. JamJam

    Why I hate agile #99

    The worst part are the developers who feel the need to become scrum masters.

    Not the best technically, lacking people skills, but not quite bright or personable enough to be a fully blown non-technical manager or project manager. The result always seems to be micro-management, no trust, no creativity while the scrum master undermines all the developers to the upper management, while not realising that the upper management give them no real authority or input.

    Bah.

  23. Anonymous Coward
    Anonymous Coward

    What is this article trying to say?

    I read the whole thing, and now I feel dumber.

    COBOL programmers are not as agile as they should be?

    At my work, now we have multi-hour 'sprint' meetings where I get to doze off to the sound of QA people planning their work in detail, rather than being at my desk coding. Seems legit.

    1. P. Lee

      Re: What is this article trying to say?

      "Break fast, fix quickly" is not something the business sponsors involved with systems running cobol want to hear.

      Agile might be fine for new things which don't have to work, but when your software supports a product which has moved from the innovation to exploitation phase of business usage, its time to protect the investment.

      Too much innovation, not enough exploitation -> never turn a profit from your work

      Too much exploitation, not enough innovation -> be overtaken by innovators

      The trick is to keep the balance.

      /credit -> TED

  24. Chris Hunt

    Yeah, right

    > Difficulties with Prince aside, there’s little doubt that agile is going to be the way forward.

    Speaking as one of those 50+ dinosaurs (though I've not touched COBOL for twenty years), I can tell you that agile will be identified as "the way forward" for couple of years, and then be replaced by some other half-arsed methodology invented by MBA-toting idiots and imposed by people who don't really understand it on the poor sods who actually have to do the work.

    The fact is that there's no magic universal approach that works in all situations, you have to blend different approaches to suit your own particular case. Sometimes that might be pure waterfall, somtimes agile, most of the time somewhere in the middle.

    1. Mellipop

      Re: Yeah, right

      Oh dear such a lot of FUD.

      Agile be around for a couple of years more? Why would a tendency to transparency, inspection & adaptation that has been growing for over 20 years now disappear?

      It will change, but you're not going to like it.

  25. ecofeco Silver badge

    Buzzword bollocks

    The few programmers I know are older masters (almost everyone in the world has used their work) and they are unanimous that the best working conditions is to be left the fuck alone while writing code and the best practice for quality control is to divide the software into sections and let each programmer work on their section alone, but with very strict guidelines for continuity and compatibility with the other sections and promptly fire the asshole that won't play by the rules. And test, test, test.

    Everything else is just buzzword bollocks and needless wheel spinning.

    1. Hollerithevo

      Re: Buzzword bollocks

      I don't generally disagree, but I have seen coding masters deciding that what the business wanted was something other than what they business asked for. In this case, the business actually asked for something sensible and focused, but it was too 'simple' and the master coder decided to make it a challenge by doing something else. It worked fine, but it wasn't what was needed. That slab of code got dumped and replaced, and he sat in his cubicle and fumed and played games.

  26. David Roberts
    Mushroom

    Two Words

    Fuck Agile

  27. Oengus

    Do you really want your bank accounts controlled by programs that have the Agile mentality "Get it out there and we will fix it on the fly"?

  28. Anonymous Coward
    Anonymous Coward

    The problem with agile is simple: there's a school of thought (or lack thereof) that says agile means running a project without defining anything at all, because even the most basic requirements analysis is "too waterfall", and then obfuscate reports to sr. Management around the cluster**** that happens in UAT, keeping the project limping along until they can't hide failure any longer, by which time the original project champion has moved to another project / department / company / career, and the project gets cancelled under a cloud, usually tainting the poor sod who just got lumbered with it. Those who didn't understand agile, blame agile, those who do understand agile, blame the original project champion, who was "the agile guy", management hear a post mortem where everyone is covering their butts, and blaming "the other guy's" implementation of agile methodology is easier than blaming someone sat around the table, management, desparate to cast off the albatross aroubd their department's neck, take away the impression that agile projects are a disaster waiting to happen

    (even though the project in question bore little or no resemblance to an agile project), and "action a best practice" to avoid agile at all costs in future: spreading the misconception as they wander from company to company.

  29. FeRDNYC

    The "agile antibodies"?

    Wait, agile fails to take hold because "the agile antibodies aren't strong"? The things that, in a living organism, would protect it against future infections of agile? (Compare "flu antibodies", "Hepatitis-B antibodies".)

    People shouldn't use metaphors they don't understand, because then this happens.

  30. Kevin McMurtrie Silver badge

    MVP

    Agile assumes that the next minimum viable product is not far away. Sometimes that's not possible and you need big plans, big schedules, and very clear long-term goals. If your project manager is stuck on any one methodology, you're doomed to fail.

  31. Anonymous Coward
    Anonymous Coward

    I like the concept of Agile...

    But execution has been more like a death penalty. My current corporation made that decision that program managers are just scrum masters with spreadsheets. So most of my day is spent being "coached" by a SM that's failing to hide their contempt for anything related to Agile, while bitching about the tool that won't let them report out the exact number of minutes spent on a story. I'm a bus sys analyst, which people cheerfully remind me has no actual role in Agile. A proxy PO at best, most often I'm just the person who needs to gleefully fall on my sword when something doesn't go perfectly.

    So yeah, I'd love to be an actual product owner, though again, my company has decided that POs are less about delivery of business value and more about kissing client ass and writing a two sentence description of a thousand hour project, then mysteriously disappearing whenever I come hunting for them. And now that the expensive Agile Coaches we hired have left the building, PMs are reverting to their old ways of micromanaging, under the guise of mentoring, while the architects are cavorting with sales to give vague, bordering on abusive, estimates for Client X's most recent high cost, low margin brain waves.

    Anon, even though I'm ready to invite a few people to watch a bridge-burning... from the bridge.

    /rant

  32. Sysgod

    Bah!

    Puny programmers need overhead. Puny programmers need communication and customer reassurance.

    Hulk programmer listens to customer, forms vision in head, gives token acceptance document, then does the plumbing, wiring, and constructs castle. Client likes, and Hulk programmer does changes and fixes easily because all his code.

    Frankly, software development has become too easy. Sounds like a lot of time wasting going on here.

    1. Mellipop

      Re: Bah!

      Love it, code ownership. We need more of that.

      How are you on pair programming?

      Or like the super cop, you don't work with a rookie who might turn out to have something you can learn?

    2. FeRDNYC

      Re: Bah!

      Whereas "Code Monkey like Fritos. Code Monkey like Tab & Mountain Dew. Code Monkey very simple man, big warm fuzzy secret heart. Code Monkey like you." –Jonathan Coulton

      ...And Real Programmers, of course, "wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly."

  33. Anonymous Coward
    Anonymous Coward

    Agile has limits

    I quite like doing things the Agile way. We switched all our dev to that, works great.

    What I DO NOT like is the incoherent and utterly useless documentation that Agile vomits out. "How does X work?" "Oh, was that in sprint 4? Check the JIRA." Utterly, fucking useless when you don't always have access to said JIRA.

    If Agile had better processes for creating documentation, testing it, and maintaining it; then it'd be pretty much perfect. Instead one is forced to waterfall the docs in a blind panic post release and that is just complete bullshit.

    I am a developer, so I don't say this lightly, documentation is an order of magnitude more important than code when it comes to deployment and sustainability.

    80% of all the support calls I handle (don't ask) result in 2 or more tickets being logged against documentation because they are asking how to do something or the users are confused why the system is blocking them (i.e. defending itself). That is a MASSIVE drag on resources and all because Agile is code-focused rather than quality-focused.

    Write the tests first, write the docs second (should be easy *IF* you have a design), then write the code. The code should be last outside of research/dicking-around-time. But no, not in Agile.

    1. Doctor Syntax Silver badge

      Re: Agile has limits

      "Write the tests first, write the docs second (should be easy *IF* you have a design)"

      So write the design zeroth.

  34. annodomini2

    Key point missed - Standards

    While not all code is required to meet a standard many systems in use do.

    Aerospace/Automotive DO-178B/C and ISO26262, explicitly require the use of waterfall.

    This is just one example, but I would bet there are more.

  35. Anonymous Coward
    Anonymous Coward

    "He cites as one example a project that was implemented using an agile approach but after a few months, it was clear it was falling behind and eventually the team started using an old methodology."

    so this thing happened somewhere and after a while it wasn't working the way they hoped so they decided not to do that thing anymore and reverted to do the other thing they were more used to.

    was there a minimum word count the author was trying to reach?

  36. hellwig

    Two Words: Earned Value

    The problem with Agile, from an antiquated management perspective, is that you can't claim you've completed any of the traditional work items until the end.

    MGR: "When will code be done?"

    DEV: "At the end of the project".

    MG: "When will test be done?"

    DEV: "The same time as the code."

    MGR: "So we're doing NOTHING for the whole time? How do I justify my existence to MY boss?"

    We're having a hard time explaining that, while we haven't completed any specific group of artifacts, we are in fact making progress on ALL OF THEM. We need to track FEATURES, not ARTIFACTS.

    I used to work at a pure Earned Value factory. How did you know you were done? You had burned all the hours in the bucket. No time left, we must be done. I mean, those people must have had a sixth sense, to know Task A would take exactly 6 hours, while Task B would take exactly 12 hours.

  37. Herby

    When in danger or in doubt...

    Run in circles, scream and shout...

    AGILE

    Just another scheme to let managers "manage" and justify their existence.

  38. Anonymous Coward
    Anonymous Coward

    building metaphor.

    The best analogy I saw on how software development should be done was in "Code Complete" .

    It used a building metaphor. Design, test and build.

    If skyscrapers were built using methods the way software is quite often developed there'd be a whole lot more stories of collapsing buildings in the news than we currently see.

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