Why I'm not a big fan of Scrum

You could think of technical debt as the energy lost due to friction. It is the energy lost changing from one point to another in your domain space. Perhaps "technical friction" would be a better concept for software. However, that is even more hand-wavvy and harder to measure ;-)

First, as background, I'm a software engineer, not a "scrum coach" or anything, but I've been on a Scrum team for nine years and nine months. (I know, right? Our first Scrum project was Nov 2006. The set of people has fluctuated over the years but it's still a pretty tight ecosystem.) Just this morning we were requested to make videos about our team(s) to explain why we work so well, so this is pretty apropos.

Second, I really did read the article through and thought it was well thought-out. Notably, I felt they came from a different mindset than mine, a different workplace, and I am a fan of Scrum, so here are my feedback points--I hope they're considered positive, helpful and constructive:

TL;DR: I feel like the author is not empowered in his workplace. Time to upgrade your scrum team mindset.

* Remember that a scrum team is self-organizing and self-managing. Specifically, I'm replying to: "The daily standup is in my opinion a manifestation of a significant but unspoken component of Scrum: Control" implies you don't know or don't practice this and is likely the actual source of your problems with Scrum.

* You mention disliking pointing stories because they never match up with the points on tasks. Points on stories are done because you haven't created tasks yet, so you can't use task hours to add up to a story, and you need to figure out relative complexity before you start.

* Getting points (RE: "I don't get the exact response that was expected, so no points for you.") - Here, the team decides whether it gets points, not a user in a review. That sounds weird, but so does a user saying "No points for you! (soup nazi voice)" in a review. Stick with me here: If you get feedback that says you need to do significant rework, it's clear there was a misunderstanding between your product owner and the business. Make a new backlog item, point it, prioritize it, move on. (If this happens more than once consider how far apart your vision is from your user and their vision of the project!)

* Demoability as a requirement in Scrum (specifically responding to "How can you demo that your code base has become more habitable?") - Business folk understand the value of "plumbing" (pipes in your house aren't visible, but they sure are handy when you want to take a poo). They don't like showing up to meetings to talk about plumbing, though, so either skip that meeting entirely or tell them what will be possible when said plumbing is complete. Point is, don't die on the hill of demoability just to say "See! Scrum sucks! I can't demo all this plumbing!"

* Meetings every two weeks - If they're painful, you're doing something wrong. If it's not ready, it doesn't go in the demo. Don't kill yourself for a demo. It may be a "sprint" but you're still actually in a marathon, so just pace yourself well.

* You mentioned disconnected users. If you have bored users, get better about grouping the meeting. Split it into two meetings, if need be. We don't; we say "Hey, finance folk, you'll want to pay attention the first 15 minutes of the meeting then you can go. You're welcome to stay, but you'll see app features that won't affect you"

* Daily Standup - For high-performing teams, the daily stand up is training wheels. Anything you learn in a daily standup should make you mad. ("Why did you wait til the daily stand up to tell me you [finished X|were blocked|needed this info|are ready for me to test]!"). Do them if you need to. If you do need them, ask yourself why. e.g. who isn't a communicator? Who would've blown you off were they not in this required meeting? Those guys are your blockade for more than just a daily scrum meeting.

* Sprint durations - You make it sound like you don't have a choice. Your team chooses the duration of the sprint.

* "I find the idea that you should get somewhere by sprinting repeatedly [and the rigidness of items in a sprint] rather weird." The rigidness is there to protect you from outside forces, not prevent your team from getting the job done. e.g. It's there to prevent the VP of Marketing from showing up and saying (psst, hey, could you add a blue link on the homepage?" .. "Oh, that link is wrong, make it into a popout." ... "oh, that popout should be a flash video" ... then suddenly you're missing your deadlines to the VP of Finance. It's there to give you a defense mechanism against folks above you trying to work-around their peers for your valuable time.

* "The Scrum coach will find fifty ways of attacking each and every one of these topics, but all of them will be in the form of one more thing. One more meeting, one more document, one more backlog, one more item in the definition of done. " I don't think so, man. It's all about taking the training wheels off, not adding brakes. Maybe you have people working against you. Working against being in a team. In order to protect you from them you're all being laden with extra BS. For us, every painful thing that slowed us down was cut. Blocades were fired. The world got good.

* "Every story in scrum has to end in customer value. [...] why even bother with refactoring?" The team can be a customer. "As a software engineer, I must refactor my [blah] to facilitate [blah]." No need to jump through artificial end-user-centric hoops. When/if you mention it outside the team, just hand-wave them and call it "plumbing." Everyone understands plumbing (as in, pipes in your house you can't see but appreciate every time you flush.) You still get points for work done, you still get value, you're still being a responsible engineer keeping their house clean.

* "What is the job of a software developer? Writing code? I don't think so. I think it's inventing and customizing machine-executable abstractions" Not to be trite, but I'd say the job of a software engineer is to offer solutions to business problems. Usually this is by way of "I've got a hammer so let me hit that hangnail for you", but really, that's all we are, is problem solvers... but... shrug

Re: Ideas for Alternatives:

* "One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then resemble a network of equations, instead of a list of items, where solving one equation would simplify the others by replacing unknowns with more precise values." I'd love to see some practical examples of this. It sounds more complicated than the simple off-the-hip-shot estimates we get with points, but the idea has promise.

* "The other proposal I would have is to get rid of the review, planning and stand-up meetings." You should be doing these judiciously anyway, not dogmatically. Free yourself of the chains of dogma and just do these when they have value. The thing is that they ARE good training wheels. If you're not in a high-performing team and you skip straight to "just do it when you need it" then you never get into practice, you never get used to them, you ... never do them. They do have value, and you should do them when you can demonstrate value in them. So... Ascend when you're ready to.

It regularly seems to me that people think that there's Agile/Scrum and there's Waterfall and that's it. The first year engineering design course (and the first year programming course) in my department cover a number of different approaches.