Daily Stand-Up, 1st July

  • Done:
    • Caught up with all the Slack.
    • Rearranged google calendar to reflect the new routine and the Agile Team Meetings.
    • Requested admin permission for the slack work space for clean up.
    • Volunteered to do the videos on Hitfilm
    • Shared the Serial Link trailers with Sarra
    • Watched all the the week 5 material on Canvas and added a couple of things to my agenda for the meeting later today. I think that we may want to complete a full XD prototype before we get going with the Unity project, up for discussion.
    • Had idea about music that fades in based on location and proximity to target or Threat Level and so on.
    • Had Idea on reducing the progress toward the Clearance Level on Op failure. Would have to manage frustration though.
    • A Random event could also be a bluff in that the Handler could just say “stop … ” and then say that the coast is clear, move on.
    • Thought about the ways in which an Agent would be able to interact with the app
      • Screen
      • Voice
      • Headphone buttons
      • Change of location
      • Change of speed
      • Stopping / waiting
      • etc…
    • Meeting.
      • The new name is Agent.
      • Narrative is that you are a Sleeper and you are activated by the Handler so that you can work for the Agency (although we will want to think about what that is and what its called.) The narrative will be purposefully vague and contain just enough information so that the Op’s make sense and give an idea of what you are doing. There is just not the time to develop a full narrative and the structure that we are building will tell the guts of the story. The mechanism that we will use for this is that when the narrative would usually supply something specific we will have the Handler say that the information is classified or has been redacted for Clearance reasons.
    • Installed Unity
    • Installed MapBox in Unity
    • Started a course on Plural sight for onboarding with Unity
  • Doing
    • Carrying on with the Unity course
  • Blockers
    • Lack of knowledge with Unity, solving with course.

Can’t Do It

I thought I would talk a little about something that has really helped with the anxiety (that I didn’t expect to feel) that happened when I started the internship at Antimatter. I feel that the opportunity to work for them, even at this low level, is so rare that I think I got myself a little worked up wanting to show them that I am serious about the work and skilled enough to add value to them.

The problem

There were a few reasons why I think the anxiety started. It’s important to understand that I am typically not an anxious person. I steadily break problems down, and then solve them. I have good self discipline and I don’t usually panic. But, there was a perfect storm of factors at play here that I think caused this problem and I will explore those in a second. The main issue was that I perceived that it was taking too long to complete what I felt were basic tasks. I found myself stewing on things and not reaching out for help. I was also experiencing difficulty hunting down solutions to problems because if I did find something that looked like a solution, I could barely understand the other components that made up that solution. I felt very vulnerable. Silly really as I look back. I was losing sight of the fact that I had been brought on as a programming intern and not the new Technical Lead, Lord of All the Bits! I fell into that trap of expecting more from myself than I was actually capable of giving and then getting frustrated when I couldn’t deliver. Did it to myself.

Why I had the problem

  • Being new to C++: I finished long course on Udemy that was teaching me how to code in C++ recently. Very recently actually. I finished the course on the 24th May and the internship started on the 3rd of June. So that meant that I was in the studio, expecting from myself that I would be able to code properly 10 days after finishing the course.
  • Unreal’s C++: This is C++ on steroids. Unreal is built on C++ and uses some really cool but complicated and thorough tools to make the magic happen and if you wish to use C++ for Unreal projects then you really need to know about these features and conventions. I didn’t know about those things and that gave me another issue.
  • Unreal API: You have just arrived in a new town and someone says ‘hey, pop to the local shop and pick up some…’. Ordinarily, not a problem. But you just got here and don’t know where the shop is. Suddenly, something straight forward and simple is made complicated and difficult just due to your lack of knowledge. This is how I felt coming from Blueprint to C++. Basic things that would have take 40 seconds in BP took 3 hours and in C++, which I must say caused an enormous amount of stress.
  • Version Control: Using Perforce and collaborating with 20 odd people from all over the world was an experience in itself too. I have had very limited experience with version control having used Git but this was on another level.
  • The codebase: Oh my. The code base for the project that we are working on has been put together by people that really know what they are doing and is very granular. It uses assets I didn’t know about in novel ways (to me at least) and just working out the structure behind the code I needed to come off was very challenging.

The solution

That has been pretty simple actually. First I just made sure that I spoke about how I was finding it and that I knew that I was being too hard on myself. I needed some reassurance that I was not there to ‘change the world’ and just there to get a bit better at coding! Then after I realised that they expected me to struggle, I came up with the idea of the Can’t Do It timer. When I get stuck and feel that I am not moving forward, I put the timer on. If I solve the problem or make significant progress, I stop the timer. If I don’t, the timer will do off and when it does, I am duty bound to reach out to someone for a hand. Sometimes its the guys in the room and sometimes its the programming lead, who is abroad. Whoever it is, I talk to them.

How its going now

So much better! It’s made such a difference to the way in which I am tackling things. Also, I find that the lessons that I learn from reaching out solve other problems of course and that in turn stops me having to reach out so much. I have also started writing the solutions down in a Workflowy doc so that I should not have to ask about that solution again.

The future

I have had a couple of days now where I have made great progress and I feel that my skill level is growing. I see more of that in the future and I am really looking forward to the time where I am more engaged in ‘how should I do this thing’ and not so much ‘why is this thing not working’.



Done: Suggested to David that we produce the coding standard including a source control strategy as the next step. Worked on finalising the first iteration of the game play loop. Started to define ‘threat levels’ as part of the mechanics and fleshed them out a little in the doc. Came up with the idea of a Code Name Generator so that the Op’s get some more interesting and unique names. Came up with the idea of Random Events with the Op to add more interest. Found an interesting video featuring an ex CIA master of disguise talking about the craft and put that on the Inspire Channel

Doing: Working on the Dead Drop game play loop as an example of one of the Ops and hope to have the first draft of the entire App loop today.

Blockers: None

Daily Stand-up, June 26th

Done: Uploaded video to YouTube, put images on my Journal (took them down again as there were not mine!), had Davids link to the XD prototype ready to go. Attended the meeting and gave part of the presentation which I think went well enough for the amount of time that we had to plan. Earlier in the day, I caught up with all the Slack channels and looked through some of the products that may be competition to us.

Doing: Finishing the gameplay loop to a first iteration standard so that it could be the target for the first working prototype, even if that has a ton of placeholder. Then if there is time, I would like to look into Unity for onboarding.

Blockers: None

Exploring Space, no, not that one.

Image from here

Currently, we are engaged in a group project that is centered around the theme of location aware apps. There are other constraints too but I don’t have the time to present a full run down. The purpose of this journal has shifted a little now and its not an academic, marked piece of work and more a place where I can record some what’s, where’s and why’s so that I refer back to this in the future. It’s content should be enough that it jogs my memory of the process and not a full account of everything, so apologies for that.

As part of week ones content we were advised to read a piece called “Step and Play!: Space as interface in the context of location-based musical album apps” found on the ACM Digital Library.

Using the space

The paper talks about the use of the environment in order to access content within a musical album that you own or are experiencing. So the idea is that you have to travel to different locations to play the different songs or that the audio changes and updates based on the listeners physical location. I like the sound of that (Ha!) but the hermit in my immediately thought, ‘yes, thats fine, but I have paid for this I will expect to be able to access it from right here in my throne!’. So, I must say that the purpose to which this material was applied in the paper didn’t really make me want to actually use musical albums but it was food for thought.

Music in urban environments

Now this was interesting to me. I found that it resonated with me because the author talks about the combination of the physical locations that are being traversed by the listener and the ‘invisible’ layer of music that sits alongside or over the top of that more visual and physical experience. He talks about the fact that personal music really was the first mobile AR system. And I think he’s right. A persons reality, how they experience the physical space in which they find themselves, is changed by whatever they are listening to. I have personally experienced this and found it very interesting to have a vocabulary with which to talk about the effect that the use of personal audio can have. The paper talks about putting the listener in the directors chair, that they have agency over this physical sense of hearing and all without any real consequence. There is nothing that the listener has really given up in order that they can do this. I know, I know, they need to more careful crossing the road and all that, but, essentially, they are still in command. It’s very satisfying to have that choice and in thinking about that, it’s made me think how much listening to music may be less to do with the music and at least a little to do with enjoying that agency. Hmm…

What is means to us

Our project (which will be discussed in other posts) will use this structure and we have agreed that the narrative and player directions will be delivered via headphones as much as possible. Our idea centres around making the player feel like an Agent and one of the key mechanics for that is that they will be able to interact with a fully voice acted Handler. I think that this will increase immersion and have the effect that the paper talks about. I hope that we will be able to augment the reality of the player using the headphones as much as any other technology we a planning to incorporate.

Antimatter Games

Just a short post (as I have less than no time at the moment) to say that I am very, very pleased to have been offered a gameplay programming internship at Antimatter games in Falmouth over the next three months! I am not sure how much I can say about what I am doing but I can say that I am learning a lot and enjoying the process. I find that the biggest challenge is working with a well developed, complicated and optimised codebase for the fist time. I haven’t long finished the C++ course that I talked about a few weeks. That course focused on the basics of C++ and now there are a lot of other things that I need to wrap my little brain around.

The Project

Can’t tell you.

The work

Nope, can’t tell you that either.

The Pay


Completing the App Jam

This is now the second app jam I have done an I am really noticing the benefit to having to come up with something interesting within the confines of the, er, constraints. This jam was based around the theme of the module which is ‘Location Aware Apps’.

The initial theme was then further constrained with the words Police, Withdraw, and Difficulty. We were told that there would be an added twist in that there would also be a set of modifiers added to the mix. The plan was that you would have to incorporate and, yep, you guessed, ‘modify’ the concept that had no doubt been bubbling in your brain. It served another purpose too. It stopped the Jam getting too technical to quickly and forced us to stay away from actual development and stay with the ideas a bit longer. I think that this was good for me as I tend to do two things, although I am working on both of them.

1: I jump straight in. When I have some idea that I think is awesome, I tend to want to run with it and I do wonder if at least some of that is done to me wanting to get to some sort of execution before the sense of the idea being ‘awesome’ dissipates. I like the excitement of having an idea, developing it out and then seeing it on-screen.

2: I seem to be in good company with this one and it’s the game devs old enemy, over-scoping. I get very carried away once my brain starts ticking and ideas spawn ideas and so on. I will say, although every over-scoping addict will say this, that I think I do have a good ability to stay focused and on track. I don’t come up with sets of mechanics that should really be in different games, it does all fit in with the idea that I am developing. There just tends to be a lot of it. I think that this is why I like Agile, Epics, User Stories and so on. Its a really good way of being allowed to get carried away and then making sure that you just pick that one or two features that you are going to make first.


The modifiers for the Jam were (pulled from Canvas, I dont have the time to type all this!):

  • Happy Anniversary!
    • Your app should incorporate one of GAM730 2018’s themes – either COMBINE, GHOST or EXPLORATIVE – in addition to this year’s three themes.
  • Public information
    • Use offline or live data from a public API in your app.
  • LEGO Got It Right 
    • There are no spoken or written words in this app. This is even true in the instructions.
  • Wrist Watcher
    • The app is designed to run on a smart-watch, or uses wearable technology in some way.
  • Rumbled
    • Use haptics (vibration/rumble) to make your app more accessible to people who have some difficulty seeing or hearing
  • Where in the world is…
    • App content changes depending on the user’s geographical location (GPS, IP location, etc). The user experience is therefore significantly different for people all around the globe.

Agent Walkabout

So my Idea was to produce a mobile game that uses Geo-Location and Augmented Reality to provide the player with a secret agent type experience. The player would interact with a Handler, who is fully voice acted, and be sent out into the real world on Operations that they would be able to complete by going to a location, performing some action and leaving the area quickly. The suitable modifiers (or Diversifiers) as I have just realised they are called, may be Wrist Watcher, Rumbled and Public Information. I have lots more information about this idea and if I have more time I would like to talk about how I came up with it and perhaps present the entire concept.

Here we go again…

Yes, I am braced.

The course has resumed and that means just one thing. Fatigue. Actually it means a few other things too. It means that I get to learn more about the things that interest me, I get challenged and I get to experience the feeling of accomplishment when the marks come in. Sometimes. Lets get on then…

This module is all about creating an app or game in a collaborative team. This presents a host of opportunities and difficulties and time will tell how many of each we will face. I am generally optimistic and a good problem solver but I have had mixed experiences with academic team work in the past as have many of the cohort. I think, and hope, that at this level working together should be enjoyable and relatively friction free.

What I hope to give

If we get to the end of this project and I have supplied the team with the very best ideas I could, have worked hard to provide the best technical implementation I could and added value to team members where I could, then I will consider the project a success. I do believe that a person just sort of ‘knows’ that they did all that they could, and thats what I will be aiming for regardless of grade. I also want to make sure that the people in the team feel that they can approach me with whatever they need to discuss. I think that its a persons responsibility to make themselves approachable in this kind of context and be mindful of tone, body language and other forms of non verbal communication so that a trusting and open environment can be created. I will endeavour to give honest feedback in a constructive way and will not be rude or insincere in my behaviour toward the work, the team or myself.

What I hope to gain

That said, I don’t want a poor grade! That would not be desirable at all… But, I think I have found that chasing the grade to closely is a recipe for frustration. So, I am focused more on what I believe the course is trying to steer me toward. I think that is the cyclical analysis of my weaknesses, the recognition of where I am falling down, the creation of some plan to solve that issue and the completion of some reflective practice to assess the success of that plan and the practice that it prescribed. On a practical level I hope to learn about AR in Unreal and how to make and deploy Android mobile apps. I also hope to gain a better understanding and appreciation for what works and what does not with regard to working within a distributed team. There will be challenges there and I hope to learn from them

How I think I will record what happens

I have had a little think about how I may record the progress that I make and that the team makes while creating the app. I think that the major areas to cover will be:

Me: Am I operating as I should? Am I completing the tasks and work that I said I would and to the standard that I would be happy with?

Team: Are we operating as a competent, supportive and professional team that is ready to support the needs of the members and also call out poor behaviours and attitudes that are detrimental to the project.

Work: Are we progressing with the work individually and on the whole. This is where supporting services like version control and communication tools may be reported on I think.

Project: I have made this separate from ‘Work’. This may be a look at how the project is going forward overall. Is it going forward as we had planned? Have there been any problems, pivots and so on. Are we able to stick to the Sprint plan and so on.

Lets get to it…

Coming to the end

Yes, I think…

I wanted to talk a little about how I think that I have experienced this module, what I have learned about the technologies and just as importantly, about myself and how I engage with the course and my personal projects. I would like to explore what I did, why and what I would now do differently. I learned a lot, and not in the areas that I expected to.

I was too scared to start in C++

When we were given the task of creating an app for the Jam, I was too scared to do the project in C++. There, I said it. I was worried that I would not be able to finish the project to a good standard in the allotted 48 hours and I felt that having something the show for it at the end was worth more than the experience I would have got from coding the prototype in C++. So, I used Blueprint, exactly the tool that I am trying to move away from. In retrospect, I think that was the wrong move and this was pointed out by staff, although frankly, I didn’t want to hear it at the time. I was wrong about that. At that time, I was not so far along with learning C++ and have a lot more confidence with it now, but I think that it would have gained more from the project had I just struggled through and learned as I went along. Having said that, I think that there was also benefit in learning about raw C++ before jumping into Unreal’s version of it, but I now think that it would not have been as painful as I first thought to just have a go. Having completed the Battery Collector tutorial, I am really looking forward to a pure C++ project, which will begin soon.

I should have started the project again when it crashed

I cannot say that the Game Jam project was a failure, not at all. The fact that it crashed and I lost the entire project file lead me to a strong desire to embrace industry standard techniques for protecting project against just this sort of thing. I learned about version control quite quickly and have used it on every project that I have worked on since that time. The other lessons that came from that experience was the problem of circular referencing, which I am surely guilty of. I came from the direction that it would be more convenient for the ‘weapon’ to know about the ‘projectile’ and the ‘projectile’ to know about the ‘weapon’ but, it turns out that there is danger in this. Particularly in how objects are created and destroyed. If the objects need each other, its very risky to manage the start and end of their lives and they lean on each other in undesirable ways. I also found out that there are established Object Oriented Design Patterns and frankly, that has been a huge relief and I am now aware that there is a tool kit that I can learn that will help me plan and visualise the structures that I need to build for the games I make. However, although I learned a lot from the failure of the project, I feel that I missed out on being about to link the rest of the course material to that project. By the time that I realised that the rest of the cohort were carrying their projects forward, I felt that it was too late for me to do the same as I would have to rebuild mine from the beginning. I regret that decision and have decided, as detailed in my CPD report, to recommence the project applying the lessons that I learned along the way. I will be working on this during the three week break between modules.

First Class Blues

Here’s one that I was not expecting at all but actually hit me quite hard. When I came off the BA and having received 78%, I expected to take to the MA easily and knowing that I work hard and put a lot of hours in, thought that I would replicate that sort of performance. The realisation that the MA is a much greater challenge and very different to the course I studied before was slow to dawn on me and I feel that I responded quite negatively to the first set of marking comments at the time, despite receiving a respectable score for a first mark. I am pleased that my concerns were taken seriously and care was extended in explaining in more detail how I may have done better, but I didn’t expect my reaction to be so strong. I think that my confidence was bound a little more than I thought to my recent success with the Degree and perhaps I needed that to continue. That’s an error. I feel much better about things now and realise that I am receiving a tremendous benefit in having the think differently and in being held to a higher standard. It’s ironic as when I was exploring my options with regard to taking on an MA, I talked with staff at Falmouth about how I wanted to be surrounded by people smarter and further along than me, but when I experienced that reality, it took longer than I thought it would to adapt. I am grateful for the opportunity to be here and to learn from a variety of people, staff and students alike.


This is something that has only been identified very recently during a conversation with a member of staff but explains why I felt the way I did above. I think that I may have this ‘Impostor Syndrome’ regarding my ability to make games and in recognising how far I have come with in that goal. The thing is that this is in direct opposition to what I say a lot of the time. I find it easy to talk about the rate at which I have been able to learn how to do this work and the progress that I make all the time but actually, when I stop and recognise how I feel about it, I don’t yet feel that I belong and that at some point the gaps in my knowledge will identify me as a fraud. I think that was one of the motivations for Blueprinting the Game Jam project and for the the need to defend myself from the feedback that I received for the initial coursework in which I got a merit! I find that I continually remind myself of the things I have achieved as though they need to fuel the next challenge. I feel much better having had this realisation and am becoming much more aware that I do belong and that I can contribute and that it’s ok to get some things wrong and in fact, getting things wrong (combined with putting the effort in) shows that a person is learning and operating right at the edge of their current ability. I read somewhere, although I can’t seem to recall where, that the more specialised you knowledge becomes, the more obvious the gaps in it become. Also, the more you learn and achieve, the better your peers become. Both of these can fuel this problem if the are misinterpreted and yes, I think I may have done that.

The Direction of the Journal

While I was studying on the BA, we had to keep journals for each of the modules that we completed. The aim of that journal was to show the journey that each of us had and to show our ‘working out’ so to speak. I think that although I consumed the material from this course on reflective practice and writing, I didn’t fully appreciate the difference in the aim and style of this journal. On the BA, I wrote about everything that I did, what I thought about it, what was working and what was not, but it was missing the reflective side I think. I don’t remember committing much material that focused on how I had got to this level of skill, or why I had been encountering some problem or any real plans for solving those issues. It was all about the fix to the immediate problem, all about what I was learning to sort out the ‘line trace’ or the ‘overlap’ not registering, that sort of thing. I found it very useful, if a little too time consuming, although learning to type properly helped out a lot. I assume that we will need to keep journals for each of the modules that we complete and I will continue to practice what I have learned during this time. I bought one of the books that the course material recommended, ‘Search Inside Yourself’, and I will read it over the break between the modules.

Learning C++

I am very happy with the study that I have been able to complete on C++ and I feel much more prepared to tackle Unreal with it now. I do think that there are things I still don’t understand to a point where they could be effortlessly implemented (like I can in Blueprint now), but raw C++ certainly not alien to me anymore. I have almost completed the Udemy course I have been studying and its taken a long time as I have not left a single section without fully understanding the material, completing the quizzes and every programming challenge that the course sets, which are numerous.

In Conclusion

Now that the module is coming to an end, it’s clear what its purpose was. Who am I as a developer? Where do I want to go? What is stopping me and how do I deal with that? I did not expect so much reflection and I have struggled to come to grips with the academic writing, but I have received a huge benefit from the organised introspection. I now have a very clear aim, I know what I need to work on in order to get there and I have a structure in which to do that work. Over the break, I intend to execute the CPD plan I have created. First I will finish the C++ course that is nearly complete, then I will complete the design patterns examples and corresponding UML diagrams. After that, I will begin the Hostage Rescue project in C++ and set up a regular routine to learn and practice the math I need to learn in order to better understand the gameplay programming I want to do. At the bottom of the list, but still important to me, is the animation goal that I have as I think that starts the process of broadening my skill set as a developer. All the while I will split my time up so that Serial Link gets the attention that it needs also. I am confident that all of these topics are connected and that skill gained and work completed in one area will bolster my effectiveness in the other areas leading to overall progress.

My Experience with Project Management

Image from here

As someone who has now worked on a few different project’s, although all academic in nature but one, I thought I should talk a little about my project management experience considering the nature of the material from week eleven. I will talk about how Agile was introduced to me, how I took to using it or not and how I think Kanban fits in to the mix for me.

Being introduced to Agile with Scrum

I was introduced to the Agile approach to software development and in particular, Scrum, early on in the BA top up course I took in 2017. As with most things on the course, the concepts were explained quickly and in a hurried fashion (our lecturer needed to be everywhere, all at once, but still managed to deliver a great course) and I don’t think that I understood what the benefit to the methodology was. I don’t think that I was alone in that either as although most of the other students present were on the course as a logical continuation of their study rather than coming in from the outside like me, they did not seem to have had to work in this way before. I was already vaguely aware of Kanban and had stumbled across Trello in reading around for better ways to manage my business tasks. We were informed that we needed to set up a Trello board and use the standard lists (To Do, Doing and Done) and although there was talk of Sprint’s, there was no mention of User Stories, the Scenario Testing to validate that they had been delivered or the idea of a Minimum Viable Product, at least not in those terms.

My First experiences with Agile

I think that considering the incomplete nature of the introduction to Agile combined with the sense of urgency that was being instilled due to the quality of the coursework needing to be very high, I saw Agile as a glorified to-do list. I thought that the bi-weekly catch up’s with the lecturer were just to make sure that the work was indeed moving forward. The idea of a ‘Sprint’ was not a lot more than ‘In two weeks I want to see where you are and I need to see that the project has moved on’ and not the heavily defined planning and tracking tool that I understand it to be now. Looking back, I would have benefited from understanding the link between the Sprints, the Backlog of User Stories and the fact that they combine to contribute to an MVP. I do think that the the idea of delivering something that worked as a whole was communicated and I do remember scrambling around to get assets that the team were working on into the main Unreal project file when each sprint was due. It’s fair to say that my memory of the process will be hazy as it was quite a while ago now and there was so much for me to learn and take in. I can say though that we did not create User Stories or Scenario Tests and in retrospect, that’s quite a large section of the Scrum methodology missing. In the teams we needed to choose a project leader and not a ‘Product Owner’, ‘Product Manager’ or ‘Scrum Master’, all important roles in the Scrum Agile approach. There were no Stand Ups, Retrospectives and work was frequently changed during the Sprint, which is forbidden until the Sprint ends and there is another Sprint Planning Meeting.

Despite a great many of Scrums implementation details missing, I did come away from the experience of the first two coursework projects with a better idea of why an approach like Agile should and does work. I liked the fact that there was no major upfront planning simply due to the fact that I had such little skill at that time, I would not have been able to create much of a plan past my ‘best guess’ at how something will go. I do appreciate that is the nature of most plans, but the clarity would have been very low and the probability that the content of the plan would need to change dramatically would have been high. That meant that Agile, even in its incomplete form, was quite a good fit for me and the team’s I worked with throughout the course as it was at least obvious that being flexible and responding to change was encouraged.

The mighty Kanban

When the need to complete a Gantt chart was thrown into the mix during one of the initial projects, I really felt that it was in direct opposition to all the benefits that had been communicated to us regarding Agile. Here was a document that was heavy in upfront definition and recording of tasks, dependencies and estimations of time and for me at least, seemed to be in direct opposition to the Agile methods. I think that it was intended that the Gantt chart be used in planning Sprints but I have since discovered that Scrum already caters for that kind of planning with the User Stories being broken down and prioritised and then being pulled forward by a team member willing to accept ownership of that task. Also, time is a tricky metric in software development, I know from my own experience, and so Story Points are used as a way to estimate the overall difficulty and complexity of a broken down User Story leading to a better estimate of how long the feature will take.

I did a little digging around at that time and stumbled across something that informs what I do even now. I found a presentation by a Microsoft project leader, Eric Brechner, and having watched that, was convinced that even Scrum, with the its limited planning and flexible nature, was still a little overly complicated. The way he spoke about Kanban really showed the simplicity of what he called Continuous Delivery. He calls the system an evolution from Scrum and talks about Scrum with respect. He does however say that he believes that the time spent Sprint Planning, tracking Sprint progress, holding daily stand-ups and the retrospective at the Sprints end would be better spent just, well, working. He talks about making sure that each of the Kanban board’s column’s are divided into two though, something that I had seen only in his presentation. The sub-column’s are the tasks that are to be completed and the ones that are complete. Sounds simple, but both of the sub-column’s contribute to the Work In Progress limit of the column that they combine to make. This makes it very easy to see what needs to be done from what is already done without the tasks having the move forward into the next column. The introduction of WIP limits in each of the columns keeps work coming at a steady pace so that developers don’t get overwhelmed and effort is tunnelled into one or two tasks (or however many tasks are appropriate for the team). But, having tasks that are complete still contribute to the the WIP limit does something very important. It act’s as a self imposed bottle neck that immediately shows problems with the work upstream and stops work being constantly pulled forward to that particular column, completed to that point and pooling there with no where else to go. This stops work being wasted on features that are not a priority and encourages the team to find out what the real problem is and band together to solve it.

This is a great presentation on Kanban over Scrum and well worth a look.

That’s the major difference. Scrum focuses on using the product backlog to house the User Stories just like Kanban, but from that, the Product Owner must create a sprint. All attention is then on that Sprint and the content of that Sprint should not change until it is complete. In Kanban, there is no such structure and tasks are pulled across to board at a steady pace and completed. The Sprint seems to me to be the last area of rigidity. So is it useful? Well, business people would likely think so as It’s the closest thing that an Agile practising team can put forward as a forecast. If there are team members that are perhaps not as intrinsically motivated as they could be, they may benefit from the push of the external, intermediate deadline. But I think that if the team is motivated, and the ‘Done’ rules for the board are clear and being obeyed, the Sprint is just not needed. On of the other key arguments is that at the end of the Sprint, there should be a prototype of the software that is available for the Product Owner to test. With Kanban, its no different. The only component needed on the board is a done rule in a ‘Build’ column that collects a number of tasks defined by the WIP limit, and forces a build in order that they can move onto the next column.

I would go with Kanban all the way if I could, and I have with Serial Link, but it’s clear that Scrum is very established. That means that in order to fit into other studios and be able to collaborate, I also need to embrace Scrum and that’s fine. It’s not the difference between cars and motorbikes, it’s as if we were talking about how different petrol and diesel cars feel to drive. Different, but closely related.

Using Now

In my little studio and in making Serial Link, I am using Kanban. I have dedicated one of the walls and set up the following columns.

  • Backlog
  • Breakdown
  • Development
  • Implementation
  • Build
  • Validate
  • Done

The Backlog is where I keep all the items that I want to work on although I currently don’t have this organised in User Stories or Epic’s. I think that given the chance to set it up again, I would do it that way as I feel that approach captures the emotional experience you want to player to have.

Backlog in my home studio

The Breakdown column is where large tasks get, you guessed it, broken down into smaller tasks. So, a large task like ‘Improve the Gore’ was broken down into several things like ‘Find better particles’, ‘Find out why the decals clip’, ‘Find a better way to draw blood, reducing the number of line traces’ and so on. I think that creating User stories would have been better here though and in my next project I will try using that approach.

Done rule: Broken down to the point where we know what the feature does for the player and what it looks like step by step. We know what assets we need and we have the work accepted by a team member.

The Development column is where the design and prototyping happens. This is where I get a bare bones ‘I could show this to other developers’ sort of feature done. It would have no UI and be printing feedback to the screen but all the pieces would be there before it is declared ‘Done’ and can move on. The WIP limit is quite high to accommodate the high number of smaller tasks that may be required to complete the main task from the Breakdown.

Done rule: Assets and logic have been created. There are no bugs that we know about and all the assets are ready.

The next column is Implementation. This is where I take the feature from ‘developer ready’ to ‘playtest ready’. Items don’t leave this column until they I am happy to put them in front of a play tester with confidence that they will understand what it does and how to use it. The reason that the WIP limit is only one is that I am the only developer that touches the project file. Knowing more about version control now, I would change this in the future and allow other developers to check in there own assets and so on.

Done rule: All logic and assets are integrated into the existing game to a standard that we are happy for a player to experience.

After that is the Build column. When the WIP limit is reached here, the project must be built and satisfy the frame rate criteria. This means that even though I am not using Sprint’s, I still have incremental builds being triggered in a systematic and predictable way. There are a couple of things that I will change in the future with regard to the done rule here. Replace ‘extended period of time’ with an actual number and ‘no bugs or crashes’ to something like ‘all bugs captured in kill list’. The presence of bugs should not mean that the build cannot go through to validation, the next step, as it could be that the feature needs heavy reworking anyway.

Done rule: Game builds with no errors and no warnings. Build player for extended period of time with no bugs or crashes.

Coming toward the end of the board is the Validate column. This is where the features are tested by users and is critical for making sure that we do not develop in the dark, emerging one day with something that no-one wants. I need to make sure that we are creating things that people actually want to play with and testing is very important to me because of that.

Done rule: Player reactions and feedback has been gathered and analysed. All issues identified and inserted into the workflow as needed. Ideas have been captured for the backlog if there are any.

The end of the board is the Done column and is just a place to collect the stickies that have travelled through the process. Its good to have them there as a reminder of whats gone into the project and allows better reflection in the future when planning new projects. Well, I suspect so, as this is the first one that I have managed this way!

Will that Change in the future?

In the immediate future I will be managing the Hostage Rescue project using the Trello board I have set up and using Scrum because I want to get the experience of doing that. I can see that in projects where I have the authority, I will be using Kanban only as I really do think that its the better way to go. But I have nothing against Scrum and I want to be able to contribute well to other studios using it.