• asdf (unregistered)

    The Agile programming mindset is like zombies.

  • PHB (unregistered)

    Agile Development Model...Agile Development Model. Hey! If I implement that at our company, I'll win buzzword bingo!

  • TheCaptain (unregistered)

    I worked in a very well oiled scrum-by-the-book shop recently. They were a huge enterprise environment, converting from a custom sdlc to scrum. Most of the other teams and processes were still this home-grown methodology and we had to interface with those teams. We got a massive amount of work done, with some upfront design, PLENTY of reqs and along the way managed to generate a wiki on the product that was more detailed than any of the docs their old products had.

    We went to production about a month late, which sucks but not terrible for a project of that size. The app is up and making money. We even managed to create some common UI pieces that are being used to develop another project at that same company. I'd say it was a total success.

    I now work at a faux-agile shop. Another huge enterprisey mega corp. It's actually waterfall but we're expected to get a year of work done in around 3 months. With no documentation. That makes it agile right?

    The differences between here and my last job are too large to describe. We are in chaos here. The codebase is a terrible mess, the app is brittle, copypasta all over and nobody has any idea how to gather or convey requirements.

    They have a hardcore chain of command with draconian rules placed around everything. We spent the whole first month trying to get someone, anyone, to cut us a branch in svn so we could at least check in work. We're not allowed to create or modify build scripts. There's no place in The Process for things like a development server. Contractors aren't allowed email addresses, workstations or a physical desk. The Process was developed before the company would consider hiring contractors so we just don't exist. We all work remotely (best part of the job actually!) because without a manager escort we can't even get into the building.

    Is it any surprise we're already a month and a half past a deadline someone else set for us with no end in sight?

    Before this I worked in another ISO-somenumber shop and another pseudo-scrum shop, and one ad-hoc waterfall-ish shop... I guess you could say I've spent about half my 10 year career in waterfall (or a derivative) and about half in agile/scrum.

    Only the agile projects have been successful.

    Just because you have a strict set of rules and dates around your process has nothing to do with your chances of success.

    In fact, only maybe 3 in 10 waterfall projects have even seen the light of day. And I've also NEVER met a PM that did anything other than update a Project or Excel sheet with percent complete. Then they play golf, drink coffee, spread horse manure about the office... useless....

    So yeah, all you agile naysayers: you're doing it wrong.

  • by (unregistered)

    Agile + Waterfall = Rapids development model™

  • Effete Hipster (unregistered) in reply to Me
    Me:
    Ah, the old waterfall method of implementing Agile Developement. Not necessarily a WTF, but ironic.

    Ugh, doesn't anyone understand irony?

  • (cs) in reply to Effete Hipster
    Effete Hipster:
    Me:
    Ah, the old waterfall method of implementing Agile Developement. Not necessarily a WTF, but ironic.

    Ugh, doesn't anyone understand irony?

    http://theoatmeal.com/comics/irony

  • JJ (unregistered)

    Okay, we've had "strange women" and "watery tart." Can someone please use "moistened bint"?

  • (cs) in reply to by
    by:
    Agile + Waterfall = Rapids development model™
    Wonderful! Best comment so far on this article.
  • Brian (unregistered) in reply to Jared
    Jared:
    On the bright side, they should be done by now.

    Captcha: dolor. Coloring, but dumber

    Or Spanish for pain.

  • nasch (unregistered) in reply to frits
    frits:
    Effete Hipster:

    Ugh, doesn't anyone understand irony?

    http://theoatmeal.com/comics/irony

    He's got at least one thing right, riding jet skis is a lot more fun than debating irony. And that's from someone who likes arguing.

  • Darth Scrum (unregistered)

    I have Agiled the project...pray I don't agile it any further.

  • boog (unregistered) in reply to Stephen Cleary
    Stephen Cleary:
    I guess I've never met a good project manager.
    They are quite rare. If you ever meet one, take a picture so the rest of us can believe you.
  • Hugh Brown (unregistered) in reply to JJ

    Here.

    Very hard to submit this one-word comment when I keep getting this: "Uh oh. Akismet says your comment was spam. Maybe it was, maybe it wasn't. But I'm taking their word on it. Try again!"

  • Hugh Brown (unregistered) in reply to JJ
    JJ:
    Okay, we've had "strange women" and "watery tart." Can someone please use "moistened bint"?

    Here.

    Very hard to submit this one-word comment when I keep getting this: "Uh oh. Akismet says your comment was spam. Maybe it was, maybe it wasn't. But I'm taking their word on it. Try again!"

  • Mr. Python to you, lad (unregistered) in reply to sdebaun

    bint: n. British slang for a girl or woman; may be derogatory. Possibly derived from Arabic (female equivalent of 'bin').

    Bink: n. Producer of computer video codec software

  • (cs) in reply to boog

    You can't tell by looking at them. Our PM does a nice job though - I have encountered this twice, and both of them work at my current employer. Good management can really make the difference. A good project manager will do all the things listed in the long post above. In addition to that, he keeps us all in a good mood - he planned a party today for pirate day. As a manager, he does keep the rest of the company from asking us to do the impossible... it is a very nice change of pace to be able to go in to your job every day and know that you're not going to be asked to do the impossible, that your tasks are well-defined, and the result will be appreciated by the business stakeholders, because the PM has managed their expectations appropriately. It completely removes the adverse sentiment between IT and other departments. Due to good management, the IT department is seen as part of the whole company and we actually work together with other departments to accomplish the same goals - that is a complete reversal from other places, where the IT department is often seen as "a service group that keeps me from getting any work done"

  • anon (unregistered) in reply to Effete Hipster
    Effete Hipster:
    Me:
    Ah, the old waterfall method of implementing Agile Developement. Not necessarily a WTF, but ironic.

    Ugh, doesn't anyone understand irony?

    Was this an attempt to be ironic by complaining that no one understands irony when in fact you yourself don't seem to understand irony? Because that actually would be kind of ironic. Wait, aren't you supposed to start smugly bitching about alanis morisette about now? And then link to that moronic blog post?

  • Dan (unregistered) in reply to boog

    I worked with one. She was fired for performance reasons.

    Honest.

  • (cs) in reply to nasch
    nasch:
    frits:
    Effete Hipster:

    Ugh, doesn't anyone understand irony?

    http://theoatmeal.com/comics/irony

    He's got at least one thing right, riding jet skis is a lot more fun than debating irony. And that's from someone who likes arguing.

    I do not like arguing!

  • James (unregistered)

    I've never seen anything more ridiculous than the % complete cells in MS Project. When I first had to use MS Project to manage a project, I was incredulous at that thought that people trusted such an arbitrary measure to track major projects.

    Oooooo...it magically updates the percentage!! Wow! This will help manage the project sooo much! Whee!!

  • LANMind (unregistered) in reply to TheCaptain
    TheCaptain:
    So yeah, all you agile naysayers: you're doing it wrong.

    I hear this mantra so often I could vommit. Programmers have been writing and maintaining apps successfully for a long time without it. If so many are fucking the latest and greatest thing, I'd say the problem aint the people, it's the thing. It seems to me that any process that tries to attain flexibility by requiring superhuman amounts of rigor is retarded, but such tortured logic is required to let the developer remain ignorant about the problem domain.

  • boog (unregistered) in reply to jasmine2501
    jasmine2501:
    You can't tell by looking at them. Our PM does a nice job though - I have encountered this twice, and both of them work at my current employer. Good management can really make the difference. A good project manager will do all the things listed in the long post above. In addition to that, he keeps us all in a good mood - he planned a party today for pirate day. As a manager, he does keep the rest of the company from asking us to do the impossible... it is a very nice change of pace to be able to go in to your job every day and know that you're not going to be asked to do the impossible, that your tasks are well-defined, and the result will be appreciated by the business stakeholders, because the PM has managed their expectations appropriately. It completely removes the adverse sentiment between IT and other departments. Due to good management, the IT department is seen as part of the whole company and we actually work together with other departments to accomplish the same goals - that is a complete reversal from other places, where the IT department is often seen as "a service group that keeps me from getting any work done"
    So what's the deal? Is your PM reading your comments or something?
  • (cs) in reply to frits
    frits:
    nasch:
    frits:
    Effete Hipster:

    Ugh, doesn't anyone understand irony?

    http://theoatmeal.com/comics/irony

    He's got at least one thing right, riding jet skis is a lot more fun than debating irony. And that's from someone who likes arguing.

    I do not like arguing!

    Yes you do.
  • (cs) in reply to Justin
    Justin:
    Hmmm. Try change a government, mkay? And you'll see that this guy is pretty clever to be as transitional as possible.

    Case in example:

    • South Africa changed from Apartheid to a democratic 16 years ago. Things were shaky early in the transition, but it was relatively peaceful.

    • USA decides to bomb Afghanistan and Iraq. Change those governments into democratic government. They had no plan - and where are they today? Still there... still putting out fires... still bombing... still sling-shooting.

    Anyways, point is: at least have some familiar process to transition into the new process.

    This analogy, my friends, is TRWTF.

  • Monty P. (unregistered) in reply to ContraCorners
    ContraCorners:
    frits:
    nasch:
    frits:
    Effete Hipster:

    Ugh, doesn't anyone understand irony?

    http://theoatmeal.com/comics/irony

    He's got at least one thing right, riding jet skis is a lot more fun than debating irony. And that's from someone who likes arguing.

    I do not like arguing!

    Yes you do.

    Ah, is this the right room for an argument?

    Ding Good morning!

  • (cs) in reply to LANMind
    LANMind:
    TheCaptain:
    So yeah, all you agile naysayers: you're doing it wrong.

    I hear this mantra so often I could vommit. Programmers have been writing and maintaining apps successfully for a long time without it. If so many are fucking the latest and greatest thing, I'd say the problem aint the people, it's the thing. It seems to me that any process that tries to attain flexibility by requiring superhuman amounts of rigor is retarded, but such tortured logic is required to let the developer remain ignorant about the problem domain.

    It has been said before but needs repeating. The process is not the goal. For some projects waterfall works, for others some form of agile. However you need to tailor the proces to the goal and the team.

    TRWTF is that so many places think implementing a new buzzword is a panacea. For waterfall and agile their are still plenty of thing both need. Design and documentation are generally part of that.

    Here is the important part, don't do what you don't need. Building a website for granny's knitting club. Just do it. Building medical equipment which potentially can fry a person? Design, document and test till your ears bleed so mine won't when I'm put through it (unless you have particular symapthy with my next of kin).

    Agile does not mean vast rigorous overdocumentation nor does it mean no documentation. Same with watefall (which can also iterate btw). The level of documentation should be tailored.

    Nothing, but nothing, replaces experience and qualified people. If you find a dyslexic, autistic, one handed, hygienically challenged, tourettes syndrome sufferer who can program his way out of a barrel on its way down niagara falls using only an abacus and a carrier pigeon as long as you let him do his thing his way...then let him do it. Fitting him into a team might be a little hard though.

    So all you agile naysayers, you are probably doing it wrong but all you waterfall naysayers you are also doing it wrong. Projects usually fail because you (or somebody anyway) is doing it wrong.

  • Mel (unregistered) in reply to TheJasper
    TheJasper:
    Fitting him into a team might be a little hard though.

    Just fit him into a barrel. He'll do the rest!

  • boog (unregistered) in reply to TheCaptain
    TheCaptain:
    So yeah, all you agile naysayers: you're doing it wrong.
    I wanted to avoid the whole "agile" debate myself, mainly because it never gets anywhere. So forgive me, all of you, but I just couldn't resist the gem-of-a-comment above. Here goes:

    I could make the same claim about waterfall that you were "doing it wrong." But it seems from your little rant that the environment itself was conducive to failure. I'd guess it wouldn't have mattered if you used waterfall or "agile," considering the massive workload, chaotic environment, horrible codebase, inability to work (delayed SVN branch, no changes to build scripts, etc.), and low morale due to being treated like you don't exist. Did you have this kind of dysfunctional environment on any of your "agile" projects?

    Personally, I don't want to hear all this adulation of your favorite "process." It's sickening. Just use whatever process you want. If it works, good for you. I couldn't care less.

    So yeah, all you agile yaysayers: stop advertising, I'm not interested.

  • Flatpicker (unregistered)

    Yep, that's what ours always looked like too. Don't forget to schedule meetings about your meetings. Make sure you invite everyone, every time. Let's spend 20 hrs in meetings each week and then act shocked and look for someone to blame when nothing gets done. But hey, at least were doin' Agile, right?

  • kosh (unregistered)

    The real WTF is that the PMO owns the SDLC.

  • EmperorOfCanada (unregistered)

    This is the sort of project manager that generates paperwork that will never be read. Yet this huge volume of paperwork is used to justify the position. A terrible manager generates no paperwork. A bad manager generates much paperwork. A good manager generates some paperwork. A great manager generates no paperwork.

    I have been in on a few projects that generated awesome code an awesome product and everyone was happy. I don't remember a single spreadsheet. The design existed on a whiteboard with post-it notes. Worst project I ever saw had a spreadsheet so big it wouldn't be believed.

  • Thera (unregistered) in reply to chron3
    chron3:
    Agile does not mean a lack of process, just a different one.
    To be fair, a lack of process could be called "different" too :)
  • backup (unregistered) in reply to Marx314

    i have uploaded a copy of the picture here, hopefully that is not blocked. enjoy: http://imagepaste.nullnetwork.net/viewimage.php?id=1299

  • AT (unregistered) in reply to Justin
    Justin:
    * USA decides to bomb Afghanistan and Iraq. Change those governments into democratic government. They had no plan - and where are they today? Still there... still putting out fires... still bombing... still sling-shooting.

    You're the worst sort of fool. The US military and govt had reams and reams of plans for war in Iraq and Afghanistan. The problem is that wars end when one side surrenders, and there's no plan that can prevent an enemy from fighting to the last man. Nor a plan to easily kill every enemy embedded in a civilian population. I have a feeling your war "plan" would look something like this:

    Phase 1) Start war. Phase 2) ? Phase 3) Win.

  • (cs) in reply to KP
    KP:
    A good project manager's job extends well beyond asking what percent complete and when it will be done.

    I can tell by your comment that you are completely oblivious to what project management actually entails.

    A good project manager will:

    • Make sure that you have what you need to complete the tasks, that includes servers for testing, development environments, training, access to systems, 3rd party components, etc.

    • Work with developers and other stakeholder to determine the scope - what actually has to be developed, and when, and what dependencies exist along the development process.

    • Organize the work in a logical manner so that you as a developer aren't being asked to develop a piece that requires other pieces that are currently vaporware

    • Negotiate with the stakeholders in the project so that everyone understands what is going to be delivered and when, and possibly renegotiate with stakeholders and keep everyone happy when you need more time to get the code or interfaces working properly

    • Create the project documentation that may seem irrelevant from a developers standpoint, but is the reason that the upper management gave the project a green light - because it's relevant to them and offers them a sense of comfort, and a degree of understanding about the project

    • Understand the software, underlying objects and development process to an extent that they don't look like idiots in the scrum and can actually ask illuminating questions that may uncover other tasks, project needs or constraints, or clarify and reduce the scope

    • Arrange the project to minimize risk, and present those risks to the people that are funding the project so that if a risk event occurs they are still happy, and willing to keep paying you

    • Set expectations amongst the stakeholder

    • Manage costs

    • Ensure that task assignments are balanced amongst the team and that everyone has a fulfilling, challenging and achievable amount of work to do

    • Do all that boring reporting that keeps track of where we are in the project, and whether we think we'll be able to deliver it to a client when we promised in the contract with enough advance notice if we're going to miss it that the contract can be renegotiated and the expectations can be reset, saving developers from having to pull 14 hour shifts to get it all together

    • Consider the business motivations behind the project and align the release and code cut-offs with those motivations - because there's no sense in having developers pull all nighters if the QA guy is on holiday for two weeks after the code cut-off date, or if the client rep has gone to Bali for a month and won't have a chance to look at the app until he's back

    • Be a communications hub

    • Insulate the development team from political machinations which may unnecessarily defocus their efforts

    And many other things.

    Then in 30+ years of ITville, from mainframes to Unix to PCs to Client/Server (basically, everything except DEC), I have NEVER encountered a "good" project manager.

  • (cs) in reply to JJ
    JJ:
    Okay, we've had "strange women" and "watery tart." Can someone please use "moistened bint"?

    It's "bink", a vaguely (if at all) defined pejorative for woman, kind of like... "tart".

    So the commonality with all 3 phrases is females who are wet (literally, not in the "hot" sense): "strange women lying about in ponds" "watery tart" "moistened bink"

    Now, go away or I shall taunt you a second tahm-ah.

  • Anone (unregistered) in reply to SQLDave
    SQLDave:
    JJ:
    Okay, we've had "strange women" and "watery tart." Can someone please use "moistened bint"?

    It's "bink"

    No it isn't.

  • C6H12O6Free (unregistered) in reply to Aaron

    You hit that so hard on the head it's seeing stars.

  • rxd (unregistered)

    strange that nobody commented on the two months of pure BS for analysis and two no-nonsense weeks for execution. that's the real WTF

  • not-of-this-Earth (unregistered)

    Call a screwdriver a hammer, and hammer nails with it. Everyone's happy. Except of nails perhaps.

  • oheso (unregistered) in reply to ÃÆâ€â„
    ÃÆâ€â„:
    Fred:
    Lucky for modern civilization spammers haven't yet figured out an automated way to generate a bunch of crap text to get past filters like this.
    Yes they have, just outsource it to some guy in a call center in India.

    They're called "The Daily WTF commenters".

  • OTee (unregistered) in reply to JamesQMurphy
    JamesQMurphy:
    ...it will be several months late and several thousand dollars over budget.

    IT is all about '1' and '0'... in this case, add generously zeros to the end of that "thousands"...

    CAPTCHA: facilisi - an Italian hired to do copies

  • jeremy (unregistered) in reply to Dan
    Dan:
    I worked with one. She was fired for performance reasons.

    Honest.

    Worked with one what? A bint, or a real project manager?

  • (cs)

    Waterfall works reasonably well with brand new green-field projects where you have a plan and try to reach targets by a certain date.

    Agile works better later on when maintaining a project that has regular release cycles, so you can plan what is going to be in each upcoming release and what issues exist.

    In either case a project manager needs to know how software is developed, i.e. you write a load of tools and put the framework into place often before you start writing features, therefore the percentage complete is not a percentage of the number of features currently in place. They should also know that you sometimes "fake" a feature implementation, either to demonstrate it so you can decide how it will look in the final product, or to have some prototype for use in the framework to allow some of the developers to work on the system whilst others are building the real system.

    Many project managers are also coders and are still actively writing code on the project as well as managing it, and as long as they don't try to write everyone else's code for them or over-control the way the other developers write their code, this works best, in my opinion.

  • Danny Moules (unregistered) in reply to Stephen Cleary
    Stephen Cleary:
    I guess I've never met a good project manager.

    They're pretty hard to come by - but a good one is worth it. Management hate them though because they make it much harder to interfere and impose arbitrary rule so they don't last long...

    TRWTF is that I bet plenty of people reading this have spotted the irony, chuckled... and then still decided to complain about it.

    CAPTCHA: Abigo

    1. I drive away (particularly cattle)
    2. I deter, discourage, frighten away
    3. (medicine) I remove a disease
    4. (medicine) I force birth, cause an abortion

    Neat.

  • Danny Moules (unregistered) in reply to Anone
    Anone:
    SQLDave:
    JJ:
    Okay, we've had "strange women" and "watery tart." Can someone please use "moistened bint"?

    It's "bink"

    No it isn't.

    It really, really isn't.

    CAPTCHA: valetudo "full-contact unarmed combat events"

  • (cs) in reply to not-of-this-Earth
    not-of-this-Earth:
    Call a screwdriver a hammer, and hammer nails with it. Everyone's happy. Except of nails perhaps.

    Even more so call a hammer a screwdriver and bang screws into the wall instead of screwing them in. They will go in eventually if you hit them hard enough and will probably just about do the job although it will probably require a fair bit of maintenance.

    Agile does have many good ideas in it. In particular it is easy to know when a developer is blocked on something.

    I have found a lot of issues that cause the development process not to work well have been known to come from:

    • Inadequate hardware resources available
    • Waiting too long for things to be "approved".
    • Badly balanced teams, where everyone is expert in exactly the same thing and unable to do something else necessary properly because there is nobody that is expert in that particular thing.
    • Blocked waiting for your code to be reviewed. Code reviews are a good thing because they lead to better code and would get rid of a lot of the WTFs that are on this site, but trust your developers reasonably well and don't leave them with a huge backlog waiting to be reviewed before they can check anything in.
    • Spending too much of your time building because there is one big thing called "the build" rather than a proper component-based system, or because you have a test-driven environment where tests run as part of the build process itself. Nice in theory but in practise leads to poorly written tests.
    • Teams where the workload is unbalanced, not so much for the reason above, but because only a few people, usually those who have been there for a while, know what the requirements really are, and they are too busy implementing them (because they are "urgent") than bringing the other developers up to speed (either by talking to them directly or by documenting what they know in a clear manner that they would understand).
  • Peter (unregistered) in reply to AT
    AT:
    Justin:
    * USA decides to bomb Afghanistan and Iraq. Change those governments into democratic government. They had no plan - and where are they today? Still there... still putting out fires... still bombing... still sling-shooting.
    You're the worst sort of fool. The US military and govt had reams and reams of plans for war in Iraq and Afghanistan. The problem is that wars end when one side surrenders, and there's no plan that can prevent an enemy from fighting to the last man. Nor a plan to easily kill every enemy embedded in a civilian population.
    Which may suggest that war is not necessarily a particularly successful way to introduce democracy?
  • Botia (unregistered) 
    % Complete  Task Name     Start       Finish  
      100%     lol     Thu 9/16/10  Fri 9/17/10
  • itsmo (unregistered) in reply to Marc Vertido
    Marc Vertido:
    They're using the Waterfall model to implement the Agile model...that's what's funny about this.

    Funny is going a bit too far - this doesn't even reach ironic. Crap WTF - boring.

Leave a comment on “In a Barrel”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article