Scrum and Its Effects on Development
|
It is my experience that Scrum is a great lightweight framework for iterative development but it also comes with certain conditions that greatly affect development. I have had some experience with Scrum in the past inside of an office environment and as such can make some comparisons between how Scrum has affected development based on the circumstances in which it is used.  Overall, Scrum is perhaps the most competent tool in which to have a cycle of iterative development. It allows a development team to be self-managing and independent in arranging and completing their tasks while staying on the same page with everyone in the scrum team in form of daily stand up meetings. The daily stand up meetings are a powerful tool inside an office environment where everybody is available at the same time, however this becomes more of a problem when a team lacks an office space and in the case of a University team members have different schedules, as this means a significant portion of the day is spent in transit to have this short daily stand up meeting. This can cost a team vital development time each day unless alternative solutions are found to decrease time in transit or how the stand up meeting can be performed without losing the quality of face to face interactions in such meetings. My previous experience has been somewhat different to how Scrum was enacted in Game Design 2 at Campus Gotland with the template we were asked to use. I believe it has resulted in some over-complication of Scrum where it requires extra time to use effectively and is somewhat lacking in clarity of language and terminology. Now this isn’t too much of a problem but compared to previous experiences where I used Scrum in Multimedia Design and Development, it has resulted in more bookkeeping than I would prefer without increasing readability. I believe this is the result of the categories in the template being “Planning”, “Implemented”, “Tested”, “Meet Expectations?” “Completed” in favor of using “To Do”, “Doing” and “Done” and separating designing, creating, implementing and testing into different tasks in the sprint log. Alongside that, I believe it would simplify it to have a tag system on each task that can simply be tagged “Meets Expectation” once the QA has reviewed it. This is based on my experience with Scrum in the past, and may likely be based on personal preferences in development using Scrum. In the case of my team’s overall development of Umibozu, Scrum has been beneficial to allow for adaptable and iterative development based on sprint reviews and play-testing we’ve done. There has been barely any sign of features or artifacts being scrapped due to the fact that we specifically plan and review every sprint based on the priority and feedback we acquire through meetings and play-testing.
 |