Keep in mind that Scrum was designed by consultants working for organizations that don't understand software development. So they designed a process that can make sense to people outside our industry. In order for it to go well, though, the person running the Scrum process needs to know how shit really works. This is rarely the case.
> Keep in mind that Scrum was designed by consultants working for organizations that don't understand software development.
Scrum was "designed" by Ken Schwaber, a software project manager at the time looking for a better way to control software development processes.
Schwaber discovered he could use an empirical process, rather than a defined one, to control software projects. He created Scrum following this principles.
> the person running the Scrum process needs to know how shit really works. This is rarely the case.
I agree, while a very simple process, people who don't get it tend to complicate it. They focus on the process instead of the result.
Most failed scrum teams I've seen out there skip the retrospective meeting, which is in my opinion, the key of the whole thing: that's the meeting where team members usually realize they "own" the process and can steer it any way they desire.
