With the upcoming release of our game (any day now), I can't think of a better time to finish up my sequence of posts on Scrums. If you haven't already, please check out Part 1 and Part 2.
In this section I'll cover my opinions of the pros and cons of using Scrum. Back in August when I initially wrote Part 1, I had entended this piece being somewhat more balanced... however, having gone through an entire project I must admit my opinions of using Scrum is more biased.
The Cons:
1. It takes time away from production. We spend an entire day of planning every two weeks. On top of that, we spend another 15-30min each morning for our daily Scrum. Additionally, we also meet every Monday for an hour for code review (however, this doesn't particularly pertain to scrum... but it is part of SOE Tucson's process). Each of these meetings involve everyone from the development team and even some people from Art, Design, Production, and Management. This can quickly add up, and may be hard to justify if you are charging by the hour.
2. The setup and management of a Scrum board, cards, and the meetings can be burdensome. This is similar to #1 in that sometimes the process can get in the way of getting things done. As we neared the end of development cycle we switched over from Scrum stories and cards to filing dev track tickets and reporting on those. With hundreds of dev tickets going through the system it would have been counter productive to make a card for each of them and track them on the board.
The Pros:
1. As an individual you know what you need to get done each day. You can focus on your tasks at hand without getting overwhelmed by the remaining items to do. By focusing on small tasks you can easily see if you are behind or ahead for the day/week and know if you should be staying late.
2. You have a good picture of where the project stands and who is working on what. If something breaks with the 'inventory' mechanic, you usually know if someone was going to be working on that today... and if no one was, you usually have an idea of who has spent time in there before so you know immediately where to go for help.
3. You pick your own fate. By playing planning poker you are defining your own tasks and your own deadlines. Granted, come crunch time some of this goes out the window; however, you still have a voice to some extent.
4. All of that planning leaves less surprises. As a team you have a good understanding of whether or not you will hit your deadline well before crunch time hits. Without a Scrum, sometimes you can get hosed by the amount of work that always seems to 'appear' towards the end of a project. With a Scrum, you should hopefully have these items listed and accounted for.
Bottom Line
I think it comes down to the project and team as to whether a Scrum should be used or not. If the timeline is vaste or the team is large, I would not want to work without Scrum... or at least something equivalent. On a small team or project that is just a couple weeks or a month... all of that planning and daily meetings could be a waste. Instead, you may be better suited using some well defined milestones, a beta launch, time to test, and a hard deadline. Those milestones combined with close communication with your small team basically covers the same objectives as a Scrum without the formalities.
Coming from a freelance background and small studio background, I am usually fairly anti process. I had viewed them as good in theory but bad in practice as they were usually counter productive in my experience. Cover sheet on my TPS report? Yeah sure, I'll be right on it... However, I had not experienced a large enough project or been involved with a large enough team. I was too green in those areas to realize the importance of process. Now I can not imagine trying to pull together the game we just created without a scrum (or code review for that matter). It would be a nightmare. Therefore, I have come to love Scrum and would recommend using it or a version of it in all future projects of any significant size.
No comments:
Post a Comment