This article will help you create some very basic systems for managing your solo software project. It won’t help you decide what projects are good ideas, or successfully market your software, but following its advice will make you more likely to get to a finished product, instead of giving up in despair.
Who will find this helpful?
- a hobbyist or pro using their spare time to build something they want
- an entrepreneur building a minimum viable product for a business idea
- a freelancer building a web or mobile app for a client
- anyone who wants to learn by doing
I’m sure many people are already on board with the need for some systems to help guide the creation of their software, but I can literally hear some of your bloodshot underslept eye-balls rolling in their sockets and saying “processes and project management systems are for the office, this is just overhead that gets in the way of getting stuff done".
I beg to differ.
Why you need a system
Even a simple project has multiple moving parts. It may be that you’re capable of keeping track of them all, but that requires effort and costs you brain power, your most precious resource for software development. The reason for this is known as the Zeigarnik Effect:
The Zeigarnik Effect is the tendency to experience intrusive thoughts about an objective that was once pursued and left incomplete (Baumeister & Bushman, 2008, pg. 122). The automatic system signals the conscious mind, which may be focused on new goals, that a previous activity was left incomplete. It seems to be human nature to finish what we start and, if it is not finished, we experience dissonance.
The take home is, unfinished tasks will trouble your worried mind. Storing your tasks somewhere trusted and finishing them as fast (or faster) than you start them, will free your mind for coding. A simple system will serve this purpose, while introducing minimal extra effort.
1. Getting Started
It may seem obvious to you what your project is; but until you’ve written it down, and explained it to a few people, you can’t be sure that it’s well defined. Figuring out why you’re doing this project and what your goals are doesn’t take long, and will pay dividends down the road.
Create a one-page project charter to outline the scope, objectives and people involved with your project. Your charter should answer the following questions:
What are your goals?
Get high level, ask yourself WHY you’re doing this, and what success looks like. If it’s a freelance project, establish this with your client. If it’s a side project, by straight up about it. Are you developing a minimum viable product to test a business idea or is it just something you think would be cool to see or make your life easier.
Who are the stakeholders?
Whose input is important to guide your project to success? Maybe it’s just you, maybe it’s potential customers or a client. How will you communicate with these people? How much influence will they have?
What will the product enable you to do?
This is akin to an epic user story for your product. Don’t talk about how the product will do what you want, focus on what you want.
A basic user story format is: "As a <role>, I want <goal/desire> so that <benefit>". This keeps the focus on solving the problem and avoiding tunnel vision around specific features for solving the problem. For example the epic user story for your product might be “As a bowler, I want to know how what I eat for breakfast correlates with my bowling score, so that I can always eat the right pre-bowling breakfast”
How much time are you willing to spend on this?
Particularly if this is a side project, it will almost inevitably take longer than you think. At the outset, we tend to see the work breakdown at very low resolution. Once you’re face to face with a particular task, you see the fine details and nuances much more closely. In one of the most popular quora answers ever, Michael Wolfe deals with the reasons for this very astutely.
When it’s no longer fun and exciting, will you keep plugging away, or will you accept the sunk costs and move on? Decide beforehand how far down the rabbit hole you’re willing to go.
2. Doing it and Managing it
Since you’ve already created a scope now you just have to break it down into manageable tasks, ideally things which aren’t much more than what you can do in a given evening or two worth of project time. Keeping your tasks small will help you to see your progress and feel great when you check something off.
Tasks that are further down the road, will inevitably be more ambiguous; no problem, as they come closer to being executed on, you can split them up further.
Write each of these tasks on a sticky note, we’re going to use them to fill up your personal kanban board.
The Kanban Board
Find a visible place in your workspace and put up a whiteboard. Keep your kanban board really simple with three columns: Backlog, Doing and Done.
There are two simple rules for using personal kanban:
- Keep your work somewhere easy to see
- Limit your work in progress. Typically no more than 5 tasks at a time in the “Doing” column.
Both of these rules would make Zeigarnik happy; they ease the burden of how much you have to store in your limited grey matter and put it somewhere you can trust you’ll see it.
Even when there is extra space in your “Doing” column, have a bias towards finishing a task over starting a new one. Only introduce new tasks into “Doing”, if everything else is stalled, and there’s absolutely nothing you can do to move it forward.
If you’re waiting on a domain transfer, go ahead and start working on wireframing. Don’t create a separate column for stalled or waiting items, even if you’re not working on it right now, it’s occupying precious brain cycles.
No one likes tracking their time, and most time tracking software makes the process even less fun, but if you keep it simple, it can help to give you very valuable data and improve your sense of how long a task really can take.
Use your personal kanban to track when you moved a task into “Doing”, when you moved it into “Done”, and how many hours you spent on it. You can do this just by writing it on your stickies like so:
Setting up these tools adds minimal extra time to the initiation of the project, and will pay huge benefits by releasing your mind from having to track all these items and allow you to focus on the execution.
I do believe that wireframing and mapping out the workflow of your product are very much worth your time. We use Moqups, which is really user friendly and takes no time to figure out.
Even though it’s just you, using version control will help you to undo your mistakes and create an easily trackable history of your progress.
Git Immersion is a great tutorial for setting up a git system. If you want a cloud based repository, with pretty graphics illustrating your branches and merges, Bitbucket’s free plan should be totally adequate for you.
Here’s the fun part, I hope that creating the charter and setting up your tools only got you more excited about the awesome code you’re going to write.
This is your project, it’s not my place to tell you which languages, frameworks and other technologies to use, you know what works for you. Unless this is a project intended to help you learn some new technologies and frameworks, you probably just want to get going with the least amount of new learning required.
Scope creep is the great enemy of getting things done. If your imagination, your client or other stakeholders are introducing new and wonderful features to distract you, nip that in the bud. This is why you created your project charter. Keep it beside your Kanban board, where you can see it and remember what you’d first set out to do. If the project drifts from the charter, make sure there’s good reason for it.
Keep moving, do what you can to make some progress every day to stay motivated.
3. Releasing 1.0 and/or Closing
Maybe you release your 1.0 and this project blow up into a huge success and becomes your life’s work. Or perhaps you’ve met the goals of your original charter, but you see potential to go further.
On the other hand, maybe you’re completely done with this piece of software; it’s served its purpose of satisfying a client, or teaching you what you set out to learn, or is now serving you as a handy little tool.
Either way, upon completing the first version of your project, it’s worth doing some work to close it out. The scale of this effort really depends on the project.
At a minimum, you should archive your post it notes somewhere safe. When starting your next project, they’ll be useful for remembering what tasks and time commitments were required last time.
Now sit down, have a beer, and contemplate how awesome your shiny software is.
|From D.A.K Photography|
References and inspiration: