Resolving a Stalling Task Pipeline
“Create phase 2 of final boss”
This task demanded some code extensions. Usually coding tasks take a few hours in average. But not this time. Each sub-task of the “phase 2” task expanded into days of coding and testing which made the whole task take several weeks.
Working for one week on the same task is OK. The second week already gets tedious. The third week is… well, as said: horrible. Motivation decreases very fast. The light at the end of the tunnel pushes further afar each time you start another sub-task.
Plans were to release a new version of the game each fortnight. That would have been around the 15th of June. But one task was enough to impede the whole project. This made me ponder on how to avoid this problem in the future. Here is what I came up with:
Split it into sub-tasks
This sounds nice but does not solve the problem. If your goal is “make boss X” and it’s a complex endeavor, splitting the task into smaller ones won’t help. It does not matter if you have 1, 10 or 100 tasks to reach your goal. On the other hand, ticking off sub-tasks provides you with a feeling of progress. Therefore I see task splitting as a good thing.
Don’t declare big tasks as release goals
To avoid including costly tasks in your release plans you have to be able to spot them in advance. Sometimes you know that a task will take several days or weeks to complete. Other times you will find out that a task is a Behemoth on the go. It takes some guts to postpone a big task you’re in and continue with smaller ones. The ego often stands in the way because it feels like giving in. I could not fight this feeling and therefore stalled my (felt) progress.
Change release goals
Don’t constrain yourself to a goal or promise. Keep your plans as flexible as possible. Avoid promises. I decided for future tasks to change release goals when a task turns out to stall my progress. But wouldn’t that make big tasks get left behind?
Work on big tasks in parallel
Among big tasks exist many more smaller tasks. Do multiple smaller ones sequentially and one big task in parallel. Having sub-goals for the biggie is helpful. As said, this serves the fuzzy feeling of progress.
Do it badly
This needs balls! Are you ready to release the worst version of a feature? Then you can try handing out a really bad implementation which will take only a fraction of the time of the high-quality version. This is the famous 80-20 rule in action, which sometimes isn’t that easy to carry out.
N+ is your friend
This goes hand in hand with “do it badly”. Start with a laughable version and improve on it iteratively later. Many times your audience won’t recognize that you just integrated a “pile of shit” into your game. They just don’t see it the way you see it. Sometimes this saves you time you would have invested in a higher-quality version which is not necessary.
I’m sure there are more things you can do to not get stuck in the task pipeline. This list is just my personal brain dump. IMO keeping your momentum is just a matter of deciding (to stop) what you are doing at the right time and having the balls to carry out these decisions.