I'd like to begin my question by saying that I understand that SCRUM or some derivative of it is probably a good way to go for managing software development. It seems all the big companies and my managers use it or have used it, and I can't really argue with all that experience. However I'm struggling to understand the "whys" and all the reading and even my official SCRUM training at work is not doing the job for me. It's just all rhetoric. So I come here seeking answers.
Until now, I have developed in teams of 4-5 members very effectively, completely self-organized and without the need for any training, methodology, or special software. Just discussions in cubes, ad hoc meetings, and one-on-one code reviews. I am now in a position at work where we're being told SCRUM is the way to go, and everything that comes along with it. When they describe SCRUM to me, I read stuff like this:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That's great, but all of it seems like common sense to me. Why did this need codified? Then I'm told the methodology helps us respond to change. What specific aspects of SCRUM are allowing me to be so flexible that I was not previously achieving with my ad hoc meetings, cube discussions, and developer planning meetings? They explain the need to have a working deliverable every two weeks, or sprint. In my particular project, there is no "client", the software won't be finished for a year or more, and in the meantime I will probably only be demoing to upper management every month or less. So why the explicit need for a deliverable every other week? They emphasize the importance of the sprint planning meeting where the entire team lays out the stories and tasks for the next sprint. This is no different than the impromptu planning meetings I've had in the past. Why must it occur every other Monday, and why does the entire team have to be involved? I understand the concept of every member "owning" the product, but the fact is, only a few individuals can ever really contribute to breaking each story up into tasks, while the rest just watch idly.
Again, I understand that the majority of people are behind this process, and so it must work, and I need to get on board. I'd just like to understand why. Is my issue that I already practice these things and just don't like unnecessarily codifying them? Or perhaps I've yet to see the advantages of these techniques because they're being done improperly? Any real, personal information or advice on this, as opposed to the spiel I'm used to receiving, would be extremely appreciated.