Given that its nearly Thanksgiving and all, I am hoping I can guilt some people into registering for a Hackathon in February (12th-13th). Basically, you code/design for 24hrs on projects for non-profits. Its a nice boost to the porfolio/resume, an opportunity to network, and a great way to give something back to the community.
This particular Hackathon is being organized by Stanford University. Although it is coupled with their Dance Marathon event, you do not need to be affiliated with Stanford to participate. I joined in the fun last year as a remote hacker (I participated from Indiana) and helped work on some interesting projects w/ very talented individuals.
If you have any interest, you can learn more about the organization and who they help here. And if this sounds like something you would enjoy, then please register here. Ignore any questions that do no pertain to you (residence/room number/etc)... this form is used by students as well as remote hackers. Make sure you answer the last two questions. By existing team, they mean do you have an organization or group of friends you are registering... Lets say your user group is interested, not everyone in the group needs to register, just register the group itself.
Feel free to ask questions in the comments. If I can't answer your question, I'll direct you to someone who can.
Tuesday, November 23, 2010
Tuesday, November 16, 2010
Scrum (Part 3: Pros/Cons)
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.
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.
Subscribe to:
Posts (Atom)
