Sounds good. I don't think it really matters the size of the organisation, though it does seem to be the bigger ones that are pushing it more. Perhaps the problems it seeks to solve are artefacts of organisational malaise where people just aren't as engaged or communicating any more. Yes Scrum is hugely time & effort intensive, and that is a fact that you must be aware of before having a go at it, and if "shit just gets done" well enough as it is you'd be best of staying clear. In dysfunctional organisations blamestorming happens anyway, but at least this way the playing-field is levelled.

Yes but in my case it's a medically prescribed suppository.

Except that Waterfall isn't really a process at all. It's an antipattern that emerges when you take a laissez faire approach to the fulfilment of your development activities. If you check the wikipedia article: https://en.wikipedia.org/wiki/...

"Royce presented this model as an example of a flawed, non-working model; which is how the term is generally used in writing about software development—to describe a critical view of a commonly used software development practice."

What Scrum "is" (or was) was an attempt to actively describe, or codify, the kind of things that effective teams do anyway.

Scrum is a good starting point and provides at the very least a suite of "exercises" which you can use to develop team and business collaboration. It can't compensate for poor technical leadership, though it might make such a deficiency more apparent.

Not quite. In daily Scrum meetings only the team and the Scrum Master are allowed *to participate*. Product owners, non-team business stakeholders, or anybody else for that matter are permitted but they have to stay quiet. Nevertheless I believe that the mere "presence" of these actors can have a negative effect on the quality of discussion ...

https://www.mountaingoatsoftwa...

Yes, it is a common misconception that full Scrum is somehow a lightweight process. It's not, and it demands a lot of engagement from developers and business stakeholders. It usually fails when one or other of these groups doesn't participate, as it should/would, given any kind of sloppy process implementation.

My experience of Scrum is that while it doesn't in and of itself make your life easier, or produce better quality software, or help heal any organisational pathologies you may have, it does at least give you some certainty and predictability, and any operational, quality, or organisational issues that may have been heretofor papered over do become better understood.

When you choose all three you can't say with any certainty which you'll actually get when all is said and done - if indeed you get any of them at all.

https://www.mountaingoatsoftwa...

"Anyone else (for example, a departmental VP, a salesperson or a developer from another project) is allowed to attend, but is there only to listen"

Official Scrum says the stand-up is open to all, but only team members can actively participate - this is a mistake in my humble opinion. In my experience the presence of a senior figure can have a "chilling effect" on the quality of discussion.

I'd rather that too than have to listen to you filling the discussion with warm air.

As somebody who has employed scrum rigorously, and "in anger", in an industrial setting, I can only share my experiences. I don't know why "what you think I think" is suddenly the focus of this discussion, but I can certainly tell you that I am not one of your "many people" that believes it should be applied rote. So take your paradigm and stick it up your arse.

Absolutely, and this is something that Scrum can't really address - though I've seen a number of attempts. Scrum works best as a set of exercises to help people that are usually in a room together to collaborate. It fails when geography or scale are put into the mix.

Except for where you expect each of these big things should be shippable in their own right yeah not so easy now