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.
Best Answer
I think there are two aspects to answer your question, but let me start with congratulating you for working with people who seem to be smart and competent enough to be able to pretty much work without a strongly defined process and still deliver a product. Unfortunately this isn't a case in all software teams, so maybe one of your issues with Scrum might be that you and your co-workers actually don't need a process dumped onto you to make you more effective. You might already be effective.
Other teams aren't and need a more strictly defined process and some guidelines to get them to get things done. This doesn't mean that these teams are more stupid or less capable, it just means that maybe they have problems self-organizing or working with discipline as a team. This can also be a simple learning experience when coming from a place where people work mostly alone to working together as a team. Scrum can help getting there, because it offers a few guidelines that are both easy enough to understand and follow, yet effective enough to put some pressure on the team to start getting it together.
Since Scrum doesn't say anything about the way that software development should be done it also leaves the team with the freedom to decide for themselves (e.g. you can still do a sprint applying a rather conservative waterfall method as long as you are done at the end of the sprint).
So the team is one issue. The other issue is management and management trust. Here, Scrum might be good because it's transparent and allows any stakeholders to see the progress the team makes in defined cycles. So it's not "we're making progress, unfortunately we can't show you anything right now, but believe us, we'll be done on time". This may be even true, but it can be reassuring for any managers to actually have a regular demo where they can see that progress has indeed happened.
Scrum is not a silver bullet. It may not work for some teams for a variety of reasons, maybe for some teams self-organization doesn't work out. Maybe for you it's the other way and it seems like a process dumped on an already productive and organized team.
When in doubt I would pretty much suggest you just try it and see. If it doesn't work and the greater part of the team doesn't like working that way, don't do it. However, check it out for a couple of months (I say a couple of months, because the first few sprints will be awkward anyway and you need time to adjust the details) and then re-evaluate.