Production Management & Team Management
This Blog will be going over the methodology and the "How" both myself and Josh Davidson have been managing the teams workload as a whole and how we organised each area of development as well as creating safety nets for the team for work overload.
After I had conducted research into some UX and UI design principles within VR, the next step was to make sure that the team was organised and could easily communicate and view what needed done, as well as what was currently being completed. To do this it was best practice to have an agile methodology for production.
The methodology that I have had most experience with and that I feel would have worked best within our team was the SRUM methodology which I wont go into detail about as I go more into detail about it in the Week One blog (Here). This weeks blog will be going over how we took the SCRUM methodology and how we worked it into the team dynamic. I had discussed with Josh how this methodology would work best within our team and below is the breakdown on how we implemented it into the team.
Using Kanban within Miro
The first thing we tackled in production management was the Product Backlog, This was a collection of everything that we thought at this time we would need to add to the product and complete for the product to be finished, this list of tasks ranged from scripting, to asset development, just about anything the team needed to do was but into this list.
This allowed the team to continually add in tasks that they needed to do as well as see what was needed to be completed in each area of the project. Myself and Josh felt as well that having a visual list that would progressively get smaller could work as a good incentive/ motivator for the team to see each task get slowly ticked off one by one.
Weekly Sprints
After the product backlog was fully completed I started working on creating an area where every member of the team could pick out tasks from the product backlog and put it into each sprint. This particular section of the SCRUM methodology was a big reason as to why I felt it would work well within our team as these sprints allowed each team member to pick out the amount of work that they wanted to do within each sprint. These tasks would then be taken into each members subsection (Seen Below)
With all of our member also working on a separate module it meant that the weeks where they felt they need to focus on the other module they could take less work for this sprint, similarly it would be foolish to not expect that throughout development life could get in the way or sickness could strike anyone in the group so it also gives leeway to those that need to take some less work due to personal reasons.
Personal backlogs
Along with the product backlog we thought that it would be best to create backlogs for each discipline within the project, those being "Asset Development", "Programming", "UI/UX Design" and finally "Level Design". This meant that each area of development could each others development during this particular sprint, as well as knowing what work they themselves are taking on.
We as a team thought it best to have something like this throughout development simply as it kept things more organised for the team and allowed everyone to keep better track of the work that needed to be completed within each sprint.
"Safety Net" Backlog
Finally then we have something that we thought was necessary for the management of this project was the inclusion of a "Safety Net" of sorts for everyone in the team, this "Safety Net" worked where whatever was supposed to be completed within a sprint that for whatever reason was unable to be completed was added to this safety net backlog, This backlog was not exclusive to any discipline within the project and could be picked up by anyone.
This allowed the team to have a better understanding of what exactly hasnt been able to be completed. As well as that it meant that if any member felt that they didn't take on enough for this particular sprint and they had some free time they could choose to pick up one of the tasks in the backlog.
This way it meant that the whole team could work together better and it would help to create a better work environment for the team as the last thing we wanted was for each discipline to exclusively stick to their own area as that is where communication breaks down, it also allows the group as a whole to help out where needed instead of leaving certain groups stranded if they are feeling too overwhelmed.
In Conclusion
Overall I have to say that I feel that if the team sticks to this methodology well that the team should run into far less team orientated problems, as everything that each member is doing at each point in development clearly outlined from the beginning. The biggest problem that could arise from this way of working however is that some members could take on too much for themselves or too little and if this does occur we can take a step back address the issue and try to find a way forward. Good Production management is something I think is extremely overlooked and undervalued in student work but it's something I think will only benefit our team I look forward to seeing how it works for our team and the lessons we will learn from it.
- L
Comments