DHL Tycoon
Details
Role: Scrum master Members: 16 Duration: 2 months School year: 2 Engine: Unity Platform: PC DHL Tycoon is a management game in which you build your own logistics company. Create your own service centre, with interesting machines and motivated employees. Figure out how to deal with an ever-growing flow of packages, while keeping your employees happy and making as few mistakes as possible. It’s time to keep your head cool and get ready to deliver some excellence
|
|
Responsibilities
- Ensuring the clients view and branding are represented in the game to their satisfaction.
- Scheduling meetings within the team, with the client, and between both parties.
- Facilitating meetings by making an agenda, sharing this with the team, taking minutes and creating action points.
- Setting up and maintaining day-to-day scrum tasks and progress.
- Communicating with the client about the state and expectations of the project.
- Setting up the team structure and pipelines, and improving these throughout the block.
- Setting up the risk list and updating it throughout the bock, ensuring contingency plans are executed if necessary.
Lessons learned
Client contact
Having the opportunity to work with a client who is not familiar with the gaming industry proved an interesting challenge. We had to figure out what they wanted without them being able to directly explain it. The end goal would be to put the game on tablets in the bigger DHL training an innovation centers for employees to play in-between training sessions. We had to derive from context and their company pillars what it is they wanted to see in the game, and how we could make that enjoyable.
To ensure the client could see the progress and give their opinion on it regularly we had bi-weekly client meetings during which we presented the state of the project and the direction we were heading. We then discussed their feedback on this and how we could improve the game based on that. Most of these meetings came down to properly managing the clients expectations, which proved to be hard at first but became easier after analyzing their thinking process and feedback. This allowed us explain our decisions based on their pillars and values, which reduced the number of questions they had, and made them more receptive to changes we made on the game.
Visually representing data
To make it easier for the client to understand the information we provided, we tried to make everything as visual as possible. This included both data and ideas. When prototypes weren't ready yet we had a designer and artist work together to make specific presentation assets that would demonstrate what a certain mechanic would do, and how it would fit into the game. We only started doing this after noticing the simple mock-ups weren't clear enough, and included too much terminology for them to understand. By making this simplified version it helped the clients see better what the end product could bring, and also helped us see their part of the story better. In terms of data, adding graphs and charts on certain decisions and target audience research worked very well. It's something they're used to seeing, and was easier for them to interpret then when we only presented it spoken.
Minute making
Since client input was so important, clear notes of their input needed to be kept for future reference. When starting out these notes were often incomplete and confusing, and therefore not always useful when looking back at them in a later stage of the project.
Throughout the project we started learning how these could be improved, and made a small guideline for whoever was making notes:
During the meeting:
Adhering to these guidelines ensured all meeting notes were set up in the same way, were complete and legible.
Client contact
Having the opportunity to work with a client who is not familiar with the gaming industry proved an interesting challenge. We had to figure out what they wanted without them being able to directly explain it. The end goal would be to put the game on tablets in the bigger DHL training an innovation centers for employees to play in-between training sessions. We had to derive from context and their company pillars what it is they wanted to see in the game, and how we could make that enjoyable.
To ensure the client could see the progress and give their opinion on it regularly we had bi-weekly client meetings during which we presented the state of the project and the direction we were heading. We then discussed their feedback on this and how we could improve the game based on that. Most of these meetings came down to properly managing the clients expectations, which proved to be hard at first but became easier after analyzing their thinking process and feedback. This allowed us explain our decisions based on their pillars and values, which reduced the number of questions they had, and made them more receptive to changes we made on the game.
Visually representing data
To make it easier for the client to understand the information we provided, we tried to make everything as visual as possible. This included both data and ideas. When prototypes weren't ready yet we had a designer and artist work together to make specific presentation assets that would demonstrate what a certain mechanic would do, and how it would fit into the game. We only started doing this after noticing the simple mock-ups weren't clear enough, and included too much terminology for them to understand. By making this simplified version it helped the clients see better what the end product could bring, and also helped us see their part of the story better. In terms of data, adding graphs and charts on certain decisions and target audience research worked very well. It's something they're used to seeing, and was easier for them to interpret then when we only presented it spoken.
Minute making
Since client input was so important, clear notes of their input needed to be kept for future reference. When starting out these notes were often incomplete and confusing, and therefore not always useful when looking back at them in a later stage of the project.
Throughout the project we started learning how these could be improved, and made a small guideline for whoever was making notes:
During the meeting:
- Write the first letter and a colon to remember the speakers name
- Write only the most important words/pieces of what is said, yet still enough to turn it into a proper sentence
- Write in bullet points per topic
Adhering to these guidelines ensured all meeting notes were set up in the same way, were complete and legible.