9 ms·

This may vary from region to region, but my biggest issue with the present Agile trend is the cargo-culting of SCRUM. Sprints, standups, reviews and retros, pla

• electrotype 8y ago
  Amen
• ChrisSD 8y ago
  The irony being that agile was meant to be a rejection of blindly following a ONE TRUE WAY. A major point was to periodically review your processes and adapt them to better suit your situation. The idea being you don't get locked in to a process that's no longer working and even have some freedom to experiment.
  • gonzo41 8y ago
    But I'm telling you people!, the earth revolves around the sun. ---Burn him!!!! We're currently swallowing the Scaled Agile Framework pill and I honestly think that it's cause maybe 3 serious episode of depression and burnout in 7 person team. We failed a sprint a while back. No one knew you could do that until we did. So at least we're learning.
    • arcbyte 8y ago
      SAFe is actually fine if you choose an appropriate level and follow the practices. It's ridiculous how people read that SAFe is "tailorable" and then promptly do something that is in no way Safe. Every single day i tell my coworkers to RTFM
      • kitotik 8y ago
        SAFe is probably the worst offender of what the article is focused on. I can’t think of a more anti-agile statement than ‘RTFM’. A more productive statement might be ‘Update The Fucking Manual’.
  • beaconstudios 8y ago
    Yeah but management consultants can't sell that as easily as they can sell a pre packaged "agile" solution like they do with SCRUM. Fundamentally, agile requires processes that are at odds with traditional management, so companies that sell buzzwords to traditional management aren't going to push anything that requires real behavioral change from the senior team.
  • zaarn 8y ago
    Agile is the ONE TRUE WAY to not follow a ONE TRUE WAY.
    • aptwebapps 8y ago
      Only the Messiah would say he's not the Messiah!
  • blumomo 8y ago
    > The irony being that agile was meant to be a rejection of blindly following a ONE TRUE WAY. The same holds true for all religions. However many believers nowadays defend it as there was only one true way.
    • ajnin 8y ago
      That's not quite true, the 3 major monotheist religions of the world insist that they are the only true one, and if you don't believe that very bad things will happen to you.
  • epicide 8y ago
    Exactly. Depending on the team, I usually try to start off using something mostly by the book and we adjust from there. Some teams need more structure and some suffocate under it. A business has to understand that the processes that are best for software delivery are orthogonal to the ones that are best for business. Namely, (good/agile) software development demands fluctuation and iteration where business plans seem to thrive on long-term forecasts and projections. Waterfall would absolutely be the best things for businesses... if it worked.
• i_made_a_booboo 8y ago
  Yup. I've come to realize a few key things: 1) Humans have an extremely limited capacity to determine what's true. 2) Our modus operandi is not to determine what is true but with which side are we politically affiliated 3) The truth is of little importance This plays out exactly like you describe. A cargo-cult. You're either for or against it. You are either on the political side of the divide that believes being in the cult is better for ones survival or you are on the side that believes deep introspection about what is better for the situation at hand is best for survival. Close to nobody has the resources or capacity to evaluate if it's actually a good idea or not and even less so the political clout to sway the group for or against. So cargo-cult it is, for better or for worse. TL;DR The state of any development methodology you can give a name to and dogmatically adhere to: a shambles.
• lmm 8y ago
  The original manifesto still stands up today. As the article says, the problem is fake "agile" that's actively against genuine agile.
  • JoeAltmaier 8y ago
    Some argue No True Scotsman. That is, any agile process can be faulted so we keep searching for a pure agile somewhere (that actually works). If true the lesson is, agile doesn't work anywhere (or nearly nowhere)
    • lmm 8y ago
      But there is a clear definition: the manifesto. Following the manifesto works. Not following the manifesto doesn't work, even if you call it "agile".
      • JoeAltmaier 8y ago
        Agile has to work with actual human beings. Holding up the dogma and saying 'well perfect people would succeed' is more One True Scotsman. If nobody is a True Scotsman, what is the point of Agile?
        • lmm 8y ago
          I've seen it succeed, in a lot of places, and the difference between places where "Agile works" and places where "Agile doesn't work" seems to be that the places where "Agile works" are the places that actually put even a token amount of effort into actually doing it. Like, in one of these threads I saw someone saying that standups were a bad idea because in their standup the manager sat down and the meeting took for 30 minutes. That isn't a problem with doing a standups, that's a problem with not standups. I mean there is clearly some kind of genuine problem here, agreed, but the problem I see is "why do these people think they're doing Agile when they're doing literally the opposite of everything in the definition". I'm genuinely baffled. Is it a cynical lie from managers, or the consultants they hired? Do they genuinely believe they're doing it, and if so, how did they come to think that? Did this happen with other methodologies - did you get companies that claimed to do e.g. RUP or Six Sigma but were actually doing the opposite of everything those methodologies prescribed?
• LandR 8y ago
  I used to work at a place where we had to do retros at the end of every sprint. But people would try to theme them? e.g. World Cup themed retro, describe how the sprint went for you as one of the World Cup teams. Christ, really? What nonsense. It just ended up with cringey comments as people try to shoehorn something into being world cup related (or whatever the theme was). Just silly.
  • arethuza 8y ago
    "describe how the sprint went for you as one of the World Cup teams." I'd be tempted to say "I was Scotland - we didn't qualify" ;-)
    • AnimalMuppet 8y ago
      I'd be tempted to say "I'm long since out of junior high, so I'm going to skip the silly games and just tell you what happened."
• tootie 8y ago
  Jeff Bezos once warned to "avoid proxies" and using fake scrum is a prime example. Scrum on its own is just a proxy for agility. Scrum done correctly can give you great agility. If you're running stand-ups and using a backlog but are unable to iterate quickly and deliver incremental value then you're failing at your actual goal. Of course, agile itself can be considered a proxy because the ultimate goal is always customer value.
  • deleted 8y ago
    [deleted]
• notyourday 8y ago
  > Agile trend is the cargo-culting of SCRUM After my last gig I firmly believe that agile is a cargo cult: every morning sales and marketing did a standup. In a circle. At the peak about 50 of the org members.
  • hliyan 8y ago
    Actually, the original principles of the manifesto are all solid: http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html It's "scrum" that appears to be the problem...
• bitL 8y ago
  That's why there was a post-agile movement already like 5 years ago, but due to overwhelming bandwagoning of clueless PMs trained in "Agile" by big-bank "consultants" that stream seems to have died out.
• Joeri 8y ago
  It has almost become a religion and any attempts at advocating planning discipline or detailed designs (even in domains where it's called for) are quickly labeled and rejected as "waterfall". Some project managers trained in agile methodologies have trouble grasping some basic common sense project management practices such as dependency tracking and capacity planning. I've seen it go wrong in both ways. One project did BDUF and then planned it out as a 2 year series of sprints, delivering increments. The scrum master's job was to keep an eye on this macro-schedule and make small course corrections along the way to keep things on track. There were weekly demo's, but since there was no slack in the schedule there was no way to act on the feedback unless the next sprint involved building out the same set of screens. That project went ridiculously over budget, and ended up so unsuitable for the customer's needs that they didn't adopt it. Another project avoided doing any design up front, because "that's not agile". In the course of the project it became apparent that several key architectural decisions were wrong due to requirements which were known at the start and which would have been apparent had an up-front design been made. These proved very costly to rework. My conclusion is: (1) if there are requirements set in stone up front, do the design work necessary to fit those requirements at the start, and (2) don't translate that design to a schedule, but instead to a prioritized backlog, then go one sprint at a time without planning too far ahead. Management tends to get really jumpy at the last bit. They want to know the whole scope for the whole cost, up front, and that doesn't fit into an agile way of working. (It doesn't fit into any way of working, which is why so many projects go over budget, but that's a whole different can of worms.)
  • hliyan 8y ago
    > (1) if there are requirements set in stone up front, do the design work necessary to fit those requirements at the start This is quite true. I often frame this as "design detail is inversely proportional to requirements volatility"
  • poulsbohemian 8y ago
    >Management tends to get really jumpy at the last bit. They want to know the whole scope for the whole cost, up front, and that doesn't fit into an agile way of working. This is the delicious irony... management loves the idea of agile because finally those pesky developers will stop pushing back on the schedule with all their requirement demands and lengthy estimates! Go fast, weekly sprints! Daily updates! What do you mean you can't tell me the cost without gathering requirements? I saw so many organizations use Agile as a way to beat developers over the head, then be surprised at the anarchy that resulted.
• sametmax 8y ago
  I really wanted to agree with you, but your comment is mostly criticizing people doing agile without understanding it. And yet, you 3 points prove that you don't understand agile either. If feels like a bad driver honking at other cars. All the points you cite are useful, but they are nowhere what agile is. The most important thing about agile is __the emphasis on communication and a short feedback loop__. You deliver things in small testable chunks because it's easier to ochestrate a team around that, and you get feedback sooner. You refine weekly based on how things went because you can thanks to the regular feedback you get. You let others know ASAP because you have regular communication. You are making the same mistake as everybody: thinking agile is about a process, and hence, rules. It's not. Agile is a set of principles, which then you use to implement whatever rules and so, process, you need for your current situation. SCRUM is one way, XP is another. Your agile and mine won't be the same. Mine today won't be the same as the one tomorrow. Because what matters is communication and short feedback loops, and there are many ways to get that. Sure, you can use proven tools and receipes. It's good. We all do it. But it's no more agile that using a good knife is cuisine.
• eudora 8y ago
  This has been my experience exactly. It's a little shocking how common the groupthink was, and no one dared speak against it, so it's nice to see people speaking freely here. Agile makes me want to leave software entirely.
• dapithor 8y ago
  I would argue Agile is a Philosophy and Waterfall would be more of a Methodology. My biggest concern with Agile is that it's lacking integration with a methodology (ie: best practices of waterfall could be in an agile way). Companies and teams tend to just say lets do Agile/Scrum/Kanban and leave out the requirements definition, documentation, etc and replace it with "As a user create shiny button". Which, might be fine in some cases but as a new-start it lacks direction IMO.
• eksemplar 8y ago
  This is exactly why agile failed, it became a religion and stopped being a tool you could modify as needed. Like SCRUM, we use kanban boards to handle projects, but a lot of our projects are so small that one guy can build the project in a week or two. Like a registration form for scheduling phone calls, you need a front end form, a backend api and integration to outlook. The first time we build one it took longer, but now we can have one up and running in a week or two. We place that on our kanban board and we talk about it SCRUM style, but it’s not it’s own project and it’s not broken in to every step of the SCRUM methodology either, because if we did that it would probably add a week of agile project management. But since we’re not doing that it means that we’re not agile or using SCRUM, because we’ve bent it to our needs and broken it’s golsen dogmas. Now I give quite a few management talks on this, and as soon as you admit that you’ve broken agile to make it fit, a line of others forms to confess. Because I don’t think I’ve ever met anyone outside of academia or extremely large tech projects that actually followed any of the agile methodologies to the letter. So agile is just as silly as waterfall, maybe even more so because it turned out that the analysis part of waterfall is often still extremely useful if you’re mixing your tech with HR stuff like benefit realisation, and let’s face it, who in digitisation isn’t? I mean, we’re digitizing to increase efficiency after all, and nothing screams benefit realisation more than that.
• setquk 8y ago
  I’ve noticed, still after a decade, people who know what they’re doing will self organise into an “agile ish” way of working similar to the points you make. If you prescribe it you end up with a mess every time. Agile occurs naturally if you’re team isn’t dysfunctional. If you have to force it in, its dysfunctional.
  • beat 8y ago
    I disagree there. Chaos occurs naturally. Agile takes real work and discipline. Cowboy coding isn't agile.
    • setquk 8y ago
      No. An organisation buys in “agile” as an ideological solution to a lack of disciplined professionals. Disciplined professionals self organise. No ideology is ever discussed even if they use it. The difference is focus. And that’s crazy important. I’ve been at this for 20 years and watched both successful and unsuccessful teams. The most successful team are not ideologically or process driven. And quality, time to market and technical debt is orders of magnitude lower than any externally applied agile class process which is purely focused on delivery and compartmentalisation.
      • beat 8y ago
        I've been working on and off with formal agile since 2002, and worked on "disciplined professionals" teams. You know what is disciplined? Formalizing a process and following it, even when it's inconvenient or annoying. Getting by on talent, high bandwidth communication, and sufficiently small scope might work, but don't call it "discipline". It's luck and narrowly defined circumstance. Try using that method on a $50M enterprise project with 100+ developers and see how far you get before you choke to death.
        • conradfr 8y ago
          I wonder how humans even got to the Moon without Scrum.
• koonsolo 8y ago
  All you need is a proper retrospective. And that's basically it. In a proper retrospective, you can change anything you want, improve every step. So all the problems that you mention, can all be addressed and improved, just as long as you have a good retrospective. Don't like planning poker? Do something else. Don't like standups? Change it.
• petr25102018 8y ago
  I guess that SCRUM should have not been adopted as a mainstream/default agile process. I think that SCRUM can work for some teams, but it should be a niche in the world of agile development. The problem is that people take it as a "best agile practice/process for every team". That is IMHO the biggest issue here. I wrote an article about my experiences with SCRUM which I named "Why SCRUM doesn't work" :-) You can read it here: https://stribny.name/blog/2018/05/why-scrum-doesnt-work https://stribny.name/blog/2018/05/why-scrum-doesnt-work I'd be interested in any opinions about this.