Scrum seems to be mostly about having better alibis

Scrum being perceived this way is hardly surprising - its hard to develop a methodology for anything where responsibility and control are arbitrated in a fashion that gives the user (of the methodology) more of each component. Taking full responsibility for things is not the same thing as having alibis for when things "inevitably" go wrong .. if the methodology is a defense mechanism from the damage that occurs when projects overrun, its not going to be as effective at actually pushing projects through as it were if it were an attack mechanism for how to make things go right, no matter what happens. Alas, being effective versus being effected, is whats at play here. Few of us actually want to face the fact of our own failing, unless of course we 'predict it' in some fashion, first of all - and therefore create the conditions for failure to occur, 'comfortably'.

But like all tooling and methodology, it is a matter of the original intention of the user that counts. If you're adopting Scrum to save your ass 'in case things go wrong', you're doing it wrong already. If you're adopting it 'to make things go right, and do things properly', then you're doing it right. The only difference is the intention of those adopting the methodology.

I'm not sure why anyone would say "Scrum doesn't want to solve this". When I've worked with teams new to Scrum and the question "how does this fit into Scrum?" comes up, I'll discuss with the team and we come to a pragmatic agreement that is right for the situation and context. Similar to TDD, I think it's great but it's not always the right approach in 100% of situations; adapt it to your needs.

All methodologies have their flaws and Scrum can sometimes frustrate me (I'm not a purist) but I definitely prefer it to waterfall. Mature teams take the bits that work for them and improve on the ones that don't. It seems the OP is taking the methodology too literally which implies a lack of experience in trying to apply it.

I've tried (and failed) to get a team to work on a feature as a team, refactoring as they go. This didn't work, not because of the methodology, but because the team just couldn't get their heads round it. We decided this was fine and worked on UX a sprint ahead (and built this into the definition of ready). A methodology should not have to cater for every personality and set of skills - that's down to you as a team to figure that out.

Teams at first won't organise themselves but once they start taking true accountability for their work (and not keep looking to a project manager for direction) I've seen teams start to get more efficient and more motivated because they get to take control of their work and define the process.

Typo with 'Onwer'?

> While they just try to focus on building software, Scrum dragged them into seemingly endless series of meetings called Reviews, Retrospectives, Plannings and Dailies.

This just caught my eye. The Scrum process as originally described had three meetings - one planning meeting per sprint, one retrospective per sprint, and one daily stand-up. It's a stand-up, as opposed to a sit-down, to try to enforce brevity. It's also typically recommended to spend 5% of your sprint in backlog grooming/refinement whatever we're calling it.

You should, of course, iterate on your process to make it suit yourself. My team, for example, decided that we'd spread that backlog refinement over multiple days to keep it short, sweet, and relevant. We probably spend more time on it than 5%, but that's purely self-interest, as it keeps our plannings short (we are usually coding by the afternoon of the first day of sprint), and our stories well-estimated and deliverable.

But then it's hardly reasonable to complain that your modified process means that the underlying principles are bad.

Fair disclosure: 1) I teach/coach Agile/Lean/Kanban/Scrum, and 2) I couldn't care less about brand names and religious dogma. I'm a developer first. If it works, do it.

Having said that, this author does not know what he is talking about. Apologies for being so blunt, but there it is. And he probably doesn't know what he's talking about because his organization has failed at making changes.

Really there's just a couple of questions to ask yourself. Can you get everybody important to the project into the room working together? Can you guess what you might do over the next week or two?

If you can do those things, hell if I care what you call it. If, however, you believe that complex systems must always consist of dozens of people with various deep-dive specialties? Then we've got a problem.

The problem isn't that some things in life are tough. Technology development is certainly tough. It's that you need to realize that the enemy of productivity has been siloing people and specialists that want to hand-off their work to others.

In some cases, the business environment means you can't have everybody in the same room. Fine, there are strategies for that (too much to go into here). In some cases, people just want to keep working the way they've always worked. Most of the time it's the latter case, not the former.

It's a shame that this person's environment has failed them in this way. No, Scrum is not made for a lot of things, but you are not a special snowflake. I can freaking guarantee you that no matter what technology problem you're solving, all that Scrum/Lean/Kanban/yadda yadda stuff has been used to help folks run fast. I would suggest trying to find other teams doing the same thing you are, only much faster, and watching what they do. That's how all these buzzwords came about, anyway. If you don't want to believe the books and trainers, and I'm fine with that, go watch it work. Then write another article. :)