Final Essay

A look at the groups at the end of the projects.

Introduction

Now that the projects have ended I am going to write an essay about the groups that I have tracked and to see if these groups have been using the agile methodology.

Agile Methodology

Agile is a project management technique, agile is good for projects that are being monitored by stakeholders who would like to see the progress of the project. It also allows for the stakeholders to be able to change parts of the project as it is iterative meaning that meaning that when new thigs are added older versions are also kept and these can be used if the stakeholder would like to revert something back, it also allows for rapid changes and bug fixes.

Agile development with scrum uses sprint cycles which allows members of the team to have a product backlog that allows them and the employers to know what needs to be added to the product. Agile methodology is an iterative and incremental methodology that allows users to have working products at the end of each sprint so that it can be tested.  (Stephenson, 2016).

Groups

After being able to sit in on the initial pitches for the groups I was able to select five of the groups that I had seen pitch and choose the groups that I would like to track for the duration of the project. I selected Group 11, Group 12, Group 13, Group 14 and Group 19, I chose these groups based on the pitches so that I had a variety of groups that could be control groups and groups that I may have to have some input to help them along with the methods that they should be using. All of these groups had some concepts on how to solve the brief that they had been given and when I was able to sit in on the initial pitches the groups had all shown that they had been meeting and communicating well with each other as they had all come up with their own concepts that would fit the brief that they had been given.  

Tracking the groups.

In order to be able to see how well the groups where doing, I was CC’d into their email threads, I was given permission to their JIRA so that I could look at tasks that are being set and when they where being done, I was also given permission to their Git Repository so that I could look at what work had been uploaded and have access to the meeting minutes that the group should have been producing.

I created a spreadsheet so that I was able to keep all of the information that I was tracking in an easily viewable document that would let me know week by week how the teams where communicating and how work was being done. 

In the first two weeks of tracking the groups all groups where communicating well and most of the groups where completing the tasks that they had been set on time and that they where not leaving them until the last day before the sprint closed. One group however was not logging the time that they had been spending on their tasks, however the tasks where being completed, this is confusing for the stakeholders who would also be tracking the groups as they are not sure when work is being done.

First two weeks of being able to track the groups (Weeks 3 - 4)

As you can see from the table above I decided that I should track the emails, if they had produced meeting minutes, if all member were present at the meetings, how many hours of work they had estimated, the total hours spent, how many tasks that had been set for the week, completed tasks and unfinished tasks.

Weeks 5 -6

The groups where still communicating well and most of the groups where completing the task on time, however during week six of the project one of the groups didn’t log any hours on the tasks that they had set so the stakeholders and myself were unsure as to whether this work had been completed or if it was left until the next week.

Weeks 5 – 6 of the project.

Weeks 7 – 8

 The communication from some of the groups had dropped in week 7, this meant that the stakeholders and myself didn’t know much about the group if they were communicating about work. All of the groups in week 7 had logged time onto the tasks that they had been working on and the majority of tasks where completed this week. In week 8 all of the groups communication increased and again the time was being logged correctly on the JIRA so the stakeholders where able to see that the teams had been working.

 

Weeks 7 -8 of the project.

Weeks 9 – 10

During week 9 of the project one of the groups had no set any tasks for the sprint so I am unsure as to whether any work had been produced during this time as they also had very little communication. The rest of the group however communicated well and had a sprint set up for the week, they had logged the time spent and they had been completing tasks on time. Also during week 9 I set up meetings with all of the groups to discuss how they feel the methodology works and if they have anything that they would change.

The feedback from the groups was very similar where they felt that the agile methodology worked well for what they had to do as they were having to show stakeholders the progress of the game and that the meetings would help them to ask their team members with help resolving any issue. The group that had not been logging work properly I suggested that If I would of got the meetings set up early that I would of asked them to try daily sprints where the work would have to be done in the day leading up to the end of the normal weekly sprint cycle, the team agreed that this may of helped them If I had managed to pick up on the issue earlier and talk to them about this. One of the project managers was also having issues with his group members, neither of them where turning up to meetings and they were not producing work to a standard that he felt would be help the project so he had to take in onto himself to do not only his tasks but his group members work also, however the group members were logging their time into JIRA and saying that they had been doing the work but looking at the Git Repository you could see that the work had not been uploaded. This meant that the project manager had to keep having meeting with stakeholders to discuss what to do next which meant that he lost time on his own work. I have more detail on this in my blog which you can read here at sstephensonfinalprojectblog.blogspot.co.uk.

The same happened again during week 10, one of the groups had not set any tasks for this sprint and this was the last sprint that the teams had before the end of the project. This was set up as a 3-week sprint due to the Easter break, and all of the groups communication dropped to zero so there was no way of knowing if they had been meeting or talking about the work that had been set by the groups that had a sprint. There were also no meeting minutes so none of the groups met to discuss the work that was being done, however by the end of the sprint the groups had completed most of the work that had been set.

Weeks 9 – 10 (Week 10 is a 3-week sprint cycle).

Final Total

At the end of the project I found the totals for the emails, the estimated hours, the hours spent, the tasks set and the tasks completed.

The teams had all worked very well together during this project and they had produced some very good work, they all had around the same amount of time spent on the project with the exception of one group however the time is also effected by the number of people within a group so because this group lost a member and was dropped down to two people then they had less time total than the other groups. Most of the groups had worked on the project longer that they had estimated this could be because tasks took longer than they had estimated to complete or tasks where worked on but then taken to the next week sprint due to them not being up to a standard that the group wanted. The communication from the teams where good however I would of liked to of seen some more emails from some of the groups in regards to the work that was being produced, especially from groups that had not been logging the work consistently. Now that I have been able to track these groups through their project from the beginning to the end I have been able to see how agile works and what can go wrong with using the methodology.

By the end of the project all tasks that had been set had been completed by the groups, however this does not mean that tasks where completed on time.

Total at the end of the project.

Is agile the best methodology?

There are a number of different project management methodologies that could be used within the game industry, however I feel that the agile methodology works well within the game industry as the product is always changing and games benefit from an iterative method as some things may be added that are not wanted within the final product.

I have been looking at agile being used within small teams, this works well as communication is a key part of the methodology and communication within small teams is easy to achieve, and within a small team it is easier to track all of the team members work.

One of the main advantages to using agile methodology within game design is that you can focus on getting out a product that is to a standard that your users would like to have as you can have input from them during development and find out what they feel about the project and then any feedback can be looked at and implemented into the game during the next sprint cycle of the project and then your users can then give feedback on the newer versions that you produce.

You can also create user stories where you can look at the mechanics that you would like to add and then look at them from the players perspective and create a user story based on this. This helps you look at the project and work out what should be implemented early and what can be left until later in the project.

Agile also allows for you to have a product backlog so before you start work on the project you can see what you would like to be implemented into the game and put this into the backlog as tasks, this allows you to have a clear vision on what you are implementing and allows you to create a timeline of mechanics or other assets that you can then prioritise from the most important things that you need to add as early as possible to make the game playable to assets that could be considered as minor so that when it is the end of the sprint and you have a meeting then you have the things that are important to the game implemented and you have something to show to the stakeholders or scrum master.

Another advantage to using the agile methodology is the communication used within the method, communication is one of the key aspects of this methodology and I feel that being able to meet and talk with your team members and your scrum master is something that should be done. I feel this because not only does it allow you to see all of the work that Is being done by your team but it also allows you to ask any question regarding work that you are going to have to be doing in the future, when a team comes together for a meeting they can discuss things that they may have problems with such as bugs, or they can bounce ideas of each other and find something that may be implemented into the game to increase its quality.

These advantages are good as it involves a lot of interaction from the player and the stakeholder so any changes that are brought to your attention by either of them can be implemented early so that you have a product that is getting the needs of your user correct.

Although there are a number of advantages to using agile methodology there are also some disadvantages to using the methodology. Having user feedback is good however it may not always be possible to find people who are your demographic who have the time to be able to test your product and the same problem arises with the stakeholders of the product they may not have the time or the interest in your product. Even though this is not as bad in small teams, but more related to the larger teams, if all team members are not fully dedicated to the project then this could set your team back as if interest is lost they may not complete tasks that are being set, or they will not complete them to a standard that the rest of the team feels is acceptable. It may not be possible to finish the features within the time that you have been allotted this is counteracted by one of the advantages to using agile though in the form of user stories as you can prioritise the most important features. Although agile can be used if team members are not all located in the same office due to collaboration software and video conferencing, it would be better if the teams where in the same physical space this would help with knowing what is currently being worked on so that two people are not editing the product at the same time and create a conflict in the collaboration software if they are trying to update or wipe out the work that one has done due to not updating their version of the product before starting to work on it.

Although having user and stakeholder interaction is good if your users or stakeholders do not have the time or the interest to look at your product then you may not get vital feedback. What I have seen during the projects that I have been tracking is that some of the groups had members that lost interest in the project and this made the groups fall behind as tasks where not being completed to a standard that was acceptable to the rest of the group, this caused issued for the project manager as he was having to escalate the members of his team who were not working.

Conclusion

After being able to look at groups that have been using the agile methodology and to be able to look into the methodology more, I feel that the projects that I have been tracking have utilised this methodology well and have been able to successfully create a product that is playable and that meets the brief that they had been set. There are a number of methodologies that could be used for project management in games, however I feel that due to the iterative nature of agile it is very well suited to the games industry as our products are always changing, whether it be during development or as an update that is released when the game is released. It allows stakeholders to have input into the development process and also allows for user feedback to be implemented, when you have play tested your game or tested your product with your intended audience. 

Bibliography

About · TortoiseSVN (n.d.) Tortoisesvn.net. Available at: https://tortoisesvn.net/about.html (Accessed: 29 April 2017).

Burndown Charts (n.d.) Agilenutshell.com. Available at: http://www.agilenutshell.com/burndown (Accessed: 29 April 2017).

Cervone, H. (2011). Understanding agile project management methods using Scrum. OCLC Systems & Services: International digital library perspectives, [online] 27(1), pp.18-22. Available at: http://www.emeraldinsight.com.login.library.ucs.ac.uk/doi/full/10.1108/10650751111106528 [Accessed: 29 April 2017].

Cohn, M. (n.d.) Scrum Methodology and Project Management, Mountain Goat Software. Available at: https://www.mountaingoatsoftware.com/agile/scrum (Accessed: 29 April 2017).

Cohn, M. (n.d.) The ScrumMaster, Mountain Goat Software. Available at: https://www.mountaingoatsoftware.com/agile/scrum/scrummaster (Accessed: 29 April 2017).

Lotz, M. (2013) Waterfall vs. Agile: Which Methodology is Right for Your Project?, Segue Technologies. Available at: http://www.seguetech.com/waterfall-vs-agile-methodology/ (Accessed: 29 April 2017).

Meulle, V. (2014). Agile, a practical point of view. [online] Gamasutra.com. Available at: http://www.gamasutra.com/blogs/VincentMeulle/20140702/220083/Agile_a_practical_point_of_view.php (Accessed: 1 May 2017).

PAULK, M.C. (2013). A Scrum Adoption Survey. Software Quality Professional, 15(2), pp. 27-34.

Parkash, S. (2015) Agile Development using SCRUM - What you don't know!, Linkedin. Available at: https://www.linkedin.com/pulse/agile-development-using-scrum-what-you-dont-know-sri-prakash?trk=prof-post (Accessed: 1 May 2017).

Pries, K. and Quigley, J. (2011). Scrum project management. Boca Raton, FL: CRC Press.

Stephenson, S. (2016). Contemporary Project Management Techniques.