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.

agile-scrum-lifecycle-diagram
Source: https://www.visualstudio.com/learn/what-is-scrum/

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.

 

3 thoughts on “Scrum and Its Effects on Development

  1. Hello Gunnlaugur,

    First of all, great post!

    The fact that you give the reader an in-depth understanding of your prior experiences with Scrum makes it a lot easier to follow your train of thought.

    Your choice of imagery complements the post nicely as it depicts the generic Scrum process.
    You have clearly described the effects that Scrum as a framework has had on your group so far. I do agree that the forced use of a template is sub-optimal for Scrum, especially as Scrum is an agile framework (and as such should allow for usage of whatever basis/tool(s) for documentation best suits the user(s)) while I of course realize it would be problematic for University Faculty to grade each group backlog etcetera fairly if we would have used different platforms.

    I find great value in your honesty and conclusions, if anything I would suggest using sub-heading for increased readability.

    Keep up the good work!
    Sincerely, Erik Rosenberg

    Liked by 1 person

  2. The post seems very well structured, easy to read and understand. Describing the principal differences between an office environment and our situation is an interesting way to develop the subject, and how those same differences impact our project, product and workflow. I believe most teams have had the same scheduling issues regarding meetings and stand-ups.

    I agree that filling the said template feels more like bookkeeping and considerably less practical than a proper tool for efficient organisation and tracking, but I also understand that is an easy way for the instructors to keep track of our work and progress. Regarding the terminology, I had to make my own google sheet to keep track of my own work and progress, since the template provides no practical way to do it because of that same terminology and lack of clarity.

    Overall, I liked how you considered Scrum in both office and university environments and compared the situations. It’s also interesting to see the point of view of someone who has worked with this framework in a professional environment and the differences with what we’re currently applying.

    A lot less ranting than I expected, good job!

    No jokes added,

    Samantha Baqués Velásquez

    Scrum post: https://artdevsam.wordpress.com/2018/02/22/scrum-and-sirens/

    Liked by 1 person

Leave a comment