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.
