The Scrumptious parts of Scrum

As you all know, this week we are supposed to write about our life and times with the agile development method, Scrum.

Scrum and me: Even though I’ve worked with scrum in the past 5 weeks, I still can’t really say anything about it at all. Might this because I don’t have anything to compare it to and that the only place I worked at was in the service industry? Probably.  I can however say how scrum affects my workflow.

  •  First of all it gives me a clear list of priorities of things that needs to be done during any given period, that is tailored to the tasks at hand, what the other team members are working on and my skill level. This makes it simple to structure what I’m going to do during a sprint – and since code and asset is worked on at the same time and often together in the same room, it simplifies the cycles of iteration since we can communicate effectively.
  • Clear deadlines. As a person who has a habit of not finishing things or space out, the clear and often very tight deadlines are a great help in ensuring that I finish all the assets on time since it affects the whole group. On the flipside, since tasks can be switched around to suit both the team and the individual, the amount of work often times don’t surpases what’s actually doable in one week.
  • The freedom of leaving things. Technically we are aiming to work 20 hours a week, and sometime that won’t happen due to disease, unexpected events or other forms of mismanagement so you might be forced to leave an asset as “It works” or the like. However since the plan is updated every week, often with a focus on testing and improving, it alleviates some of the pressure of needing to make sure everything looks perfect before it can be considered “Done”, since you always has the option to go back to it and you’re probably gonna iterate upon it either way.

These are the thinks I can think of when it comes to how Scrum has affected me since I don’t have anything to compare it to and bottom line, I’m still not very familiar with it.

A big problem with how we’ve been working, is that since it’s built upon previous cycles, is that if something doesn’t get done during a sprint – there’s no way to continue working on it until the stage before is completed. As an artist this can be really frustrating when I have to wait for design, and I can imagine it being frustrating for our programmer when I’m slow with an art asset. It also means that there’s a higher chance of me being forced to redo an asset if the design changes part way through the project. This is probably a symptom of our inexperience in game production and our misunderstanding of Scrum. As well as how it feels like we are sort of pushed into something that’s in between scrum and the classical waterfall model.

In Team Devourer we usually structure our days like this.

Monday: We usually start a meeting by having an actual meeting where we discuss different parts of our game with feedback and just general thoughts as a base. When we’ve reached a conclusion (read. When everyone is dead from the lack of oxygen) we move on and do our sprint plan. During the planning we usually look at what we decided, where we are and where we are going and then tasks are given based on what needs to be done to the next milestone, based on the order of importance. We usually don’t have a stand-up meeting since we end very late.

Tuesday: We have a stand-up meeting where we present what we have done and what we are going to do.

Wednesday: On wednesday we usually have another meeting followed by us working together in the same room.

Thursday: The same as Tuesdays. Sometimes we have an extra meeting if there’s something urgent that needs to be taken in person

Friday: We do our sprint review where we briefly discuss how things have gone throughout the week, followed by, you guessed it, another meeting where we prepare ourselves for the coming week.

You might notice an overabundance of meetings, but they surprisingly really helps us to keep on the right track and also makes sure that everyone is up to speed. This is about I don’t have much more to say.

See ya~


6 thoughts on “The Scrumptious parts of Scrum

  1. Hey Carl I will be commenting on your blog this week!

    Is it clear what is done?
    Yas! I like the way you reflected on your own thoughts and experiences with Scrum and went into a lot of detail regarding how it has effected your team as well as how your team adapted to it and have structured your work habits.

    Is it clear how it is done?
    Maybe not as clear, to me it sounds like trial and error as my team basically experienced the same thing since no one had used Scrum before until now. I understand your line of thinking and I like the way you described your process though!

    Is it clear why it is done?
    Yes! As you stated it was mostly a lot of try and see what happens which has evolved into your weekly Scrum schedule. At least from my perspective I understand how you got from where you started to where you are today!

    Is the post valuable?
    Yes! I really liked the way you went about describing hot scrum has effected you, your team, and your work week layout! Now that I read your blog I kinda wanna go back to mine and fix it!

    Can it be improved?
    Maybe describing how you started and possibly a more descriptive description describing how you got from week 1 to now! Otherwise I really enjoyed the read and I am sure I will use this blog as inspiration for my own 🙂

    Good Work Ma Dude,
    ~Marcuse Ford


  2. Hi Carl!

    Overall I liked your blog post describing the way the SCRUM method works for you and I generally share the same feelings regarding this subject. However, when referring to how the development method is based upon previous cycles I find it quite hard understanding the issue of not being able to work on specific goals until the sprint is completed. From my point of view the whole basis of Agile planning is to revisit some of the items, that have a high priority and have not been completed in time, in the upcoming week. This results in progress being made until the item in question respects the definition of DONE. What I have learned through this way of working is that no matter if the asset in question is completed, implementing it into the game and testing could lead to you (as a graphic artist) having to make slight changes in order to fit the criteria. And that is where we share the same feeling of frustration.
    Finally, I would like to point out that the way you described how SCRUM has influenced your work flow is pretty good and gives insight on how working with a team for game development really is.
    Good luck with your project!

    Raileanu Petrut


  3. Don’t sell yourself so short. Despite saying otherwise, you clearly do have something to say about it. From reading your post, it’s obvious that you understand what scrum is, the way it works, how you and your group are applying it to develop a game, the accompanying ups/downs, and how you have been dealing with them. Even if you aren’t necessarily familiar with scrum, I can see and say you still ‘get it,’ and any growing pains are just part of the procedure.

    While I don’t see any issues with the overall content of your post, I do with the way in which it is structured. I do not recommend starting something off with “as you know.” Not only is it an atrocious method of shoehorning in an infodump, but it’s not going to just be our peers and professors who will be reading our posts. In general, you’ll be better off not believing the reader possesses a rather specific sort of knowledge. This happens again in a way when you mention the waterfall method and didn’t expand on what it is or how it works either before or after. Though if I’m being critical of the frosting and not the cake, it means you’re heading in the right direction.

    Best of luck in development!

    -Christopher Haibel


Comments are closed.