Getting Organized about Projects
I've come to agree with the adage "Failing to plan is planning to fail." In my experience, going into a project that demands any sort of complexity without a clear, concrete plan, is like driving while blindfolded {1}: my only way to maybe get where I'm going, is to swerve off the road enough times to get a feel for where I am and where I need to be – and, in reality, I'll probably crash, or fall off the side of a mountain, or something. :s
Design as a Distinct Process
In the past, I didn't respect the difference between design and construction. I trivialized design as something I could do on the fly, while I built the product. The more I try planning, though, the more I realize that treating these two things as separate processes is the only way to do either properly. Whether it's designing a website in Inkscape, designing the architecture of an app on paper, or designing the schema of a database, doing design work before typing my first line of code is never something I regret.
Design tools (whether it's software or pen-and-paper) allow for quick changes, which in turn allow for brainstorming, mistakes and A-B testing. It's easier to erase something on paper, or delete it in Inkscape, than it is to tear out a section of code (and patch up all the bugs that result from tearing out that section) just to see whether the product would look better without that section. Construction tools (like programming languages) aren't built for design – even when you use Git to maintain feature branches. They're slower, and made for deliberate implementation of a well-planned idea.
I used to think I could save time by avoiding planning. In reality, there's no avoiding planning. If you try to avoid planning, you end up just trying to plan while building. These processes get in the way of each other, because you end up writing code and implementing features that you'll later scrap (because the feature/code wasn't thought through). In my experience, time spent performing two concurrent tasks poorly, is always better spent doing two asynchronous tasks well.
Kanban
While Agile's broadness of definition leaves me with more questions than answers, Kanban – a specific Agile framework – answers those questions.
According to ProjectManager.com [1], Kanban was created in the 1940s by Taiichi Ohno at Toyota, and adopted widely within Toyota by the 1960s. It's a Japanese word that apparently translates to "Signboard." [2] In a production environment, it seems to be centered around putting a sign onto an item (or container of items) before it's used, removing the sign after the item (or container of items) has been used up, then putting the sign in a place where it signifies that another one of (or another batch of) that item needs to be ordered. [2]
In software design, it seems to be a bit different. I watched one video on Kanban, and I'm not going read any other instructional material on it at this point in time, because I don't want to confuse myself with 20 different ideas of what Kanban is.
The video is Beginner's Guide to Kanban for IT Project Managers by the IT Project Managers YouTube channel. [3] It's a really good, straightforward video that gave me concrete instructions for how to track of a project and make sure that the project is seen to completion. I'm sure someone will take issue with some aspect of the video, and say that it's not "real" Kanban, but to quote the Agile Alliance (emphasis mine) [4]:
Those frameworks [like Scrum, XP, Kanban, etc.] help inform where a team starts with its methodology, but they shouldn’t be the team’s methodology. The team will always need to adapt its use of a framework to fit properly in its context.
This is the first clear, concise and applicable explanation I've heard of an Agile methodology, and it makes sense to me. So, whatever it is, I'm going to use it as a starting point.
According to the video, Kanban is a system in which you create distinct stages for tasks, from concept to completion (i.e. "Planning", "In-progress", "Complete"). You then break your project down into smaller tasks. You start every task at Stage 1, and continually move your task from one stage to the next. Each stage has a "WIP Limit," which denotes how many tasks can be in that stage at a time; this forces you to move tasks along to completion, as opposed to starting many tasks and not finishing any of them.
The reason I like Kanban is that it works with my impatience and novelty-seeking while also restricting me enough to prevent me from jumping from thing to thing without completing anything. At the end of the day, it's just a system, and it's up to me to adhere to it and stay disciplined enough to complete the project – but Kanban seems like it'll help make that easier.
I also like that it's simple, and is in wide use.