29 ms·

Agile projects have become waterfall projects with sprints

• swader999 4y ago
  They are if you allow it. I haven't had to put up with waterfall since 2007. Interview carefully, deliver good work to gain trust then read them the riot act if you have to. And if you can't change your Company, change your company.
  • kyriakos 4y ago
    Unfortunately more companies are as the op described than truly agile.
    • swader999 4y ago
      I've had a lot of good work arise from these kind of companies. They fail on a critical project and call in the fixers.
• AlexandrB 4y ago
  Just once in my career I'd like to work on a project that resembles the original intent of agile. So far I've had 3 jobs that "did agile" and in each case there was a long list of requirements and a fixed deadline many months in the future for each "agile" project. No one wants to hear "We don't know when we will deliver X because we're working on Y this sprint".
  • superchroma 4y ago
    I've had one and it was by necessity as we were building something new and we were a tiny company. It's great when it works.
    • shortstuffsushi 4y ago
      This has been my experience as someone who has worked at a variety of large and small companies. Do you have a (generally B2B) product to market, with fixed release increments, and features set by some external marketing / sales team? Your agile is probably going to be "that agile." Are you a small company developing a new product that you don't fully understand yet as you're still developing it? Your agile will probably be closer to the experience people are seeking.
  • kube-system 4y ago
    > No one wants to hear "We don't know when we will deliver X because we're working on Y this sprint". You need a good PM who knows how to handle this for you. I did agile correctly in a large bureaucratic organization because our PM shielded us from those requests, and basically told the business that they could prioritize the requests appropriately in the next sprint planning session. If they showed up and participated, they got to duke it out with the other competing business units about who got priority. If they didn't show up, we told them that their work was not prioritized because they failed to attend the planning session.
    • lumost 4y ago
      All this really means is either - You can only ever work on projects which are finished in one sprint. - You have no idea how, when, or even why the big initiative you're working on will finish. It's not practical to build a business this way, what happens when one team pulls priority and a different one next week? what happens when a multi-sprint project becomes a multi-year forever project? You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy. At best, the absence of autonomy for an individual in a scrum team might be the point of the whole process.
      • user_named 4y ago
        Your first point is exactly true. We design concepts with certain goals in mind, then that gets cut down into something that takes one or two sprints of work "to see the results", which never come because it does not even cover mvp use cases. Then the rest never gets built. Absolutely lack in long-term thinking, goals and vision.
      • kube-system 4y ago
        If you have a large project, you break it down into smaller parts. If you know what needs to be done, throw it in the backlog, give it a broad estimate, sort it, and you have an estimate for about how long it will take. If you have unknowns, make resolving them a task. If you need things from the business, give them tasks. > It's not practical to build a business this way, what happens when one team pulls priority and a different one next week? Someone has to own the project, and have the final say on priority. If the project is at risk due to shifting priorities, you need to escalate this to them for a final decision. > You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy. If you have everything in your backlog, you can judge velocity to come up with an estimated timeline given all of the assumption at the current state. This isn’t a promise, it’s an estimate. When the business shows up to sprint planning and sprinkles around new ideas for high priority tasks, you always remind them that this means deprioritizing other tasks which will affect timeline. > what happens when a multi-sprint project becomes a multi-year forever project? Yes, at the end of the project you will likely have done something very different than what you originally put in your backlog, because the business will have changed their minds 100 times. This is the point! The point is to track close to building what they want, not to build what they wanted 8 months ago.
  • woutr_be 4y ago
    In one company that proclaimed to do “agile”, our release was suddenly halted by the business, because they came up with some new requirements. These were regulatory requirements they of course long knew about, but only now decided to throw at us, because “agile” and it’s an ongoing product. All good and well, except that they now demanded the product to be released within two weeks, because that’s when the marketing campaign went live. Of course, our PM and scrum master, just went along and put us all into a room, to estimate and figure out how we could deliver. All our estimates were proclaimed wrong, and we had to estimate again, eventually devs just gave a number to make it fit within the two weeks. Needless to stay, the product did not launch, and the developers got blamed for not being flexible enough. That’s how agile works in big companies, use agile as a term for everything wen it fits, use it as a way to blame others. Scrum masters are just there to pass along communication from the business, and absorb complains from developers. It’s just another one-way street of communication.
    • the_af 4y ago
      > All our estimates were proclaimed wrong I've seen something like this happen, and I must wonder. The only ones that can give an estimation are the people who will actually do the work. This estimation will likely be also wrong, but it's their job and their estimation. How can anyone else dispute it? Very tempted to reply "well, how about you do it in two weeks then?". I never do, because I want to keep my job. And nobody is ever punished for missing deadlines, anyway.
      • irrational 4y ago
        They dispute it because they assume that developers are padding their estimates. You know, it will probably take 2 weeks, so double it and then double it again.
        • ahtihn 4y ago
          If developers consistently miss deadlines and the business consistently pushes back on estimates, maybe the original estimates weren't padded? This should be fairly easy to communicate to the business people.
  • eyelidlessness 4y ago
    I’ve worked on three teams which have to some degree been agile in spirit. The first didn’t really have a planning philosophy at all, and was mostly agile in spirit by virtue of that other than when crunch time got really chaotic and stressful. The next took a minor opportunitistic rebellion to achieve, in the midst of a significant culling of management and a sympathetic view from one of the remaining leadership. My current job is thematically between the two and surprisingly adaptable even while being conscious of pressures. All of these have been unusual work environments so I’m not sure I have reproducible insight to offer (though the second case probably is more reproducible than not at all, and I highly encourage anyone with the opportunity to throw down and choose your own planning adventure to coordinate with your team and see what shakes out; you have nothing to lose but your estimation poker hand).
  • de6u99er 4y ago
    There's nothing wrong with a full backlog. And also not with a deadline defining when something should be available. Sometimes such deadlines come from third parties (e.g. retirement of an already deprecated API version), a larger corporate program that requires multiple projects to deliver in sync, or opportunities based on external factors where marketing is already concentrating on a specific date, ... My approach is the MVP way, where the team delivers everything that is necessary to meet the customers goals. All the bells an whistles can be qdded once those goals are met. If the goal can't be met within the given timeframe, then it's a problem of unrealistic expectations. But most of the times we have met the deadline while otheres with their bloated waterfall projects were late.
• lkrubner 4y ago
  I recently wrote about my experiences here, and especially, what makes a great project manager who can move a project in a flexible way. I quote myself: -------------------- What about Scrum, Agile, Kanban, PMP and CAPM? At this point many of you will be wondering, where is the conversation about all of the formal methodologies? Some of you will think it’s strange that I’ve written a whole chapter about project management without mentioning Scrum, Agile, Kanban, PMP and CAPM. ...I have not personally noticed that credentials (such as Scrum Master or PMP) are necessarily associated with real skill as a project manager. Rather, the key things that make a great project manager tend to be more qualitative: • Does this person have the moral convictions necessary to take a tough stand against upper management, for the benefit of the overall company? • Does this person have the confidence necessary to fire a poor performer for the benefit of the overall team? • Does this person have the perceptiveness to correctly read team members and know when they are lying or boasting? Certain people gain these attributes as they gain experience, but these attributes tend to be things that are not emphasized in formal credentialed courses. Strong moral convictions tend to be picked up in childhood and are only learned slowly in adulthood. In formal credentialed courses the focus on various rote processes tends to shift the focus away from the things that are really important.
  • deleted 4y ago
    [deleted]
• quickthrower2 4y ago
  As the meme says: Alway was
• superchroma 4y ago
  Described my current gig to a T except our useless project manager outright said he doesn't believe in agile and runs everything from excel. He came from a defense contractor and it shows. Everything has fallen apart, we've been late on every release, lost huge contracts and now we're outsourcing work to India, but, inexplicably, he still has two brand new cars and just bought a hobby farm. The bastard. The only thing he did in response to failure was to pivot us to feature driven development, and then he screwed that up by not clearly defining teams and muddying responsibilities. Pick your jobs carefully or be prepared to walk away :(
  • spaetzleesser 4y ago
    “feature driven development,” Enjoy! All your problems are solved.
    • oblak 4y ago
      You know what I'd do if I had a million dollars budget? I'll tell you what I'd do, man, two teams doing Feature Driven Development at the same time, man.
• the_af 4y ago
  I don't know if I agree with every sentence in TFA, but this is obviously true: > "Soon there will be a new project methodology that will promise to deliver software projects on time and on budget. It won’t work, but we will all have fun learning new terms and joining a new methodology cult." I think everyone here will agree this will happen. Again, and again, and again.
  • someweirdperson 4y ago
    For the next on we need something that uses the terms "back-propagation" (blah ... self-correcting planning ... blah) and "blockchain" (blah ... ensures to meet estimates ... blah).
• shrubble 4y ago
  A funny enough YouTube video (comedy) and really, it kind of reminds me of the agile methodology in the large company I worked at ... https://www.youtube.com/watch?v=bB340S0tGf8 https://www.youtube.com/watch?v=bB340S0tGf8
• mbesto 4y ago
  I mean, yes, thats literally what it is. Hilariously we attribute waterfall from Royce[0] in which he visually shows a waterfall like process, only to describe it as an iterative process (and essentially agile scrum). > still makes projects late. But under the concepts of the agile manifesto there is no concept as "late" so I'm not sure why the author refers to a project as being late. The whole point of an agile process is to be able to iterate quickly. 2 weeks is a generally accepted timeframe in which you can revert attention if what you develop is incorrect. So whats the gripe? [0] - http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...
  • hedora 4y ago
    Running waterfall on a two week cadence burns out engineers by forbidding them from doing any work with a timeline greater than one week. After all, half a week is burned, minimum, at the beginning and end of the sprint on process paperwork and screaming at disconnected Zoom windows. Next sprint, their week of work is frequently reverted or irreparably hacked to meet an arbitrary deadline. Also, the product sucks, but management metrics ensure people that focus on shuffling the titanic deck chairs instead of fixing it get promoted. If a group of engineers puts in a heroic two month effort to save the project, their metrics tank, and they end up reporting to the first group until their options run out or they are laid off.
    • BLKNSLVR 4y ago
      Metrics. The way the MBAs will throw the world (further) into a meat grinder. My wife is a teacher and she was telling me that a panel who was responsible for hiring a new permanent teacher was "not allowed" to consider their prior knowledge of the applicants' teaching abilities, and had to go with the teacher who best answered the Department of Education's paperwork questions. They chose (against their personal better judgement) the worse of the two teachers because "on paper" they appeared better. I'm currently struggling to find a job (my current contract ends in a couple of weeks), and I just don't have the ability to be the level of ass-kiss dishonest, straight-laced, official textbook answers that seem to be what lands the fish. I'll get something eventually, and that's all I want, but it really feels like the world is tuned to the sizzle even when you can smell that the steak is rotting.
• zerop 4y ago
  With Agile, I find more ceremonies than actually work - Planning, estimations, Re-Planning, Cross Prioritization, Retro, Ticket Updates, Blockers, Blah, blah...
  • BLKNSLVR 4y ago
    Our daily "15-minute" stand ups regularly tip over to 30+ minutes. This should be a sign that the team needs to be split up, as more than half of the stand-up is discussion of topics that are totally unrelated to my context. It stops my momentum, annoys me, which ruins my motivation.
    • rexpop 4y ago
      So... why do you put up with it?
      • BLKNSLVR 4y ago
        12 month fixed term contract, which is up in a couple of weeks. ;)
    • chii 4y ago
      > more than half of the stand-up is discussion of topics that are totally unrelated to my context. or the team is doing too much at a time, and delegating different "projects" to different people in the name of efficiency. I think that's actually wrong - the whole team should work on the "same" task. For example, coding a module could be done together. It might seem like only 1 person is writing code, and everyone else is over the shoulder looking, but you save knowledge transfer times in the future, and you save code review time (you do review at the same time when everyone is there).
    • deckard1 4y ago
      I had a manager that gave me shit for not being verbose enough. And our stand-ups were already in that 20+ minute territory. Why do we have a Jira board if no one wants to read it? It's all right there! No blockers. Next.
    • 4y ago
• jasongi 4y ago
  I think one of the main reasons for wagile is that software development is often seen as capital expenditure rather than operational expenditure (or R&D, although companies love saying it's all R&D to the tax dept). CapEx assumes a fixed(ish) upfront cost and then an ongoing maintenance cost afterwards - which means that you need to be able to estimate the upfront expenditure. In reality, software development doesn't fit neatly into this model. It's part R&D, part operational expense and part capital expense all at once (even in maintenance phase) - but it's impossible to distinguish which parts are which. The resulting product's value is constantly in flux, which means it is difficult to plan depreciation like a traditional asset. Agile will always fail unless the way software is accounted for changes too, because the people at the top are looking at budget spreadsheets, not JIRA boards/burndown charts.
  • handojin 4y ago
    Basically a new thing has been introduced into the world and the world has tried to fit it into an existing paradigm and when it doesn't fit, well let's invent a new paradigm that looks like the old one but better... The problem isn't how the business solves software. It's how software dissolves the business.
  • growse 4y ago
    > I think one of the main reasons for wagile is that software development is often seen as capital expenditure rather than operational expenditure Depending on where you are, you might find that allocating expenses as capitalisable is much more tax-efficient, hence the desire from the business (finance, specifically) to treat it that way.
• BFLpL0QNek 4y ago
  Even 10-15 years ago I was at a small Thoughtworks event where Martin Fowler was speaking and back then he was using the term “Water-Scrum-Fall” saying most Agile projects he’s seen are waterfall projects wrapped in to two week sprints. At the time Agile/Scrum didn’t have the popularity and only just gaining traction at larger companies. Today everywhere I work is now “Agile”, doing scrum or similar. It’s all lip service, it’s just another process and ceremonies over the actual spirit and ethos of the original manifesto. The teams I’ve worked on who didn’t practice agile where actually the most “agile” in the spirit of the manifesto. The teams that did agile, by the book, with the ceremonies and all, dogmatically, doubling down on it, where the least agile in the spirit of the manifesto and not that productive or creative, often micromanaging every tiny detail in a Jira ticket.
  • colechristensen 4y ago
    Having worked in actual "waterfall" (which is just a perjorative term) environment in the defense industry long ago, scrum is quite a bit worse in overhead, amount of nonsense, waste, inflexibility, etc. Agile/scrum is a codeword for "we don't want to / know how to / haven't ever experienced long term planning, but we're going to do it anyway".
    • badlucklottery 4y ago
      Yup. If you're at a shop that is openly waterfall, they do the requirements gathering and design/prototype work up front so the planning is based on something approaching reality. "Scrum" has become waterfall without the pre-work so it often descends into iteratively pulling estimates out of your asses.
      • xeromal 4y ago
        And the worst part about it. Holding your ass to the flame over your shit estimate.
      • mrwh 4y ago
        Definitely my experience of Scrum! In my part of a FAANG we do a sort of sloppy waterfall and honestly it's the most effective method I've found.
• mruniverse 4y ago
  I think it'll only work if the people paying for the product want an agile project. And that they understand agile to mean the same thing as the engineers. That is to say to small deliverables within a short period. Review the small deliverable with client, make adjustments, then repeat until final product is done. Basically get things working a small piece at a time. Change directions if needed. Don't boil the ocean. What usually happens is that the clients take "agile" to mean changes on-the-fly AND quick delivery of final product. They also usually prefer the waterfall deadlines, because then can line things up for Q2, Q3, etc. I think a big reason for the disconnect is the word "agile".
  • Aeolun 4y ago
    Yeah, it’s like biz reads ‘agile’ and sees it as a buzzword for ‘everything we want’ instead of taking the word at face value.
• Joel_Mckay 4y ago
  Witnessed agile/DevOps degenerate into resource constraint paralysis far too often. In general, such approaches are not appropriate for every project... even if you are not the one paying for the billable hours. The Module pattern design built into many languages like Python is perhaps why some folks get away with it for awhile. ;)
• clumsysmurf 4y ago
  I think the reason why Agile worked, back in the days of the Manifesto authors, is not because of any specific thing in that Manifesto ... but because you had a small team that could decide how they wanted to work. This is antithetical to most corporate management.
  • freetime2 4y ago
    Also presumably they were experienced engineers who could be trusted to make good decisions. But not all teams are like that. I have worked with many engineers who are completely lost, or will routinely make the worst decision possible, any time the requirements are exactly spelled out for them.
    • chii 4y ago
      agile will not fix the problems of incompetency in engineering (or stakeholders for that matter). But agile is often sold as a tool to fix such incompetencies i reckon!
  • drewcoo 4y ago
    Little a agile was supposed to be an iterative system that the team could adopt and adapt to their needs. These forms were intended to make developers more effective. The manifesto was so small and stark because those were the few things that all of the manifesto signatories could agree on. They were trying to find consensus on principles that made products successful. Big A Agile is much more rigid and top-down, marketed to management. Success there means selling training and certifications. Nothing more.
  • mongol 4y ago
    Also, they were thought-leaders with an interest in exploring better ways of working, and presenting what they found. As such, they surely adapted themselves and bent some rules. They were not following recipes in some book about Agile. But if you look at agile coaches preaching on LinkedIn, there is an endless stream of posts about the true way to do agile.
  • bluGill 4y ago
• mianos 4y ago
  I call it 'Wagile'. Everyone uses all the agile buzzwords yet all the project management is focussed on estimates and hard deadlines. To me the most disturbing part is people read the 'Agile Manifesto' and say, "yep, that's what we do", yet for every item it is the exact opposite. For example, "people over process" seems to be addressed by considering every team member identical and focussing purely on the tickets. I am to the point now where I think corporate 'Wagile' is the Agile process and I simply don't understand what it was years ago.
  • watwut 4y ago
    What you describe has nothing to do with waterfall and is simply agile. Literally nothing in what is supposed to be waterfall prevents specialization or treating people nicely. However, multiple agile methodologies explicitly prevent specialization and explicitly are tickers focused. They do it for a reason, to be fair. But, it is ridiculous that for how long agile existed, every single uncomfortable or dysfunctional thing about any agile process gets blamed on waterfall. No. These are all issues with agile methodologies. Agile manifesto is just feel good document meant to make you buy into the process in abstract. It is inspirational, but that is all there is to it.
    • mianos 4y ago
      So, it seems to me, you are saying that we should not be taking any notice of anything clearly stated in the Agile Manifesto. Next time someone says to me "Don't bother telling me about the real work, just keep the ticket time spent updated", I'll keep that in mind. (A real quote from an Professional Agile Practitioner to me).
• watwut 4y ago
  Waterfall - the mythical process that if ever existed it was 30 years ago, but we bring it up when we want to make our 30 years old process sound hip. And when we don't want to say agile both often massive sux and also is the normal way of doing things for decades.
• Apocryphon 4y ago
  I wonder if there’s one of those observational “laws” that states that any idea, no matter how flexible and open-ended, must eventually harden into a rigid unthinking cargo cult. As a corollary, all ideologies end up as self-parody, contradicting their original intentions in sometimes egregious ways. > The retrospectives are gone Oh, they’re still there, they take like seventy-five minutes, they do produce some good observations, aired-out grievances, and action items, the latter of which are never ever followed upon in full or even half.
  • wheelinsupial 4y ago
    John List, an economist, has a new book out called The Voltage Effect: How to Make Good Ideas Great and Great Ideas Scale [1]. I think it address your point in a more general way and has identified some failure modes that lead to a negative end state. [1] is a summary of the ideas from the author. [1] https://nextbigideaclub.com/magazine/voltage-effect-make-good-ideas-great-great-ideas-scale-bookbite/32783/ https://nextbigideaclub.com/magazine/voltage-effect-make-goo...
• progre 4y ago
  This classic Yegge piece is almost 16 years old now and seems to describe more or less the same thing https://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html?m=1 https://steve-yegge.blogspot.com/2006/09/good-agile-bad-agil...
  • quacked 4y ago
    Phenomenal article, but I'm frustrated by his focus on Google, because it implies that you can only do 'Good Agile' when you have more money than God and no deadline. Although, perhaps that was his point.
    • antod 4y ago
      In that timeframe a lot of his blog posts related to the experience of moving to Google - eg comparisons with Amazon etc. It's now apparent that Google is both very a different place in recent years, AND that all the "Good Agile" stuff from 15 yrs ago kinda screwed most of their products and reputation long term.
  • antod 4y ago
    One part of that post that hasn't aged well is the praise Google's launch culture got. 15yrs of hindsight later and it has probably become the biggest product pathology cliche identified with Google.
• bamboozled 4y ago
  From my experience, there is usually a fundamental lack of trust and communication problems behind all of these project management approaches and initiatives. Ultimately it all stems from anxiety about the potential for a date to be slipped or something to not get delivered. It's not about peers, it's about tracking everything in a ticketing system so nothing is missed. In practice, the only thing that ever really happens and I've never see anything deviate from this is as follows: 1. Product team wants something feature or new product 2. A plan is formulated to get there, often by a certain date with engineers present. 3. An individual or team is entrusted with the delivery of said imitative 4. People go off to do the work to make it happen. Often for months, often without a ticket associated with the work, they just want to get their work done. 5. If you're lucky, the senior resources on the project will flag any issues as they arrive or foresee them. 6. A the end, if everyone isn't too burned out, it's nice to have some time of retrospective about how things went. Ideally through this process, there is a lot of open and healthy conversation about the progress and status of the work. Anything outside of this is really almost always just cruft, a distraction and leads to bad feelings because the people who need to get the work done are distracted with silly things like poorly ran daily stand ups. Sometimes things make it so the project is late, no level of agility or number of waterfalls can avoid the sometimes inevitable so it's better if product acts under the assumption things might not always be on time and have a more flexible marketing schedule etc. None of this would be a problem, except now there's a lot of anxiety about not "doing agile", or waterfall or something...
• ppeetteerr 4y ago
  Sounds like someone is working at a growing company. Agile is great when you can be agile. Not every busyness fits into that mold. Some software projects are big, regulated, public, etc. They need more structure. For instance, you don’t update the cloud provider at a 500 company with agile. It takes planning, coordination, contingency plans, and often 2-3+ year timeline. Agile is for smaller companies or smaller projects that can be broken up into sprint size pieces. Many are not.
  • yomkippur 4y ago
    It's also produced needless stress and bullies that manage scrum. Maybe that's what you want in a business to get stuff done on time.
  • willsmith72 4y ago
    "Agile is for smaller companies or smaller projects that can be broken up into sprint size pieces. Many are not." Just not true. I know it's hard to know if you haven't seen it but I assure you it's possible and much for effective for a large team to be truly agile
    • ppeetteerr 4y ago
      Can you back that with some proof?
      • aliswe 4y ago
        i call cap too. agileis the way to go, but requires focus, lots of communication and a concrete foundation of trust. that does in fact not scale well, in that angle.
  • BoorishBears 4y ago
    You're just applying the concept at the wrong scale. Honestly I hate the term agile, it should really be "open communication", and it can apply on even a daily timeline Waterfall "style" is a directive comes from on high to get every service running on the new cloud provider, and 2 years later those on high find out we're still 2 years away from completion and along the way we spent months working on tiny aspects of it because the directive couldn't capture every nuance. Agile "style" is where you get to return feedback to "on high" before that point. If there's a service that represents 5% of our revenue but required 30% of the effort, you get a chance to push back and talk to stakeholders before committing that. - It's really the idea of "further unraveling uncertainty as you go along instead of assuming you accounted for all of it at the start" that makes agile useful, and that can work on any project of any scale. No matter how rigid the parameters of a project, at some level there's uncertainty (otherwise you'd have perfect estimates and nothing would ever be late). So better that "on high" learns more details about that uncertainty as you go along, and you get input on how to handle that uncertainty... than in a giant "we're flailing" moment later down the line. I think people focus too much on the whole "no committing to deadlines" idea, when that is not at all central to the value proposition, and honestly feels like a feel good platitude that doesn't actually work when it meets reality regardless of how small you are
• allisdust 4y ago
  The worst part about agile is it has become whatever each company wants it to be. Product owners dominate the pace and direction of development often to the detriment of engineering quality. At least in waterfall model, there is some one like a program manager or delivery manager taking overall responsibility for delivery and coordinating dates with stakeholders. With agile and scrum, there is no one taking responsibility for achieving things. Often product owners end up doing this for which they might or might not qualify for.
  • drewcoo 4y ago
    > The worst part about agile is it has become whatever each company wants it to be. Actually, the point of agile is that it should become whatever the team needs it to be. Also, scrum is an agile methodology, not a separate thing.
• Nursie 4y ago
  They always were. Worse even, 'agile' gets used as an excuse for project managers and architects not to document requirements or plan properly, even in situations where all the goals can be known ahead of time, because that's a lot of work. It's also rife with "It's not working? Clearly what we need is more interference, more monitoring by management, hire more 'agile coaches' to inflict more 'ceremonies' on developers and use even more of their time." Never mind that planning is always thrown out of the window because priorities shift. Never mind that none of the changes that were identified as necessary in the retro get any sort of management buy-in, rendering it pointless. Never mind that 'stand-up' has become a management-run progress-report session. Never mind that this kills the feedback loop and developer-lead benefits that are supposed to come from this. No! Do more agile! Whatever the hell that means! Do it harder!
  • drewcoo 4y ago
    > Worse even, 'agile' gets used as an excuse for project managers and architects not to document requirements or plan properly, even in situations where all the goals can be known ahead of time, because that's a lot of work. What's the complaint? The higher ups have a scapegoat, so they're happy. And you can rejoice in it not being you or any of your friends!
• psi75 4y ago
  The problem is that programmers answer to idiots, but nevertheless those idiots have certain reptilian sensibilities in which they exceed us, and a consequence of this is that they have a knack for zero-sum power grabs and pissing contests. So, even though those people are 30-50 IQ points below us, they nevertheless end up remaining on top, and there isn't really much we can do about it unless we're prepared to burn down a whole socioeconomic system (which I am, but most people aren't there yet). "Sprints" are supposed to be humiliating. The very message is that you're not trusted with even two fucking weeks of your own (!!) working time. It could not be clearer. If you work in sprints, it's because the higher-ups think you're a child and a loser, and you'll never be able to overcome that negative inference, because if you perform poorly you will confirm it and if you perform well, you will confirm that their micromanagement actually works--there is no winning. Also, "Waterfall" never really existed. It was a straw man invented to sell this Agile bukkake. In any case, a number of the dysfunctions are, in effect, intentional. Standups that go on for 45+ minutes? Long meetings are a classic way for managers to punish perceived underperformers (or, in Agile terms, "impediments") when they're not entirely sure who problem player is. The theory is that the rest of "the team" (I put this term in quotes because coworkers in corporate aren't an actual team--that's just management speak--but are often pitted against each other) will get sick of the incessant meetings and rat out the underperformer who is causing this wastage of time. The humiliations of Jira and "user stories" aren't bureaucratic accidents that occurred in good faith; they hurt because they're supposed to hurt.
  • drewcoo 4y ago
    > Also, "Waterfall" never really existed. That part is true. > It was a straw man invented to sell this Agile bukkake. That part is colorful, but retconning. A fellow named Royce coined the term in 1970 and used it as a strawman for common project iteration organization (V-model?) a the time. I agree with most of the spirit of the rest of the parent's screed, though not with all the details.
• cloudking 4y ago
  Having managed agile projects at startups and big tech, there's a few problems that were common: 1) lack of customer feedback loop - agile is meant to ship features quickly to customers, get feedback, and iterate/enhance/pivot based on their feedback. Often times the projects were simply things that "had to be done" and the whole agile process was not necessary. 2) inaccurate estimation - projects would start with asking engineers to estimate "t-shirt size" efforts on user stories, and what happened in reality is the projects always ended up taking longer than expected due to unknowns, dependencies etc. I've only worked with a few senior engineers who can accurately estimate, but junior engineers starting their careers in a big company, it's a tall order to ask them to be accurate.
  • willio58 4y ago
    As I have taken on more senior roles I’ve learned how to estimate better and most of the time it’s just estimating much more time
    • theshrike79 4y ago
      Good old Miracle Worker formula. Take your original estimate and double it. =)
    • antupis 4y ago
      Initial estimation * 2 is my way nowadays.
      • rmnclmnt 4y ago
        Golden formula of time estimation!
      • aliswe 4y ago
        How unscientific - 3.14 is the way to go.
        • antupis 4y ago
          shitty the boss with excel yelling about bad estimations -> add more pi-decimals.
• WheelsAtLarge 4y ago
  I've found that there's no single method that works well over time. Agile gives you crappy code and a stressed team and water fall gives you late projects. I generalize. People want to blame the method of project management but it comes down to the team and the project manager. There's a reason why project managers get paid so well in every field. They know how to manage a team while bringing in the project on time. It's a hard job. What method is used is not as important.
• resonious 4y ago
  I think what makes or breaks a team is not so much "is it agile or is it waterfall", but more cultural and difficult to quantify. My fairly small team of ~20 tried all kinds of kanban, sprint, standup, scrum or whatever and have converged on something amusingly waterfall-like where we design stuff upfront then just bang it out. We have open communication, so if we hit unexpected snags, you can just talk to product or bizdev or dev and sort it out. If product is getting anxious about progress, they just ask and the devs give an estimate (or even a demo). I guess business is kinda like a marriage where just talking about things openly solves quite a lot of problems.
• quacked 4y ago
  I have found a simple rule useful: if you know what the end product will look like and how it should behave, you're not "doing Agile", and there's no point in pretending that you are. If your PM or client can look at a piece of software and say "this doesn't behave like we expect it to" or starts asking "when can you have that done?" (and they're referring to any unit of time smaller than a quarter-decade), batten down the hatches and start writing requirements. The last job I worked at still had defined features, test cases, and release dates for its projects, but since they were "Agile" they stored all of their "user stories" (read: free-form requirements that needed to be built according to a literal separate design document) in Jira tickets. I worked there until the urge to play in traffic became too strong.
• matchagaucho 4y ago
  Quite simply this comes down to business users not wanting to know how the sausage is made after all. They want their food cooked fast, but don't really care how. We manage 2 different conversations at all times (agile and waterfall): Internally, the Chefs in the kitchen agree on Mise en Place practices, prep time, and have strong confidence then can run 100% regression tests and deploy at anytime. The overhead of TDD, technical debt (sharpening the knives), and retrospectives are kept internal. Externally, the customers don't care about the ingredients or process. We encourage business users to take the waterfall view, think through their requirements, discuss menu options, set delivery dates and formal acceptance testing criteria. It's not that development teams aren't doing agile. But the Agile Manifesto's ideal that Developers and Product Owners would all sit down and speak the same language turned out to be less than practical.
  • matchagaucho 4y ago
    Keep in mind the Agile Manifesto was not a list of absolutes. It was a list of values that accept waterfall practices, but with a preference to do things slightly differently. https://agilemanifesto.org/ https://agilemanifesto.org/ "That is, while there is value in the items on the right, we value the items on the left more."
• osigurdson 4y ago
  Agile is pretty silly. Waterfall is ridiculous. Instead, start with a good vision of what needs to be built (if you don't have that, maybe don't even start). Then focus on the product, not the process.
  • galangalalgol 4y ago
    I think what you just described is what the agile manifesto described. Valuing working code over tools and processes to paraphrase. Scrum and kanban are not agile. Because agile is not a process. Process is for people who can't accept accountability.
• legitster 4y ago
  Worse. At least with waterfalls, you are starting from the end goal. In my experience, most Scrum is the worst of both worlds - you are kept on a rigid/bureaucratic process but are not allowed to think about the end state. I recently had a kerfuffle with a manager when I brought up the idea of a novel solution to a time consuming problem and proposed doing a quick proof-of-concept. I was told not to work on anything until we have requirements. "How will stakeholders know to submit requirements for something they don't know is possible?" "Well, we can't to any work unless it is submitted for approval in an Agile way".
• peteradio 4y ago
  Anybody ever heard "we don't plan that would be waterfall, we are an agile shop". It was at that point I knew it was over at my last gig.
• theshrike79 4y ago
  The point of Agile is to give power to the team and also to use The Process to protect them from ad-hoc management interference during sprint. 10 The stakeholder says which features are the most important and gives the team a prioritised list. 20 The team goes through the list and determines how much work each will take. At this point the stakeholder might be asked to re-prioritise. 30 Team picks tasks from the top of the list for each sprint and shows the result to the stakeholder after the sprint in a demo. GOTO 10 That's it. If someone from outside the team has "a quick request" that needs to be done ASAP, the scrum master shows them the prioritised list and asks them what features should be dropped. If the someone is stupid enough to pick something, they can go wrestle with the stakeholder(s) of the deprioritised tasks about whose thing is more important. The team doesn't see anything of said quick request, they can focus on their sprint. If the stakeholder has any "quick requests" The Process says all work for the sprint is to be scrapped (no one really does it, but you don't tell that to the customer) and the sprint is restarted with the "quick request" included. In my 20 years in the business, zero customers have taken the "scrap the sprint" route. But none of this will work unless an expensive enough consultant can convince the higher ups that it's a good idea. If they're not with the process, you get scrumfalls, 45 minute standups and other crap.
• fn1 4y ago
  Important fact about the waterfall model, that no-one ever talks about: The authors thought it was important to actually do it twice [0]. Of course, nobody in the big corporate/government world wanted to pay a second time for work that has already be done, so most of the projects failed and continue to fail. [0] https://en.wikipedia.org/wiki/Waterfall_model#Royce's_final_model https://en.wikipedia.org/wiki/Waterfall_model#Royce's_final_...
• throwaway787544 4y ago
  Yes, we know this. We've known this for a long time actually. Nobody has yet proposed a better method. - The agile manifesto is a smattering of nice-sounding principles with no suggestion of how to achieve/implement them. - Scrum is an over-prescribed, subtly-complex theoretical workflow from the 1980s that was carried forward in the absence of any alternative other than Waterfall, in the same wake that created TDD, XP, and other now-ancient methods that we pay lip service to. - DevOps came and went like a fart in the night. Was supposed to result in better outcomes for developing and running software projects. It's now literally a cargo cult. People who have no idea what it is, saying that they "do" it. If you have a suggestion for a better way to work, by all means, someone please blog about it, I will read it. But please no more blog posts about how Agile or Scrum don't work. We have a decade of those posts already.
  • buscoquadnary 4y ago
    I will say that my favorite new methodology can be found here: http://programming-motherfucker.com/ http://programming-motherfucker.com/
    • throwaway787544 4y ago
      That's interesting actually, because it seems written by a contractor. Each role in each industry probably has its own warped methodology, which means a "better" methodology will need to be tailored to the role & industry. So we might need 40 methodologies, not one.
    • suprfnk 4y ago
      I find that very shortsighted. Unless you're working on your own pet project, programming is like 20% of the job. The other 80% are designing, communicating, and collaborating. You will not ship complex business software by just "Programming, motherfucker". You will build the wrong thing if you talk to the customer for one hour and then go off on a mad programming frenzy for the next 6 months. You need constant iteration and feedback (agile), or completely up front agreed-upon specs (waterfall), to not build the wrong thing. Both of these are absolutely not programming. Next to that: > "We are tired of being told we're socialy awkward idiots who need to be manipulated to work in a Forced Pair Programming chain gang without any time to be creative because none of the 10 managers on the project can do... Programming, Motherfucker." This seems very stereotyping. Does anyone actually experience this? In this job market? The companies I've worked at are generally very happy to have a software engineering professional in the team, and are trusting of my word/estimations. If someone would call me a "socially awkward idiot" at work, I'd have no problem finding another workplace that does respect me.
• kaonashi 4y ago
  Until you get get it through the skulls of people with the money to pay that "we have it all drawn up, you just have to build it" is a horrendously bad idea, this will continue forever.
• 4dregress 4y ago
  I guess it depends where you work because this doesn't how things have been done throughout my career.
• travisgriggs 4y ago
  I miss eXtreme Programming. If the team bought in and had some discipline, it rocked. Beck’s eXtreme Programming eXplained was my favorite book on the subject. Cunningham’s C2 was a gem of early ideas and thoughts exploring the space. And then it all slowly just eroded to crap. It reminds me of the morphology that took place with the first hundred years or so of Christianity.
  • misterflibble 4y ago
    I like the idea Extreme Programming. Well, anything at all that is different than the status-quo would be great. Actually I never considered the theological connotations of working in an Agile project!
• misterflibble 4y ago
  If I had a coin for every time someone replied to these kinds of posts with "That's not Agile! You're not doing Agile properly! True Agile is..blah..blah".....well, I'd have a few coins! I have had Agile/Scrummy Agile/FrAgile/Enterprise Fragile shoved firmly down my throat in every single job I've work since 2006. Rather than actually let the software professionals do their job, other non-technical people insist on these poor excuses for a micro-management methodology. Just this week, I was asked by our resident enterprise management consultant to put hourly estimates and actual hours worked on all of my assigned 20+ User Stories. He said "This is Agile 101! All of the best teams in the world do this! Follow the process!" Today, he wants me to add estimates and actual hours to my 20 Bugs and bug-fixes too, plus add tasks to each User Story explained what work I actually did. Nevermind that I'm the only developer 100% allocated to the project, so there's only one person to micro-manage I suppose! Shouldn't commonsense prevail in these modern times? No? lol :-P Edit: Is it possible for one to get paid just to rant about how terrible Agile is?
  • __derek__ 4y ago
    No True Scotsman is indeed a popular fallacy.
  • aliswe 4y ago
    To be completely fair, what you are describing is not truly agile :)
    • misterflibble 4y ago
      Aha! Now I'm rich! :-D
  • plaguepilled 4y ago
    As a fellow anti-agile dev, I can understand why its so prevalent. Labour estimates are crucial for business, even if they're bad - the goal is to improve iteratively over time and gradient-descend towards an accurate picture of resource allocation. Is there a better way to do this than agile? No duh, but that's another topic. :-)
• scrame 4y ago
  They always were.
• dcow 4y ago
  We've taken some inspiration from Shape Up by the Basecamp folk. We don't use Basecamp or follow it strictly, but since we had already been practicing some of the things the book advocates for, we decided to take a closer look and adopt some of their terminology. Some highlights: * 6 week cycle + 2 week cooldown * no ticket backlog * handoff between product and eng, scope hammering * fixed deadlines * integrate first then refine To me it feels like a modern blend that takes a few good things from the Agile philosophy but concedes that not everything happens in 2-week sprints in reality and that effective product people have to actually design product and buy work instead of just dump user stories into the issue tracker and tell engineers to build them all. With our team of 4, we essentially choose from a set of "pitches" 3-6 "bets" for a 6 week cycle. We then work on answering all the unknowns (e.g. "does this platform API support some requirement in the way we think it might?", or "is there a de facto library for this or do we need to build it?") and prototyping solutions for the projects. Those prototypes we share with each other once they're working (and of course collaborate along the way as needed). From the prototype, now that you actually have an engineering handle on the task, you basically resolve how much time is left in the "appetite" (allotted time for the project) against the remaining scope of work. Then you do an amazing rare thing: the engineering team cuts, or "hammers", scope until they can deliver something on time. This is very different from the norm in my experience where product tries to micro manage the outcomes of the project the whole way. Obviously things are not totally rigid and sometimes a little more appetite appears to allow something to not be hammered out of the final thing or some preferences are expressed for which project to hammer harder when competing for remaining time, but it generally works pretty well. At the end, product gets to taste what got cooked up by the chefs and then, during cooldown, decide (with eng leaders) what to pitch and ultimately bet on for the next cycle while the eng team addresses smaller tasks, monitors deployments, polishes, and fixes bugs. The key, "shape up" terminology and logistics aside, is forcing product to make up front "purchase commitments" (my term) of things they need/want in the product. This forces a lot of things that don't happen normally or happen ad hoc during a sprint to happen up front (in theory, alas no process is perfect). Somewhat secondary but also very important and close to my heart is that this methodology avoids the utterly useless and inaccurate time waste of trying to achieve task-level estimates prior to work, usually building something that nobody has every build before, has starting. It inverts the commitment so that engineers are building what the time allows rather than product asking how long something is going to take and then rightfully getting angry/frustrated when things 4x as long as the engineers said they would. It feels way more human as an engineer to be given some freedom to explore the solution space and then use your and your teams expertise to deliver a solution in the allotted time.
• mkl95 4y ago
  Agile as understood by most companies is a self-deception framework. It's a way for companies to think they are more mature than they actually are. The truth is that in most cases escaping the good - fast - cheap triangle is expensive because it involves a lot of research, and most companies either can't afford it or are led by greedy short-term thinkers. Agile can only be solved with honesty. If you want some cheap crap, you can have it, but let's not get too pretentious about it.
• jokethrowaway 4y ago
  The Agile manifesto is purely common sense: https://agilemanifesto.org/ https://agilemanifesto.org/ Read it, it will take 20 seconds. That makes sense. Now how does that turn into some monstruosity like scrum or anything else all the tech companies use, that I don't know. "Agile" in the companies is all about process (have you done your standup, backlog refinement and retro?) and deadlines. The only thing we kept is not having documentation. Great one btw, in the waterfall times we at least had an idea of what the hell was going on in a company.
• tluyben2 4y ago
  I had a large project for a new client a while ago; they had 50 devs and I was managing work of 20. They kept saying I did not understand what agile is; this way they have no control! They said. So they started more and more micromanaging this already waterfall project which they didn’t understand; daily ‘standups’ that took a lot of time and which were used to embarrass individuals who missed their estimates they put yesterday, pull tasks apart into minute subtasks and estimate them and hand out fines for people who missed their targets. Needless to say everyone was really stressed, they hated these ‘managers’ who were supposed to be on equal footing with me but were not. No one was project managing anything; the dude meant to be the PM went in such detail about useless product things that he didn’t have time to manage anything. All along this was hailed as a perfect agile project. Of course the project was fixed price, fixed deadline and fixed feature set (but no one told me that; I was hired as a freelance tech lead to make sure things were implemented properly as I worked in that field for ages). Needless to say things didn’t go as planned and I was let go for not being a team player. The project is still not live years later and all people we worked with were fired and replaced several times as well except the ‘managers’.
• enb 4y ago
  I found Scrum’s iterative approach very beneficial. In every other project without it or some other bastardisation of “scrum” there was always a major fuck around with wrong priorities, and constant reacting to every manager. Theres no point taking on Scrum if you only think it means story points and standups. In any case, I ask what frameworks (that i can read about) have worked for all of you?
• mclightning 4y ago
  Scrum and Kanban ways of working, work for different kinds of people/roles/goals. Neither are silvet bullet solutions to a problem. But scrum has a well-defined method, that works for everyone. It is managed top-down to deliver items for individuals to do. Whereas kanban needs the individual to take on whatever the work throws at them, including total failure of the deliverable by issues outside of their control. In this situation, the individual has to be empowered and trust should have been settled between managers and members of the team.
• enb 4y ago
  Waterfall projects with sprints. Releasing every 2 weeks is still way better than releasing less frequently. Yes its not ‘true agility’, but as long as you find your weakness and learn from them every 2 weeks you’re going to be in a stronger position than if you have to wait 6 months to realise you stuffed up 5 months ago
• Kaotique 4y ago
  I have never experienced a truly Agile or a truly Waterfall project. It has always been a mixed bag of approaches and ideas depending on the project, the client and team. There is a reason there are managers and planners in every company. Projects are messy in all different ways. Be flexible and keep an open mind. Try different things and figure out what works best for you.
• BowBun 4y ago
  What's interesting to me about these posts is that usually employees are complaining about their current job, or a very few experiences compared to the thousands of software shops implementing this framework with various degrees of fidelity. While your experience may suck, mine at my company has been pleasant and planning/estimates greatly help us organize and predict our work. We get the benefits of breaking down complex tasks, while throwing out anything unnecessary to us and coming to terms with the fact that estimates != time. Anything the business asks of engineering is a problem to be solved be engineering leaders without decimating the productivity of your teams. I've gone from IC to engineering leadership and while I get the arguments, most of the blame falls on poor engineering culture and management implementing things without thought. You don't have to do everything the framework tells you. Use it in spirit in a way that's appropriate to your current team and company.
• Surfactant7 4y ago
  The biggest problem the anti-Agile crowd has is that: 1. They have no replacement methodology. 2. Even if they did, it has no name. I get that lots of people dislike Agile and what it has come to mean in certain quarters. But I have yet to see a cogent, actionable response. Criticism is well and good, but changing a bad situation requires a better idea. But "leave me, the beleaguered, over-meetinged, over-instrumented developer, the hell alone" is not a methodology, and it's not something any sane business is going to sign up for. Many of the comments here against Agile really attack process itself. Not particular processes, but the notion that there is a process that is followed, the same way every time. And extra scorn is heaped on process attached to metrics.
  • o_m 4y ago
    Agile replaced waterfall, so one of the replacements for agile would be waterfall.
  • commandlinefan 4y ago
    > They have no replacement methodology. Yes, we do. > it has no name. Yes, it does - it's called the "Agile Manifesto". When MBA's do something called "Agile", they're actually doing Waterfall, but worse. Imagine if you hired a cleaning crew to clean a warehouse but, instead of sweeping up the floor, they started opening bags of garbage and dumping them on the floor. Now imagine that you pointed out to them that what they're doing is the exact opposite of "cleaning". Now finally imagine that they say, "oh, you warehouse owners always say we're not doing 'cleaning' right".
  • CRConrad 4y ago
    > the anti-Agile crowd ... replacement methodology ... has no name ... lots of people dislike Agile AIUI, there is no capital-A "Agile". It's a pilosophy, a mindset, a set of methodologies, not a brand or a product. I actually think that could be a heuristic: Talks about capital-A "Agile" == doesn't get what "agile" is about.
  • 62951413 4y ago
    Re: no replacement methodology The way I remember the RUPs and FDDs of the world they actually addressed technical questions developers cared about. Starting from XP they have all been about managerial concerns. I'm not aware of a consistent explanation for that transition.
• deleted 4y ago
  [deleted]