In our gamification design and development work, we loosely follow the agile methodology. In the agile way of working the agreed tasks and priorities form part of a sprint. We do our best to work in this way and work with high, medium and low priorities on our projects. Any time we reach the end of a project, we start creating issues logs and get ready for the final sprint. The final sprint is often the longest and most tedious because the big work is out of the way and now we are effectively fiddling with details.
The emotional journey
The emotional journey of any given project goes from the excitement on winning the work and enthusiasm to start. This is soon followed by the realisation of the magnitude of the task you have taken on and at various points, throughout the project, you may go from feeling good about to feeling a bit frustrated or disheartened by it. Any time you hit a major deliverable or milestone there is a bit of rejoicing and if you can take a break to celebrate that is great, in our experience, it tends to immediately roll forward into the next phase.
I really enjoy it when I start to see a design come to live via graphics and playable parts. The development phase is high on conversations back and forward with the team to make sure everyone knows what we are working towards. Questions and suggestions often come to improve the original design or development limitations arise which means re-thinking some of the designs. The key is to give clear direction and to ensure that people can keep working and progressing to hit all the subsequent deadline.
The testing phase is where quality control and bug spotting and fixing is the order of the day. My tool of choice is an issue log in excel, where each task get’s a ranking in terms of priority and the team can then indicate where in the development it sits. It can be open, on hold, in progress, ready for a next build or resolved. This spreadsheet then becomes the driver for the activity for the final sprints.
Multiple stakeholders
In my experience of dealing with large corporates, making sure that everyone is on board with the design and to also draw lines on what can still be changed at which points if key in our work. Often when we come to final deadlines, we will hear of someone higher up in the client organisation, which has not been privy to the process from the start and has some clear opinions. With experience, you learn to draw these people into reviewing earlier in the design and development. There is no clearcut way of ensuring you won’t get some surprise views later in the phases but by asking who has final sign off and say over the projects, you will hopefully get some of them on board sooner rather than later.
In gamification and game design for corporate projects, one thing that always strikes me is that we do an awful lot of explaining and educating of what it is we actually do. Often the decision makers have no idea of game design and development and in some cases, they also have no interest in games or self-admit to be against them. The latter I find challenging to deal with. There comes a point where you just have to go into production to complete a project and not consistently debate the purpose of something. The proof is often in the experiencing of the end result.
My personal preference is to work with people on the project team that at the very least understand games from the players perspective. When we have these types of people on the client team, the whole process becomes a lot smoother and they can rationally follow why certain things work a certain way. Preferably that person is also well-respected and high enough up the food chain on the client side to help the project moving.
Good project management is key
The more project we have ongoing at any one time, the more important project management becomes. I have been told numerous times that a great project manager can do any project. Now while that is true for the basics of communication and project tracking, I don’t buy it when it comes to delivering great work. When they don’t understand your type of projects, the pitfalls relating to them and the tools we are working with, you are introducing the risk of cluelessness and for the project manager to be bought and sold by developers. Multiply the trying to buy and sell you all sorts of stories a few times when you are female, unfortunately. I have learned to arm myself with the knowledge to ensure I can spot the bluff.
A great project manager can steer a team to succeed and focus on the most important tasks that will make the biggest difference. In a recent project, I had to step in to get the project to the final sprint, because communication had fallen over, deadlines were slipping and issues were being handled in a very disorganised manner. I can’t sit back when ultimately my clients are potentially on the receiving end of something that isn’t finished.
When you are outsourcing your development to external partners, which we often do because of the varying nature of the types of work we deliver, communication is key. Our development partners are rarely in the same countries as us, so project management tools are important. We have worked with tools such as Slack for everyday conversations and questions, Trello board and other Kanban style tools such as Ora and Gitscrum as well as Basecamp and Monday for project task tracking. One thing to watch for is that communication to you as the client also includes the daily questions between teams around problems they are facing and questions they have. If this is filtered by their project management then be sure that issues will arise later as a result of interpretations of what you have said and especially if they are first time teams to work with gamification or games this can give rather surprising/shocking results.
Project cadence
You know a project is going well when there is a natural rhythm of meetings, communications, deliverables happening on time and problems being tackled head-on. Every project will have moments where it is harder to envisage a positive outcome, but with a good team, communication and perseverance we often get there. Creating the regularity of specific recurring tasks and not moving them is the base of project cadence or flow. Everyone gets into a rhythm of working towards this.
The final sprint
By the time you come to the final sprint(s), project management becomes more intense to keep a team focused on the highest priority items. At this point, everyone is probably suffering some dose of project fatigue and want’s to see it over and done with. Snag or bug fixing tends to be everyone’s least favourite task. But reaching a final deliverable that everyone can be proud of is key.
From an emotional perspective, this is often the phase that is hardest to manage. Motivationally you are asking people that have been working hard already to dig a little deeper. High detail doesn’t suit everyone and that can cause frustration and interesting conversations. I personally find this the point where I have to care about what happens. I have had people walking out and going missing in action and I have had serious arguments and then we have also had really good positive outcomes, but anything is possible. It is a case of walking a bit of a tightrope of being demanding and listening to when it is driving it to the edge.
I think that a celebration after the final sprint is essential, but only when the job is completed. Let go too soon and people become unfocused, leave it too late and people don’t seem to care anymore. However, there is great satisfaction in completing the long final sprint to the developed end product.
Gamification design, game design, instructional design, it’s all easy, or?
The post The final sprint is often the longest appeared first on Gamification Nation.