1. 26
  1.  

  2. 12

    Scrum frees you to be dumb about your process. That’s great, it lets you save brainpower for the thing you actually want to do.

    I don’t understand the point about single-function teams. If you don’t have product teams there’s no way your team is delivering customer-facing functionality every two weeks, which means you’re not doing scrum.

    Continuous delivery is great, and not incompatible with scrum. But sticking a date in a calendar does one very important thing: it gives you a point at which to step back, reassess, and realise that a particular deliverable has gotten bogged down and needs to be rescoped. In a pure-CD environment without that, it’s easy to fool yourself that you’re still “working on the most important thing” and it’s just taking time, as the days stretch into weeks, months or years and you’re not delivering anything.

    1. 11

      I’m no fan of scrum. In particular, I think it makes long-term work extremely difficult. But this rant mostly sounds like the usual “technology X is making people stupid” argument (which dates back at least to when X == “writing”). Perhaps it would have helped had the author at least glossed the arguments he references.

      But perhaps not, since the “wealth of research” on sprints making people dumb are about poverty, and poverty’s effect on cognitive capability. Charitably, a gloss would have given him the opportunity to explain how lack of income and pattern-matching mapped to scrum and development. Uncharitably, the author didn’t expect anyone to click the links.

      Even internally, the author is with one hand condemning scrum practitioners as having broken memories, and with the other condemning any developer who uses her experience to improve her ability to estimate a task.

      Finally, the core thesis (that “continuously delivering the most important thing in the simplest way” (emphasis his) is the ideal methodology) is vacuous. The whole point of a methodology is to help identify 1- the most important things, and 2- the simplest ways to get them. And the whole point of agile methodologies in general is to get the results delivered 3- as quickly and predictably as possible.

      It makes the entire article sound akin to someone weighing in on an argument about the merits of Fermat’s and Euler’s factorization methods with “too much math makes you dumb, why aren’t you just factoring??”

      1. 1

        Charitably, a gloss would have given him the opportunity to explain how lack of income and pattern-matching mapped to scrum and development. Uncharitably, the author didn’t expect anyone to click the links.

        He makes the point about scarcity being with respect to time. So in the author’s view, that’s the poverty aspect.

        While I find the point compelling, I think the article is a too sensationalist for my tastes. Not everything in Scrum is “dumb” and saying “continuous delivery” doesn’t mean much of anything in and of itself. It doesn’t tell you how to structure or run a team. It’s almost as meaningless as saying “be Agile”. (You point this out as well.)

      2. 8

        “Dogmatic process fads make you dumb”

        Perhaps because I’ve never been directly exposed to Scrum certified trademark official guru wizards, I found a lot to like in “Scrum”, where it is a collection of ways to organize and operate on ongoing work. The ordered backlog is a great tool for communication, stand-ups are an efficient way to keep teams in touch and on track, and I’ve not once found sprints useful, so I’ve only used them once.

        Take what works. Leave the rest. Move on and do good work. Repeat.

        1. 2

          I think the backlog is great, but I don’t think that’s exactly what people mean when you say scrum.

          Or in other words. Making a prioritized todo list and working through it almost certainly existed before scrum.

          Depending on how you do scrum it might actually be hindering that it is setup in such a static way. There are tasks that make sense to group or parallelize, because a task involves waiting times or because you already look at code, system, etc.

          Another thing in defense of these methodologies: People when they start Scrum they sometimes tell a little bit of history and benefits over other system. At least to me it often sounds like many people simply approach it from the wrong side, as it tries to shorten cycles of getting together and planning from something like month, half year or even longer cycles into two weeks or so.

          Many younger companies and certainly developers who didn’t work in a company already start out from a lot of syncing and very agile development style.

          Again, this is just from what people that introduced at companies I worked, but since a big part of the presentation involves explaining that more agility which can be achieved by scrum a main weakness seems to be that it tries to break down something that in smaller (ie. not IBM, Microsoft, banks, etc.) pieces, which I totally can see as a big win over an environment that is stalling because every project has a huge planning stuff and things are potentially hard or even impossible to change for a long time.

          So people seem to emphasize frequent syncs and comparatively frequent planning/roadmap meetings. If you actually put that on top of something that already features these in such a way that there is no problems and people don’t go out of sync, work on solutions that are known to be pretty much deprecated already and people just know what to do, communicate and so on, then don’t implement scrum in the hopes it will magically give you any kind of boost.

          Of course everyone wants to optimize, but maybe the process isn’t the thing that would make stuff better. Maybe there are other problems in the company/project. Your process might be just right. Maybe you lack motivation, a clear vision, people, infrastructure, resources, etc. While I am sure that there are situation where at least resources can be added with scrum (ie fewer hours are wasted), that isn’t always the case.

          When things don’t work out, it’s always easy to blame the process, because it usually doesn’t hit a person directly and nobody really feels blamed upon, but if the actual reason lies somewhere else scrum won’t help you.

          1. 1

            In my experience all recurring problems are, or reduce to, process problems. Or at least you’d better hope they do, because process is the only lever you have to change them. Hiring better people or fixing specific issues works for small companies, but that approach can’t scale to a large company.

        2. 6

          Technology management seems to be a bargain bin for management ideas (and managers) that failed elsewhere. Just as doctors are highly intelligent but the favorite targets of financial scammers (rich, overconfident, financially clueless due to lifetime residence in educational/hospital meritocracies) the technology industry seems to be a preferred destination for those peddling bad management ideas. Everywhere else, Jack Welch style rank-and-yank has been agreed to be counterproductive. Not in tech. In software, it lives on.

          Scrum is Taylor’s so-called “scientific management”, which worked poorly in factories and is a disaster in software.

          I saw a company kill itself with Scrum. Scrum set off a talent bleed in software that couldn’t be stopped. Core business functions suffered because of the software attrition. It was bought for less than 10% of its previous valuation. Stories like this are common.

          1. 2

            Everywhere else, Jack Welch style rank-and-yank has been agreed to be counterproductive.

            Scrum is Taylor’s so-called “scientific management”, which worked poorly in factors and is a disaster in software.

            What are your favorite texts on those two points? I’m interested.

            1. 2

              I saw a company kill itself with Scrum. Scrum set off a talent bleed in software that couldn’t be stopped. Core business functions suffered because of the software attrition. It was bought for less than 10% of its previous valuation. Stories like this are common.

              On the other hand, every badly implemented management switch can kill companies quickly and lead to bleed. What in this case was scrum-specific?

              I’ve seen companies break on scrum and some thrive on it. (the latter ones always being ones that were un-dogmatic and seriously weighting time/gain)