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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s