1. 30

  2. 27

    “Why did you choose soda instead of seltzer? If you didn’t consider seltzer, you didn’t choose soda, someone else chose it for you.”

    Replace “seltzer” anything you like. Lemonade perhaps. Or water. Or ribena. If you drink soda without considering ribena, you didn’t choose soda.

    It is a common fallacy among smart people that they can get perfect information and make a perfect decision. In reality, your decisions have to be made on what you know. Your options are only the ones you have in your head. Maybe you should explore more options, but you don’t need to consider or know about every option before making any choices!

    A common mechanism in pursuit of decisions is soliciting advice from others who might know of other, unconsidered options. Do that. But don’t shame others for their sufficiently made decisions.

    1. 11

      I feel like you’re focusing on one throwaway line that doesn’t have anything to do with the meat of the article.

      1. 5

        It’s the hook. And it’s a bad one.

        I liked the article. It was fine.

    2. 10

      I’m generally suspicious of anyone selling a process that has a name. There’s nothing wrong with borrowing a little from Scrum, a little from Kanban and a little from waterfall, as long as it works for the team/org. All processes are a bag of practices that each have trade-offs.

      1. 3

        And to add, most processes are arbitrary when it comes to a “best process” (hence why there are infinite to-do softwares). Pick a process and standardize and fluctuate to the business needs as best you can.

        Non-obvious optimizations and efficiencies are secondary to an operating team.

      2. 8

        I like Scrum for the same reason the author derides it: it’s training wheels.

        The same way I have a preferred stack for tech, a preferred set of business metrics, and everything else, when I roll onto a new team I’m invariably going to try to get us to something that’s basically Scrum as soon as feasible. It’s okay leaving some performance on the floor at start if doing so lets me start training the business how to interact with engineering and product.

        Good teams with good managers can get Kanban to work super well, but the same things that make Scrum inefficient also (in my experience) make it more robust in adoption on an underperforming team or next to the howling vortex of crazy that is business.

        You shouldn’t stick with stock Scrum for longer than you have to, but if you need to bring relatively quick order to the org with something that’s pretty well documented, you can do a lot worse as a starting point.

        1. 5

          The difference is that Scrum completely ignores your process’ nuances and tells you exactly what to do and how to do it.

          This is not true. This is the whole reason behind retrospectives - the whole point of Scrum is to iterate not only on the backlog but also on process. I know I’m venturing into “No true Scotsman” territory here, but anyone who continues to follow dogmatic scrum’s starting point just for the sake of following a process really isn’t doing scrum correctly.

          Managers who master Kanban’s principles don’t need training wheels. Whether they’re riding a bike or a motorcycle, they’ll just need a few laps to understand the circuit, optimize their strategy, and overtake competitors.

          The author has revealed a deep misunderstanding of scrum.

          Scrum becomes even more harmful when managers create their own flavour of Scrum. When that happens, managers turn an inefficient yet sound framework into an inefficient and defective process. That’s because they didn’t pay attentions to the dynamics which made “by-the-book Scrum” work.

          How does this not directly contradict “Once you understand these principles, you can tailor them to your particular situation and obtain much better results.”

          I find this reason to adopt Scrum extremely ironic. It’s ironic because the way Scrum makes work visible is by adopting a Kanban board.

          Post-it pads on whiteboards existed long before Kanban and even before Scrum.

          1. 2

            Post-it pads on whiteboards existed long before Kanban and even before Scrum.

            Whiteboards were uncommon before the 1990s and the adhesive used on Post-it notes was not invented until 1968 whereas Kanban was around in the 1950s.

            1. 1

              I started my career in software development in the mid-1990s, and at least in my part of the world, whiteboards were very commonplace.

              And fine, if a red index card in a parts tray indicating that the assembly line needs more washers means that Kanban boards predate Scrum, I suppose you can have that. My opinion that the author of the article has a misinformed view of Scrum is unchanged. Suggesting that the only good thing about Scrum is the Kanban board, and using that as an argument for Kanban, still made my eyes roll back in my head.