They're software development paradigms. Scrum seems to be a subset of Agile development with an emphasis on meetings to report progress, and less emphasis on reams of written documentation (which seems to be for the purpose of making things go faster in a crisis). The idea is to accept that your software specifications are going to change, and therefore break down everything into small subproblems that can be tested, revisited, and most critically submitted to your supervisor individually so that they can make the most inane possible critiques and requests. The process assumes a regular flow of "completed" things upward so that supervisors always have something to do to make them feel valuable, which in turn means your actual developers have to get X number of things done every week (regardless of how challenging any of them happen to be, leading to significant overtime). Moreover, in order to ensure all these little bits work together (and to prove you're doing your work), you need to be constantly documenting things (instead of making things) for developers on other teams in the same project, since one of the core principles is to have small teams of developers with narrow goals.
Or at least, that's my understanding of it. Basically, it's totally administrator-focused, with the expectation that the engineers will just make things work. You're expected to constantly prove that you're getting shit done, either by documenting it or explaining it in a meeting, which decreases productivity directly and through morale hits. And while there are cases where those costs are worthwhile, the arguments for making it the status quo rely on ignoring those costs and/or attacking a strawman (the "waterfall" model, which has some similar problems, but is fundamentally based on the idea that specifications will be determined in advance).
Author
Topic: For those who also think Scrum is awful (Read 1813 times)