What is the effective system methodology for doing a start-up project?

Question

I'm an experienced developer. I'm flexible and can develop apps at any platform, but I'm experiencing problems on meeting my own deadlines and asking myself why can't I finish this start-up idea/solo project of mine. I started this project alone, and I only have few consultants. Also, I never quit my job as a programmer/developer at our company. My project is an app (desktop, Android & iOS).

I use the Scrum method on this project. It's like insert-insert-insert when I want something on my app.

What's an effective method in doing solo projects so that I can finish my deadlines?

Answer 1

Back in the 90s, Watts Humphreys developed a "Personal Software Process", first outlined in A Discipline for Software Engineering and subsequently adopted and promoted by the Software Engineering Institute.

Regardless of its actual content, the key insight of the book was in taking the processes of development in groups and scaling it down to the individual developer.

That's the place to start. Pick practices as if you were in a team, then act as if you are the team. For example, don't perform work without an issue-tracking ticket. Don't check in code without tests. Practice branch management. Write daily "standup" reports summarising what you did yesterday, what you're doing today and what's blocking you.

When I'm working on solo projects that matter (as opposed to learning or noodling around), that's what I do. I raise issues, I fork into an issue branch, work on it, then merge back to master. I write notes and specs when I need them, as if some other programmer were going to take over. And so on.

Do I get 100%? No. But I do try to stick to it, if only so I have a record of what I did, when I did it, and why I did it.

Answer 2

No method guarantees results from a timeliness perspective...or any perspective for that matter, nor does any method offer better timeliness results than another ALL the time under EVERY different scenario. Different methods work better based on THAT project at THAT time. The method is not your issue.

Your issue is estimating techniques and choosing the planning value that represents the degree of risk you are willing to assume. Much of your results from a schedule perspective is random, in that after you pull all the levers under your control to increase your odds of being on time, you are going to get this with many random and uncontrollable variables that may still make you late or even come in early. These are aleatory risks.

If you are coming in late repeatedly, it may be nothing more than a series of bad luck, not unlike travel to the airport four times in a row and hitting severe traffic due to accidents. It just happens and the last four times you got hit.

But it may also be due to promising a planning value that is simply too risky or too aggressive. You may need to push that out to the outside of your estimate.