Agile is simply a scam and doesn't work.



  • .. or the TL;DR version:

    "company that uses waterfall produces a report attempting to show how agile doesn't work but actually describes how agile's been badly managed" shock horror.

    Discuss.



  • @Cassidy said:

    Discuss.

    No!

    Well. Ok. I think Agile is in often in violation of Brooks's "No Silver Bullet" rule-- if you listen to trainers talking about it, listen to the employees that come out of those training sessions, it certainly sounds as if its being promoted as the silver bullet that fixes all software problems. At the same time, I think Waterfall doesn't adapt well to situations where the product needs to be changed quickly, or where distribution of the product is 100% controlled by the developer (that is, web apps). That's not to say Waterfall is bad-- just that it doesn't work well in those situations.

    As to your premise, 90% of the time when you see "X is bad" it's because X is being misused. That's because it's a lot easier to define a system in an idealized world than to actually use one in the real world. Duh.



  • I especially like this misleading bullet point:
    @TFA said:

    • Overwhelmingly, 40% of participants that use Agile did not identify a benefit.

    Which was it? Overwhelmingly, or just 40%?

    In related news, 50% of the under 12 years old participants in my study did not like pizza. Remember: all to often, today's leftovers are tomorrow's breakfast.



  • @blakeyrat said:

    it certainly sounds as if its being promoted as the silver bullet that fixes all software problems.

    There's no getting away from the fact that it's over-evangelised in many places, and opponents of it cite places where raised expectations weren't met or bad management tarred it with the same brush.

    @blakeyrat said:

    That's not to say Waterfall is bad-- just that it doesn't work well in those situations.

    I suppose the same goes for any methodology - there's a time and a place, and a poor choice will produce poor results, irrespective of what's used.

    @blakeyrat said:

    That's because it's a lot easier to define a system in an idealized world than to actually use one in the real world. Duh.

    I'd also add that it's a lot easier to define a system when system requirements are clear, i.e.: people discussing system functionality are all focused upon a clearly-understood problem definition and strive to achieve a workable solution within given constraints. It's when design gets distracted by extraneous considerations or different people are focussed upon different goals do things begin to diverge.

    I feel agile methods are closer to the concept that whatever you build, it will never be the optimal solution - but will be something pretty close, and each quick iteration (re)aligns the results with the requirements, even if the requirements begin to differ over time. This addresses the issue that improvement opportunities often emerge once something has actually been in use for some time (either because knowledge isn't finite or because the "proof is in the pudding") so if something is difficult to use in the real world today, we have a process to make it easier tomorrow.

    I can't profess to be an expert in such matters, but I know it's easier to hit a moving target by squeezing off several shots and adjusting your aim after each miss than it is to aim for a prolonged period then let fly.



  • @boomzilla said:

    I especially like this misleading bullet point:
    @TFA said:

    • Overwhelmingly, 40% of participants that use Agile did not identify a benefit.

     

    Yeah... without any qualifying text to explain why not, that statistic becomes meaningless. It could simply be "they didn't perform any benefits analysis" or "they weren't shown any comparisons". There's nothing to indicate no benefit existed, just that 40% didn't see it.

     



  • @Cassidy said:

    Yeah... without any qualifying text to explain why not, that statistic becomes meaningless. It could simply be "they didn't perform any benefits analysis" or "they weren't shown any comparisons". There's nothing to indicate no benefit existed, just that 40% didn't see it.

    And how, exactly, do those 40% "overwhelm" the other 60%? I can only guess that "no benefit" was more common than any other particular benefit. Which is still a stupid way to present the results.

    @Cassidy said:

    I'd also add that it's a lot easier to define a system when system requirements are clear, i.e.: people discussing system functionality are all focused upon a clearly-understood problem definition and strive to achieve a workable solution within given constraints. It's when design gets distracted by extraneous considerations or different people are focussed upon different goals do things begin to diverge.

    I feel agile methods are closer to the concept that whatever you build, it will never be the optimal solution - but will be something pretty close, and each quick iteration (re)aligns the results with the requirements, even if the requirements begin to differ over time. This addresses the issue that improvement opportunities often emerge once something has actually been in use for some time (either because knowledge isn't finite or because the "proof is in the pudding") so if something is difficult to use in the real world today, we have a process to make it easier tomorrow.

    Yes, the age old, "it depends," because it always does. Especially with a customized application that's brand new (i.e., not replacing some legacy system), users generally don't really know what they want. Or what they think they want is impossible or totally impractical. And when you're replacing a legacy system, they end up requesting lots of the arbitrary limitations of the legacy system that make the legacy system suck.

    Some sort of prototyping or agile approach seems like the only way around this sort of nonsense. IME, waterfall is only good for project managers and their MS Project proficiency. YMMV.



  • @boomzilla said:

    users generally don't really know what they want.
     

    Amen, brotha.

    In my experience, I have observed the following behaviour:

    • users don't know what they do want - but do know what they don't want
    • users usually describe what they want - rather than what they need
    • users can describe the journey - but not the destination
    • users don't often communicate changes in requirements - so user engagement becomes a supplier responsibility
    • users occasionally treat UAT as change proposal opportunities
    • users aren't resistant to change - they're resistant to unfamiliarity
    • users aren't always completely clear about (or cannot clearly define) how they use a current system - so creating a replacement is near-impossible
    There are obviously a few others. But I'll get off my soapbox now.



  • "The Agile movement shifts the broad, inter-departmental process of software engineering to one that is focused on software development to the exclusion of QA and operations,"

    Incorrect. Every Agile project I've worked on has extensive QA not only in the form of a formal testing environment with QA specialists, but with varying degrees of unit testing which must pass in order for a build to be worthy of deployment to any environment.

    "In spite of the specialization of resources which limits the scope of the work of developers, the Agile movement might inspire and encourage developers to push back on processes, tools, documentation, and following plans,"

    Agile projects always define [i]some[/i] requirements to reach an end goal. The only difference is they don't define every single minute task before development starts. At the end of each sprint a new collection of tasks are defined for the next sprint. To say agile developers don't plan ahead is grossly inaccurate. Agile development isn't improv, it's about taking a project one step at a time and making course adjustments at the end of each step.

    Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow.

    Of course. Every paradigm shift takes some time and effort to get used to. The same could be said for any agile developer who has to transition to a more traditional waterfall method.

    Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.

    *gasp* They've uncovered our conspiracy!

    As Blakey says, Agile development can be done wrong, and when it is done wrong, it can have disastrous consequences. You're far more susceptible to scope creep, and you still need to look at the big picture in order to determine if you are actually achieving the overall goal of the project. I [i]have[/i] seen a lot of scope creep and schedule slip in agile projects, but guess what? Waterfall methods slip a lot, too. Anyone who touts Agile development as an end-all-be-all method is an idiot, just as anyone who touts waterfall development as an end-all-be-all method is an idiot. They each have their places, their pros and cons, and as long as you know the risks with each and make an informed decision on how to proceed, you're going to succeed.



  •  Agile is just a series of small, overlapping waterfalls with no end in sight.



  • @dhromed said:

     Agile is just a series of small, overlapping waterfalls with no end in sight.

     

    I've always imagined Agile as several mini-waterfalls, or waterfall as a long, drawn-out Agile featuring additional enterprisey components to progress slowly and carefully - but been corrected by several people that it's NOT THAT AT ALL!

    Then when they explain what it really is... they describe the model I've mentally constructed.

    Anyways. To summarise: I felt Voke were talking utter bollocks. I just wanted to see if anyone agreed with their points and could recount experiential evidence supporting their claims... and it seemed not.

    As you were, people. Thanks for the input.

     



  • @Cassidy said:

    I've always imagined Agile as several mini-waterfalls, or waterfall as a long, drawn-out Agile featuring additional enterprisey components to progress slowly and carefully - but been corrected by several people that it's NOT THAT AT ALL!

    I agree with your (and dhromed's) characterization of agile. Of course, different methodologies have their little differentiations, but those are less important IMHO than breaking the problem down into smaller chunks. I suspect that these several people were focusing on those extraneous details instead of the difference in scope that waterfall vs a single agile iteration / sprint / whatever implies.

    @Cassidy said:
    Anyways. To summarise: I felt Voke were talking utter bollocks. I just wanted to see if anyone agreed with their points and could recount experiential evidence supporting their claims... and it seemed not.

    Well, I will say that with agile, it's easy to go down rat holes and lose focus of the end goal. OTOH, you get much quicker course correction, since the end users are getting their hands on actual software, which of course can save tons of time (or prevent outright failure) in rework once the users finally realize what they're getting.



  • Agile is really only viable if you have strong developers. The more competent a developer, the more they can do something on the fly, and on the fly is pretty much synonymous with agile.

    The great risk, as repeated in this thread, is that you indeed easily lose sight of the goal and can't really pinpoint when a project is finished. You're going to to have to finalize work at some point, but this is hard if the project method explicitly allows clients to keep coming with requests.

    In short, it's a false dichotomy, and barring mismanagement, a project can only be "too agile" or "too waterfall".



  • @dhromed said:

    Agile is really only viable if you have strong developers. The more competent a developer, the more they can do something on the fly, and on the fly is pretty much synonymous with agile.

    I suppose. But I think you could apply that to any methodology with slightly tweaked justification.

    @dhromed said:

    The great risk, as repeated in this thread, is that you indeed easily lose sight of the goal and can't really pinpoint when a project is finished. You're going to to have to finalize work at some point, but this is hard if the project method explicitly allows clients to keep coming with requests.

    The never ending money train!

    More seriously, though, this isn't necessarily a drawback. Obviously, it depends on the project. An avionics package obviously needs to be complete. An ERP-like system may need to be constantly evolving as the organization does. This is especially true for service organizations. The agile methodology is pretty simple to adapt to later life cycle phases.



  • @boomzilla said:

    @dhromed said:
    Agile is really only viable if you have strong developers. The more competent a developer, the more they can do something on the fly, and on the fly is pretty much synonymous with agile.

    I suppose. But I think you could apply that to any methodology with slightly tweaked justification.

     

    I'm trying claim its complement, I guess: juniors/idiots are incapable of functioning under agile, since it requires good judgement and some autonomy and maybe a sprinkling of improv (comedy), but they're useful as codemonkeys if the spec is sufficiently large and airtight.

    DISCUSS

    @boomzilla said:
    Obviously, it depends on the project. An avionics package obviously needs to be complete. An ERP-like system may need to be constantly evolving as the organization does. This is especially true for service organizations. The agile methodology is pretty simple to adapt to later life cycle phases.


    Software is never done, so all things are agile, in a way.



  • @dhromed said:

    I'm trying claim its complement, I guess: juniors/idiots are incapable of functioning under agile, since it requires good judgement and some autonomy and maybe a sprinkling of improv (comedy), but they're useful as codemonkeys if the spec is sufficiently large and airtight.

    I might counter that they do better on small tasks. You can have these in either agile or waterfall. I suppose things like pair programming can also help bring them along (again, not specific to any particular development model). IME, waterfall is often less likely to have a good, detailed spec at the level to which I think you're referring. When going over everything, it's really easy to skim over some of the details. And many of the tasks end up being bigger than they would in agile, where you're constrained by time, so you generally have to have smaller units of work.

    @dhromed said:

    Software is never done, so all things are agile, in a way.

    Now you're just trying to pick a fight with the authors of the report.



  • @dhromed said:

    The great risk, as repeated in this thread, is that you indeed easily lose sight of the goal and can't really pinpoint when a project is finished.
     

    You could set some stage boundaries relating to payment or increase in capability to determine when a particular project finishes.

    I'm guessing you're equating "finished product = finished project" and as a product never "finishes" in the Agile world, there's no end to a project. However, there will be some longer-term goals ("add this new module", "deprecate this functionality") that could use Agile as a way of staging the overall change into smaller chunks but there will be a point at which some signoff and payments be made.

    Weak, I know - but you either see one Agile iteration as a project (highly unlikely) or you group together a collection of agile-related changes into a project. It's doable, but somewhat artificial.



  • @boomzilla said:

    I might counter that they do better on small tasks. You can have these in either agile or waterfall. I suppose things like pair programming can also help bring them along (again, not specific to any particular development model). IME, waterfall is often less likely to have a good, detailed spec at the level to which I think you're referring. When going over everything, it's really easy to skim over some of the details. And many of the tasks end up being bigger than they would in agile, where you're constrained by time, so you generally have to have smaller units of work.
     

    The supposed great differences between agile and waterfall dissolve with every new post in this thread, don't they?

    We're probably just doing it wrong.



  • @Cassidy said:

    Weak, I know - but you either see one Agile iteration as a project (highly unlikely) or you group together a collection of agile-related changes into a project. It's doable, but somewhat artificial.
     

    If one breaks a big job into component tasks — as is the only correct way of going about it — is one not in fact producing a set of agile projects?



  • @dhromed said:

    The supposed great differences between agile and waterfall dissolve with every new post in this thread, don't they?

    I don't think so. There's a massive difference between doing little chunks (that includes requirements / design / development!) and getting feedback at each step and doing all of your requirements before your design before your development before your customer gets any working software.

    @dhromed said:

    If one breaks a big job into component tasks — as is the only correct way of going about it — is one not in fact producing a set of agile projects?

    It certainly sounds similar. But again, a critical difference is setting up all of those tasks before hand and then executing, vs having a rough roadmap and applying course corrections as the tasks are completed. I guess the difference can seem subtle on paper, but it can be really massive in practice.



  • @dhromed said:

    If one breaks a big job into component tasks — as is the only correct way of going about it — is one not in fact producing a set of agile projects?
     

    Yes. Seems obvious, doesn't it?

    However, a PM may argue that they're breaking a project up into a set of agile tasks, and someone believing that agile is a magical silver bullet may argue that they don't need the bureaucracy of project management slowing down their nimble stuff.

    I'm not disagreeing with you, just pre-empting how it may be perceived in some organisations.



  • @boomzilla said:

    But again, a critical difference is setting up all of those tasks before hand and then executing, vs having a rough roadmap and applying course corrections as the tasks are completed.
     

    I get it.



  • @dhromed said:

    @boomzilla said:

    But again, a critical difference is setting up all of those tasks before hand and then executing, vs having a rough roadmap and applying course corrections as the tasks are completed.
     

    I get it.

    I am global expert on software methodology and have also studied Roger Pressman's book from end to end. Humanity nature is full of fail, so mythologies will never work with. It is easy to be inducting some kind of culture that promote rewards and punishes bad behaviour. That will fix us developers.



  •  Spectate.. is that you?



  • @boomzilla said:

    But again, a critical difference is setting up all of those tasks before hand and then executing, vs having a rough roadmap and applying course corrections as the tasks are completed. I guess the difference can seem subtle on paper, but it can be really massive in practice
     

    I had the dubious honor of working on a real waterfall project a couple years ago.  It was doomed before it started because top management promised the delivery date (end of January) to the customer before the requirements were even analyzed/documented, there was only one business analyst and one developer familiar with the system and the whole rest of the team had to be recruited, and they waited until October to pull a team together, the team consisted of "warm body" contractors (including myself in that) from body shops who had to get up to speed on what the system actually did.

    So with that "promising" start, we started work.  I have to say that along with being mandated to be a waterfall project, this was in a company with HUGE regulatory restrictions, political oversight (yes, I mean senators and such!) and repercussions for anything that might go wrong, and as a result they enforced quality gates and approvals on everything.  Even the documentation had to be in a very precise format, reviewed and approved before anybody could cut code. 

    It took the team three months just to get the business requirements documented and approved. Then the system analysts started their portion of the work, which was to rewrite the business requirements into high-level system requirements.  That was my role.  If not for the quality gates and an asshole supervisor, the task would have been web-surfing and collecting a paycheck.  Instead it was quite difficult to reword the requirements in just the right way to satisfy the AS, and in the right format to pass the quality gate.  I was nearing completion of my work in late February; yes, one full month after the non-delivery of our project for a hard "do it or die" deadline.

    While I was working on my task, the whole team was getting intense pressure to turn back time and deliver in January; which meant that the PM was alternating between crashing the project schedule and fast-tracking it (neither solved the problem - duh), the developers were trying to sneak into writing code before they were supposed to, and the poor PM was going from meeting to meeting with different executives who wouldn't budge - one group was "we MUST pass the quality gates and use the software development methodology, NO MATTER WHAT" and the other group was "we MUST deliver this in January, no matter what".  

    In the first week of March, they fired the entire project staff (which if you'll recall was all contractors anyway) and replaced us with other contractors from Accenture.  I was the last one let go, so that I could do knowledge transfer to the new team.  I never did hear if they delivered in January.  It was a breath-taking example of project failure, and the WTF's were almost uncountable.



  • @jetcitywoman said:

    top management promised the delivery date (end of January) to the customer before the requirements were even analyzed/documented

    @jetcitywoman said:

    Even the documentation had to be in a very precise format, reviewed and approved before anybody could cut code. 

    So... the documented requirements were optional, but if they did exist then they must adhere to this precise approved format?

    That computes.

    @jetcitywoman said:

    one group was "we MUST pass the quality gates and use the software development methodology, NO MATTER WHAT" and the other group was "we MUST deliver this in January, no matter what".  

    Did either group actually meet in the same room at any point in time? It sounds like the age-old problem of having two different (isolated) bosses with different requirements that pull in different directions. Apparently it occurs frequently in mom-and-pop shops.



  •  No, documented requirements were mandatory, it's just that the executives felt they knew what they were and how long it "should" take to implement them.  The typical C-level hubris.

    And pertaining to your second comment about bosses with different requirements:  spot on, except that this wasn't a mom and pop shop.  It was a very large corporation in the finance industry.  Even corporate monoliths have this problem, except it's worse to deal with because it's harder to (locate and then) stomp into each of their offices to smack heads together.



  • @jetcitywoman said:

    Even corporate monoliths have this problem, except it's worse to deal with because it's harder to (locate and then) stomp into each of their offices to smack heads together.
     

    One particular strategy is to identify key decision-makers out of the possible stakeholders then arrange a meeting with those names on the premise that non-attendance implies non-commitment (and no further involvement from that particular party). Those that do make the effort to attend can all thrash out their vision in one place and collectively agree upon the project deliverables.

    Those that don't attend or cannot find a way of providing their input can get sidelined by those that are in situ.

    I know it's tricky to get heads bashed together, but this "Berlin Wall" syndrome only crops up when you find yourself the go-between. At some point those that deem themselves important enough to the project should demonstrate their level of importance by a commitment to the decision-making process (meetings, etc).

    It's been somewhat successful for me - those that can't make the meeting because of something more important suddenly found the time when I let them know they were marked down in the "doesn't see it a priority - doesn't need to be involved" column.



  •  Ooh, hardball.  I like you!



  • Ok, let's now understand we are dealing with people, members of staff, who implement a product.

    I am going to assume we have people who are very skiled in their field:

    - Business analysts who are very good at business analyst, knowing the market, etc.

    - Project managers who sit between BAs and the development team, I presume. Never sure exactly what they do.

    - Developers, i.e. coders. What I am, essentially. I am most productive when I am writing code. Yes, I have to understand a spec, but I should spend most of my time writing code because that is where I am most skilled and most productive.

    Now we want a model where:

    - A developer joins a project near the start, not necessarily right at the start of the planning phase, but soon after. The sooner you get developers in, the quicker you can get code written and the product released. Remember that from a business analyst point of view, the best time to release is now because they are analysing the market as it currently is and what it currently needs and not predicting for the future. Most of the time, anyway, even though I am not one of them...

    - Developers get down pretty quickly to writing code. Of course they need some guidance as to what the project is about, but then all code is there to serve a purpose.

    - Developers are not spending the beginning period of the project doing analysis for months, then doing design for months, then getting down to coding, then stop coding to do testing.

    - Not sitting around for weeks waiting for documents to get signed off.

    It doesn't need any silver bullets. If your staff are not productive the process isn't working properly.

    Agile is supposed to address this. You therefore break down requirements into small steps and perform "sprints" whereby you can reach a certain goal in a shorter period, with chances to change course depending on what you discover along the way. You will often start with proof-of-concept coding whereby your developers are in some way "experimenting" with how the application might work, at least in some areas.

    Used to achieve these goals, agile works well. If the process isn't working, change it. A book can give you ideas that might work for your company for your product, but there isn't one rule fits all because not every application development environment is the same. For example, internal office software is likely to have a far more frequent release cycle than anything that is sold commercially (albeit that some applications seem to be forever having updates, and insist on keeping some stupid service running on your computer that you didn't ask for to check for them).

     

     

     



  • @Cbuttius said:

    I am going to assume we have people who are very skiled in their field:
     

    BWHAHAHAHAHAHAHA! What? No, really?

    Nnnnn... bwwwhhhahahaHAHAHAHAHA!

    (sorry)

    @Cbuttius said:

    - Developers, i.e. coders. What I am, essentially. I am most productive when I am writing code. Yes, I have to understand a spec, but I should spend most of my time writing code because that is where I am most skilled and most productive.

    I would refine the role "developer" - many architects, coders and testers all come under this banner but are roles with different skillsets and objectives.@Cbuttius said:

    - Developers get down pretty quickly to writing code. Of course they need some guidance as to what the project is about, but then all code is there to serve a purpose.

    - Developers are not spending the beginning period of the project doing analysis for months, then doing design for months, then getting down to coding, then stop coding to do testing.

    Last part, true. However, there needs to be an architecture element: "you must design it before you build it; you must know what it should do before you design it" - else coders could rush into building the wrong thing. The analysis & design element doesn't need to take months, but it does need to be done at some point - and the role of the Proj Manager is to ensure those activities are fulfilled to the required quality.

    @Cbuttius said:

    Used to achieve these goals, agile works well. If the process isn't working, change it.

    That, generally. I actually find most issues are people issues. Often the problem isn't with computers or processes, but those that use them.

     

     

     



  • I worked on a failed agile project a while back.  It failed due to managements insistance on the individual iterations being flexible.  The priorities would suddenly change mid iteration, and I mean completely change.  Eventually management decided iterations were too inflexible those were tossed out.  Things relating to presentation took precedence over the core.  6 layout redesigns in one year took priority over everything else. Why? Because maybe it would look better in blue or pink! Or spacing was off between text. This required removing all resources from development until this was done... I do agree presentation is important but in this case it was like building a house without a foundation or any support walls inside.

     That being said it wasn't truly an agile project anymore.  And agile should not be blamed for the failure.  



  • With agile, it's always a "no true Scotsman", isn't it.

    Yeah, Agile didn't fail, they just did it wrong.

    So many red flags.

    So many.



  •  As I see it, the problem with any methodology is that there are too many immature and selfish people at the higher levels who can throw their weight around demanding that things get delivered yesterday based off requirements that are mind-read from them on a constant basis.  And anybody who can't work that way is the problem.



  • @jetcitywoman said:

    requirements that are mind-read from them on a constant basis. 
     

    What?

    I thought everybody working in IT got one of those tiny Link thingies on the side of their skull. Didn't you? It's really cool to just pull data from the Hive.

    It' so cool.

    The Link is great.

    It's the best.

    Yes yes.

    Wheee.



  • @dhromed said:

    @jetcitywoman said:

    requirements that are mind-read from them on a constant basis. 
     

    What?

    I thought everybody working in IT got one of those tiny Link thingies on the side of their skull. Didn't you? It's really cool to just pull data from the Hive.

     

    I'm sorry.  Didn't you get yours?


     



  • @da Doctah said:

    @dhromed said:

    @jetcitywoman said:

    requirements that are mind-read from them on a constant basis. 
     

    What?

    I thought everybody working in IT got one of those tiny Link thingies on the side of their skull. Didn't you? It's really cool to just pull data from the Hive.

     

    I'm sorry.  Didn't you get yours?


     

    When did the unobtrusive and unnoticable babelfish/TARDIS universal translator go out of fashion?


  • @PJH said:

    When did the unobtrusive and unnoticable babelfish/TARDIS universal translator go out of fashion?

    Turns out it doesn't work with WS-*...

    (something about being completely devoid of any actual semantics)


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.