• J (unregistered)

    Company has been cursed. -5 Agility.

  • The Enterpriser (cs)

    I guess the feedback re: process issues/concerns wasn't as positive as they'd hoped.

  • Jared (unregistered)

    On the bright side, they should be done by now.

    Captcha: dolor. Coloring, but dumber

  • Frank (unregistered)

    IDGI, please explain?

  • ÃÆâ€â„ (unregistered)

    Meh, a project behind schedule isn't that big of a WTF. I was expecting rants against co-workers or ranking of co-workers based on body attributes somewhere in that table, but it was just a project behind schedule. They can't all be gold, I guess.

  • JamesQMurphy (cs)

    I don't get it. "Agile" doesn't mean "without process." It means a different process than traditional waterfall. You still need processes, artifacts, training, and all that stuff.

    Granted, this type of MS Project work would bore me to tears, and if it's run like most projects at big enterprise-y places, it will be several months late and several thousand dollars over budget.

  • RogerC (cs) in reply to Frank
    Frank:
    IDGI, please explain?
    When you're down inside the Big Design Up Front box it's very hard to see the world outside. There are no windows, and the walls are all papered with Gantt charts.
  • Steve The Cynic (cs)

    So, what, exactly, are they supposed to do? Granted, this plan does seem excessive, and it would be better to do a brief study of the literature followed by a case study on a small project, but you have to consider TORWTF (The Other RWTF), the Process, aka the ISO 9001 quality manual. That probably dictates a process for adopting new methodologies (well, it should, anyway), and many of the items in this plan look as if they belong in such an environment.

    Of course, the somewhat free-wheeling nature of most Agile processes does not sit well in an ISO-9001 environment, especially the "eww, gross, let's fix it" approach to refactoring, but what do I know?

    (Yeah, yeah, OK, I'll say it... "Not much, dude!")

  • Drew (unregistered)

    Two months of analysis, agile does not make.

  • Spork (cs)

    Next: the GANTT chart for processes involved to hire the Scrum Master.

  • Rufford (unregistered)

    So is TRWTF the idea that they thought they actually went to Agile?

  • Me (unregistered)

    Ah, the old waterfall method of implementing Agile Developement. Not necessarily a WTF, but ironic.

  • The Enterpriser (cs) in reply to JamesQMurphy
    JamesQMurphy:
    Granted, this type of MS Project work would bore me to tears, and if it's run like most projects at big enterprise-y places, it will be several months late and several thousand dollars over budget.

    If several months late is only costing you several thousands dollars, you aren't at a big anything.

  • Aaron (cs) in reply to RogerC
    RogerC:
    Frank:
    IDGI, please explain?
    When you're down inside the Big Design Up Front box it's very hard to see the world outside. There are no windows, and the walls are all papered with Gantt charts.
    I could easily say the same about Agile. Doesn't matter whether you're in an ultra-secure Waterfall bomb shelter or a dingy Agile basement; either way, if you could only look out a window, you'd see the wide open landscapes of Actually Knowing How To Do Your Job.
  • Marc Vertido (unregistered)

    They're using the Waterfall model to implement the Agile model...that's what's funny about this.

  • JamesQMurphy (cs) in reply to The Enterpriser
    The Enterpriser:
    JamesQMurphy:
    Granted, this type of MS Project work would bore me to tears, and if it's run like most projects at big enterprise-y places, it will be several months late and several thousand dollars over budget.

    If several months late is only costing you several thousands dollars, you aren't at a big anything.

    Okay, yeah, a few million dollars would probably be closer to the mark. But it's not like this is an actual coding project, just a project to convert the process over to a different process.

  • JamesQMurphy (cs) in reply to Marc Vertido
    Marc Vertido:
    They're using the Waterfall model to implement the Agile model...that's what's supposed to be funny about this.

    FTFY

  • David (unregistered)

    TRWTF is that they haven't included ISO 9000 process development - how will they know their Agile Process is adequate?

    CAPTCHA amet - amo,amas,amat - no, not lovin' it.

  • Dazed (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.
    A number of people here need to think about what they're writing. What is this group supposed to use to implement Agile? Agile? i.e. a method that hasn't been implemented yet? How many of you will order your next computer using your next computer?
  • sdebaun (unregistered)

    This is hilarious to people who are somewhat versed in Agile.

    To those that aren't: An Agile process would not have a document that looked like that. The whole idea of Agile is that you're not planning "that way". You're dealing with batches of concrete features on a periodic basis (e.g. weekly).

    "Strange women lying in ponds distributing due dates is no basis for a system of project management!"

    Bad music analogy: it's like a club owner saying they're going to change from reggae to country, so they hire a reggae band to play reggae covers of country songs.

  • Code Slave (cs) in reply to JamesQMurphy
    JamesQMurphy:
    I don't get it. "Agile" doesn't mean "without process." It means a different process than traditional waterfall. You still need processes, artifacts, training, and all that stuff.

    Dito.

    There's a lot of people out there who assume that "Agile" means without a plan. The developers like the idea because they think they aren't going to have spend all that boring time making a plan/design document before they do the "Real" work of coding it.

    The management don't like the idea because they are concerned (rightly so) that developers working without a predefined plan will produce cr@p.

    Both sides fail to realise that in any Agile Big-M methodology you still do at least as much planning, it's just cut up into a lot more chunks.

    I still don't see the WTF here though. You are investigating using a new process, but you are using the old process to run the investigation project.

  • frits (cs)

    So how exactly is this CodeSOD? Where is teh codez to mock?!

  • Marx314 (unregistered)
    Comment held for moderation.
  • ToodleLew (unregistered) in reply to Frank

    The PMO is planning and implementing an Agile development environment using the waterfall model. The PMO hasn't accepted the Agile model for it's own use.

  • frits (cs)

    What, no unicorns? Hath the Red Bull won?

  • chron3 (cs) in reply to sdebaun
    sdebaun:
    This is hilarious to people who are somewhat versed in Agile.

    "Strange women lying in ponds distributing due dates is no basis for a system of project management!"

    Or "You can't expect to follow an agile methodology just because some watery tart threw some index cards at you..."

    Agile does not mean a lack of process, just a different one.

  • BeepDog (cs)

    Here's their manifesto: http://www.halfarsedagilemanifesto.org/

    But apparently I don't have enough text to make this URL not spam. So perhaps by typing in more things it won't be spam anymore.

  • Fred (unregistered) in reply to BeepDog
    Comment held for moderation.
  • nope (unregistered)

    Where is the WTF?

    You need a methodology to make sure that the agile process is being followed. Without it, you might as well use no process, which is still 1 step above waterfall. There has to be audits, proof of unit testing, etc.

  • Justin (unregistered)

    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.

  • airdrik (unregistered)

    So what's wrong with using the existing process to make sure that they transition to the Agile process properly? They're investigating it and scoping out exactly how it will be implemented to make sure that they do it correctly.
    Sure they could immediately use Agile process to transition over to using Agile for development and other processes, but if they just jumped on it bandwagon-like, they could mess up a lot of things and turn out a great big hassle.

    As for those mentioning the timeline in relation to today's date: the screenshot was probably taken in the beginning of May and they were right on schedule when it was taken.

    IMO, the people finding WTF in this (at least with the limited amount of context information that we have been given) are all grasping at straws (or is there really something more that we can infer from this that I'm missing).

  • sdebaun (unregistered) in reply to Dazed

    Dazed:

    There absolutely are processes for Agile. They look nothing like this.

  • Casper (unregistered)

    Project Managers are (usually) TRWTF. All most of them know how to do is ask "When will it be done?" and "What percent is complete now?" In other words, they are in effect a very slow cumbersome and error prone input interface device between you and their damned MS Project spreadsheet.

    Then if, despite your inability to see the future, you make up an answer, they'll just change it to something they like better anyhow.

    Completely.

    Freaking.

    Useless.

  • _sam (unregistered) in reply to sdebaun
    sdebaun:
    Bad music analogy: it's like a club owner saying they're going to change from reggae to country, so they hire a reggae band to play reggae covers of country songs.

    Yes, that is a bad analogy.

    A better analogy would be "continuing to live in your current apartment, while looking for a new apartment". "Living in your new apartment while looking for your new apartment" doesn't make any kind of sense.

    So slightly ironic, yes, but WTF, no (and CodeSOD? seriously?).

    I accept a better way to investigate Agile would be to try it out ... but it would still make sense (to a big Org) to run a "try out Agile" project within the waterfall framework (ie have a definite cut-off at some point to decide how it went, and how to roll it out if successful).

  • sdebaun (unregistered) in reply to ToodleLew
    ToodleLew:
    The PMO is planning and implementing an Agile development environment *using* the waterfall model. The PMO hasn't accepted the Agile model for it's own use.

    Ah, that. Ok, that's less of a WTF then, but still funny: using a waterfall methodology on a project to evaluate whether or not to use agile methodology. Athena springing from Zeus' head?

    Or "You can't expect to follow an agile methodology just because some watery tart threw some index cards at you..."

    "I mean, if I went around saying I was a project manager just because some moistened bink lobbed a gantt chart at me, they'd put me away!"

  • MWF (unregistered)

    TRWTF (based on some of the comments here) is that people think you have to subscribe to just one model or another.

    In reality, a single development model rarely provides an optimum development structure.

    One must keep in mind that development models are not something that benefits from being strictly applied. Rather, they are general tools one can use to construct the optimum configuration for their own specific situation; the final form of which probably won't match any given model exactly. The same goes for design patterns (where one should also be mindful that design patterns result from analysing common solutions to practical problems in the real world; they didn't arise wholly out of theory only to be applied to a practical problem afterward, nor are they best served to be applied strictly...)

    Oh, and one is also well-served to remember that no one development model is suitable for all cases. Too often does management (or even engineering) demand the use of "method X" when it is actually detrimental to the success of the project at hand. People get blinded by buzzwords and idealized models without stopping to recognize reality.

    Contrary to popular opinion (and certainly contemporary management buzzword-focused opinion), Agile is not an end-all-be-all model for software development. In fact, depending on the application, forcing the use of agile methods can be absolutely disastrous.

  • jasmine2501 (cs) in reply to Aaron
    Aaron:
    I could easily say the same about Agile. Doesn't matter whether you're in an ultra-secure Waterfall bomb shelter or a dingy Agile basement; either way, if you could only look out a window, you'd see the wide open landscapes of Actually Knowing How To Do Your Job.

    Came here to say that - there's no substitute for a good project manager, and neither waterfall or agile are correct for most situations. Waterfall is "don't do anything until you know everything" and Agile is "do something now, even if you don't know what it is" - and the Real Truth of project management is somewhere in between. I don't see any WTF here... actually I'd like to see more project plans being used in more companies - would save me a lot of headaches.

  • Jay (unregistered)

    I'm reminded of when I was doing consulting work for the Air Force. We regularly got multi-page forms from various agencies that we were expected to fill out describing what our current project was for, how we were meeting security requirements, what tools we were using, etc. Once I got -- and this is not a joke, this is literally true -- a 65 page form I was expected to fill out. The topic: What we were doing to comply with the Paperwork Reduction Act.

  • Cbuttius (cs)

    That word "agile" is a pain in the neck for me. Well I hate it because it's been used too much as a buzzword in the last couple of years.

    Another "are you familiar with..." question for moronic recruitment agencies and HR managers to determine whether someone has the necessary qualifications for the job, or exclude CVs that don't contain the word. Probably followed up with "how many years/how recently/give an example of" questions...

    How many of the WTFs on this site were there purely because they weren't using Agile?

  • ÃÆâ€â„ (unregistered) in reply to Fred
    Comment held for moderation.
  • KP (unregistered) in reply to Casper

    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.

  • Webster (unregistered)

    Agile (adj)

    1. Software project sponsored by someone unable to properly define the requirements

    2. Software project developed by people unable to properly analyze requirements or create a development plans

  • Rob (unregistered) 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.

    Unfortunately, so are all but one of the project managers I've ever dealt with.

    So many of them know only "what percent is complete" that finding someone who does everything else on your list is rare.

    And, of course, the one PM who knew what they were doing was RIFfed in the middle of a project... which promptly sank in a sea of "what percent is complete" emails...

    captcha: ideo - a small idea

  • MS (unregistered) in reply to Code Slave
    Code Slave:
    There's a lot of people out there who assume that "Agile" means without a plan. The developers like the idea because they think they aren't going to have spend all that boring time making a plan/design document before they do the "Real" work of coding it.

    I call it "faux agile" when you get a team of people who think that "agile" = "hack some shit together and hope you can make it work". I've seen faux agile projects, but I've never seen a project follow a formal agile process.

    ( Personally, I prefer to understand the problem before I start designing. )

    I still don't see the WTF here though. You are investigating using a new process, but you are using the old process to run the investigation project.

    +1

  • somedude (unregistered) 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.

    I don't know why but.. reading the first sentence up to the "[...] mkay?" made me think of Bill Lumbergh from Office Space.

  • sdebaun (unregistered) in reply to MS
    I call it "faux agile" when you get a team of people who think that "agile" = "hack some shit together and hope you can make it work". I've seen faux agile projects, but I've never seen a project follow a formal agile process.

    ( Personally, I prefer to understand the problem before I start designing. )

    I'm starting a project using Agile techniques and I'm finding that I'm doing more documentation than I ever did for the (granted, extremely loose-and-fast) "Waterfallish" techniques I've used in the past.

    I'm still spending the up-front time describing, at a very high level, what the requirements (features) are. I'm estimating how big those features are. It's just that instead of deciding on an arbitrary date three months in the future that feature X is going to be done, I'm putting the feature in the queue.

    By seeing how much is in the queue, you can estimate how long the project is going to take, but still be flexible enough to change requirements as needed.

  • JamesQMurphy (cs) in reply to somedude
    somedude:
    I don't know why but.. reading the first sentence up to the "[...] mkay?" made me think of Bill Lumbergh from Office Space.

    I think that's the effect that Justin was going for.

  • SomeDeveloper (unregistered)

    HAHAHAHA. I know what company this is, I've literally seen this project plan.

    CAPTCHA: jugis

    What?

  • JamesQMurphy (cs) in reply to Rob
    Rob:
    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.

    Unfortunately, so are all but one of the project managers I've ever dealt with.

    So many of them know only "what percent is complete" that finding someone who does everything else on your list is rare.

    And, of course, the one PM who knew what they were doing was RIFfed in the middle of a project... which promptly sank in a sea of "what percent is complete" emails...

    captcha: ideo - a small idea

    Reminds me of Dilbert when the PHB decided to manage by spreadsheet. Which is exactly how my old boss managed at one of those big enterprise-y places.

  • Stephen Cleary (unregistered) 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.

    (snip)

    • Manage costs

    (snip)

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

    And many other things.

    I guess I've never met a good project manager.

Leave a comment on “In a Barrel”

Log In or post as a guest

Replying to comment #:

« Return to Article